Routage des politiques Linux – les packages ne reviennent pas

J'essaie de configurer le routing des politiques sur mon server domestique. Mon réseau ressemble à ceci:

Host routed VPN gateway Internet link through VPN 192.168.0.35/24 ---> 192.168.0.5/24 ---> 192.168.0.1 DSL router 10.200.2.235/22 .... .... 10.200.0.1 VPN server 

Le trafic de 192.168.0.32/27 devrait être et être apathé via VPN. Je voulais définir certaines politiques de routing pour apather du trafic à partir de 192.168.0.5 via VPN ainsi – pour commencer – de l'user avec uid 2000. Le routing des stratégies se fait à l'aide de iptables marque la cible et la règle ip fwmark.

Le problème:

Lors de la connection à l'aide de l'user 2000 à partir de 192.168.0.5, tcpdump montre les packages sortants, mais rien ne revient. Le trafic depuis 192.168.0.35 fonctionne bien (ici je n'utilise pas la politique fwmark mais src).

Voici ma configuration de passerelle VPN:

 # uname -a Linux placebo 3.2.0-34-generic #53-Ubuntu SMP Thu Nov 15 10:49:02 UTC 2012 i686 i686 i386 GNU/Linux # iptables -V iptables v1.4.12 # ip -V ip utility, iproute2-ss111117 

Règles IPtables (toutes les règles dans le filter table sont ACCEPT)

 # iptables -t mangle -nvL Chain PREROUTING (policy ACCEPT 770K packets, 314M bytes) pkts bytes target prot opt in out source destination Chain INPUT (policy ACCEPT 767K packets, 312M bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 5520 packets, 1920K bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 782K packets, 901M bytes) pkts bytes target prot opt in out source destination 74 4707 MARK all -- * * 0.0.0.0/0 0.0.0.0/0 owner UID match 2000 MARK set 0x3 Chain POSTROUTING (policy ACCEPT 788K packets, 903M bytes) pkts bytes target prot opt in out source destination # iptables -t nat -nvL Chain PREROUTING (policy ACCEPT 996 packets, 51172 bytes) pkts bytes target prot opt in out source destination Chain INPUT (policy ACCEPT 7 packets, 432 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 1364 packets, 112K bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 2302 packets, 160K bytes) pkts bytes target prot opt in out source destination 119 7588 MASQUERADE all -- * vpn 0.0.0.0/0 0.0.0.0/0 

Routage:

 # ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master lan state UNKNOWN qlen 1000 link/ether 00:40:63:f9:c3:8f brd ff:ff:ff:ff:ff:ff valid_lft forever preferred_lft forever 3: lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether 00:40:63:f9:c3:8f brd ff:ff:ff:ff:ff:ff inet 192.168.0.5/24 brd 192.168.0.255 scope global lan inet6 fe80::240:63ff:fef9:c38f/64 scope link valid_lft forever preferred_lft forever 4: vpn: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100 link/none inet 10.200.2.235/22 brd 10.200.3.255 scope global vpn # ip rule show 0: from all lookup local 32764: from all fwmark 0x3 lookup VPN 32765: from 192.168.0.32/27 lookup VPN 32766: from all lookup main 32767: from all lookup default # ip route show table VPN default via 10.200.0.1 dev vpn 10.200.0.0/22 dev vpn proto kernel scope link src 10.200.2.235 192.168.0.0/24 dev lan proto kernel scope link src 192.168.0.5 # ip route show default via 192.168.0.1 dev lan mesortingc 100 10.200.0.0/22 dev vpn proto kernel scope link src 10.200.2.235 192.168.0.0/24 dev lan proto kernel scope link src 192.168.0.5 

Déchargement de TCP ne montrant pas de return du trafic lorsque la connection est faite à partir de 192.168.0.5 user 2000

 # tcpdump -i vpn tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listning on vpn, link-type RAW (Raw IP), capture size 65535 bytes ### Traffic from user 2000 on 192.168.0.5 ### 10:19:05.629985 IP 10.200.2.235.37291 > 10.100-78-194.akamai.com.http: Flags [S], seq 2868799562, win 14600, options [mss 1460,sackOK,TS val 6887764 ecr 0,nop,wscale 4], length 0 10:19:21.678001 IP 10.200.2.235.37291 > 10.100-78-194.akamai.com.http: Flags [S], seq 2868799562, win 14600, options [mss 1460,sackOK,TS val 6891776 ecr 0,nop,wscale 4], length 0 ### Traffic from 192.168.0.35 ### 10:23:12.066174 IP 10.200.2.235.49247 > 10.100-78-194.akamai.com.http: Flags [S], seq 2294159276, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 557451322 ecr 0,sackOK,eol], length 0 10:23:12.265640 IP 10.100-78-194.akamai.com.http > 10.200.2.235.49247: Flags [S.], seq 2521908813, ack 2294159277, win 14480, options [mss 1367,sackOK,TS val 388565772 ecr 557451322,nop,wscale 1], length 0 10:23:12.276573 IP 10.200.2.235.49247 > 10.100-78-194.akamai.com.http: Flags [.], ack 1, win 8214, options [nop,nop,TS val 557451534 ecr 388565772], length 0 10:23:12.293030 IP 10.200.2.235.49247 > 10.100-78-194.akamai.com.http: Flags [P.], seq 1:480, ack 1, win 8214, options [nop,nop,TS val 557451552 ecr 388565772], length 479 10:23:12.574773 IP 10.100-78-194.akamai.com.http > 10.200.2.235.49247: Flags [.], ack 480, win 7776, options [nop,nop,TS val 388566081 ecr 557451552], length 0 

METTRE À JOUR:

J'ai fait ce que suggère @BatchyX:

 # iptables -t mangle -nvL Chain PREROUTING (policy ACCEPT 3 packets, 179 bytes) pkts bytes target prot opt in out source destination 173 15993 CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 CONNMARK restore Chain INPUT (policy ACCEPT 3 packets, 179 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 1 packets, 67 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 1 packets, 60 bytes) pkts bytes target prot opt in out source destination 83 5247 MARK all -- * * 0.0.0.0/0 0.0.0.0/0 owner UID match 2000 MARK set 0x3 166 16053 CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 CONNMARK save Chain POSTROUTING (policy ACCEPT 2 packets, 127 bytes) pkts bytes target prot opt in out source destination 

En outre, j'ai désactivé rp_filter pour vpn

 # echo 0 > /proc/sys/net/ipv4/conf/vpn/rp_filter 

C'est mieux maintenant – je reçois des packages SYN, ACK, mais la poignée de main ne semble pas être complétée. De plus, le checksum des packages sortants semble être faux …

Juste comme un indice – c'est un double scénario NAT – je suis NATing packages entrant VPN et mon fournisseur de VPN les NAT avant de les transmettre au monde.

 # tcpdump -vvi vpn tcpdump: listning on vpn, link-type RAW (Raw IP), capture size 65535 bytes 16:27:56.308479 IP (tos 0x10, ttl 64, id 49013, offset 0, flags [DF], proto TCP (6), length 60) 10.200.2.235.58020 > wi-in-f104.1e100.net.http: Flags [S], cksum 0xff0b (incorrect -> 0x9790), seq 3580181028, win 14600, options [mss 1460,sackOK,TS val 12420433 ecr 0,nop,wscale 4], length 0 16:27:56.488691 IP (tos 0x0, ttl 46, id 44196, offset 0, flags [none], proto TCP (6), length 60) wi-in-f104.1e100.net.http > 10.200.2.235.58020: Flags [S.], cksum 0x12a2 (correct), seq 3226424033, ack 3580181029, win 14180, options [mss 1367,sackOK,TS val 1968045661 ecr 12420433,nop,wscale 6], length 0 16:27:56.799066 IP (tos 0x0, ttl 46, id 44197, offset 0, flags [none], proto TCP (6), length 60) wi-in-f104.1e100.net.http > 10.200.2.235.58020: Flags [S.], cksum 0x116c (correct), seq 3226424033, ack 3580181029, win 14180, options [mss 1367,sackOK,TS val 1968045971 ecr 12420433,nop,wscale 6], length 0 

Mise à jour 2:

Comme indiqué précédemment, je reçois SYN, ACK maintenant, mais je ne peux pas compléter la poignée de main avec un package ACK. Donc, si j'ai telnet du count d'user routé, je reçois:

 routed@placebo ~ # telnet 85.214.204.92 80 Trying 85.214.204.92... telnet: Unable to connect to remote host: Connection timed out 

Et le tcpdump correspondant:

 # tcpdump -vvi vpn tcpdump: listning on vpn, link-type RAW (Raw IP), capture size 65535 bytes 20:33:51.940151 IP (tos 0x10, ttl 64, id 65041, offset 0, flags [DF], proto TCP (6), length 60) 10.200.2.235.60547 > korn.vibfolks.eu.http: Flags [S], cksum 0x3014 (incorrect -> 0xe817), seq 151728396, win 14600, options [mss 1460,sackOK,TS val 16109341 ecr 0,nop,wscale 4], length 0 20:33:52.142823 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 60) korn.vibfolks.eu.http > 10.200.2.235.60547: Flags [S.], cksum 0xf897 (correct), seq 986246473, ack 151728397, win 14480, options [mss 1367,sackOK,TS val 62899312 ecr 16109341,nop,wscale 6], length 0 20:33:52.937974 IP (tos 0x10, ttl 64, id 65042, offset 0, flags [DF], proto TCP (6), length 60) 10.200.2.235.60547 > korn.vibfolks.eu.http: Flags [S], cksum 0x3014 (incorrect -> 0xe71d), seq 151728396, win 14600, options [mss 1460,sackOK,TS val 16109591 ecr 0,nop,wscale 4], length 0 20:33:53.140728 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 60) korn.vibfolks.eu.http > 10.200.2.235.60547: Flags [S.], cksum 0xf79e (correct), seq 986246473, ack 151728397, win 14480, options [mss 1367,sackOK,TS val 62899561 ecr 16109341,nop,wscale 6], length 0 20:33:53.341764 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 60) korn.vibfolks.eu.http > 10.200.2.235.60547: Flags [S.], cksum 0xf76b (correct), seq 986246473, ack 151728397, win 14480, options [mss 1367,sackOK,TS val 62899612 ecr 16109341,nop,wscale 6], length 0 

Mais l'user non routé se connecte sans problème:

 nonrouted@placebo ~ $ telnet 85.214.204.92 80 Trying 85.214.204.92... Connected to 85.214.204.92. Escape character is '^]'. ^] telnet> quit Connection closed. 

Mise à jour 3

J'ai ajouté des règles de journalisation dans les tables mangle et nat pour savoir où les packages se perdent.

Je me connecte mangle avant et après le marquage (basé sur uid), dans la postruting natale (basé sur l'iface) dans manigle prerouting (basé sur dans l'iface) et dans mangle input and forward (basé sur la marque restaurée)

 Dec 9 01:00:55 placebo kernel: [80760.497780] [VPN mangle OUTPUT pre] IN= OUT=lan SRC=192.168.0.5 DST=85.214.204.137 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=30041 DF PROTO=TCP SPT=48700 DPT=80 SEQ=3158481901 ACK=0 WINDOW=14600 RES=0x00 SYN URGP=0 OPT (020405B40402080A0132EEB40000000001030304) Dec 9 01:00:55 placebo kernel: [80760.497819] [VPN mangle OUTPUT post] IN= OUT=lan SRC=192.168.0.5 DST=85.214.204.137 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=30041 DF PROTO=TCP SPT=48700 DPT=80 SEQ=3158481901 ACK=0 WINDOW=14600 RES=0x00 SYN URGP=0 OPT (020405B40402080A0132EEB40000000001030304) MARK=0x3 Dec 9 01:00:55 placebo kernel: [80760.497875] [VPN nat POSTROUTING] IN= OUT=vpn SRC=192.168.0.5 DST=85.214.204.137 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=30041 DF PROTO=TCP SPT=48700 DPT=80 SEQ=3158481901 ACK=0 WINDOW=14600 RES=0x00 SYN URGP=0 OPT (020405B40402080A0132EEB40000000001030304) MARK=0x3 Dec 9 01:00:55 placebo kernel: [80760.695265] [VPN mangle PREROUTING pre] IN=vpn OUT= MAC= SRC=85.214.204.137 DST=10.200.2.235 LEN=60 TOS=0x00 PREC=0x00 TTL=50 ID=0 DF PROTO=TCP SPT=80 DPT=48700 SEQ=3597895441 ACK=3158481902 WINDOW=14480 RES=0x00 ACK SYN URGP=0 OPT (020405570402080A03FCE5720132EEB401030306) Dec 9 01:00:55 placebo kernel: [80760.695305] [VPN mangle PREROUTING post] IN=vpn OUT= MAC= SRC=85.214.204.137 DST=10.200.2.235 LEN=60 TOS=0x00 PREC=0x00 TTL=50 ID=0 DF PROTO=TCP SPT=80 DPT=48700 SEQ=3597895441 ACK=3158481902 WINDOW=14480 RES=0x00 ACK SYN URGP=0 OPT (020405570402080A03FCE5720132EEB401030306) MARK=0x3 

Conntrack montre:

 # conntrack -L --output extended | grep 85.214.204.137 | grep tcp ipv4 2 tcp 6 59 SYN_RECV src=192.168.0.5 dst=85.214.204.137 sport=48724 dport=80 src=85.214.204.137 dst=10.200.2.235 sport=80 dport=48724 mark=3 use=1 

Conclusion – les packages ne parviennent jamais à INPUT … pourquoi? mauvais routing?

3 Solutions collect form web for “Routage des politiques Linux – les packages ne reviennent pas”

Assurez-vous que votre routing est symésortingque ou désactivez le filtrage du path inverse (uniquement si vous savez ce que vous faites, car la correction de votre routing est toujours un meilleur choix).

Faisons le test, avec le trafic provenant de 192.168.0.33:

192.168.0.33 -> 192.178.100.10 iif eth0

Le filtrage du path inverse est activé par défaut dans ubuntu. Il inverse l'adresse source et de destination, et essayer de sélectionner un itinéraire comme s'il avait un package avec ces sources et l'adresse de destination. Si l'interface ne correspond pas à l'interface sur laquelle le package a été reçu, le package est considéré comme falsifié.

Donc, le kernel tente d'apather 192.178.100.10 -> 192.168.0.33 … le tableau principal de searchs … trouve l'input 192.168.0.0/24 via eth0, qui est également l'interface sur laquelle le package a été reçu, donc le package n'est pas abandonné.

donc vous NAT et envoyez 10.200.2.235 -> 192.178.100.10 sur l'interface VPN. le programme VPN encapsule cela et envoie ceci comme 192.168.0.5 -> remotevpn. Maintenant, vous recevez une réponse de votre vpn à partir de la même interface. Le filtrage du path inverse sera évidemment adopté ici. le VPN décapsule les résultats (192.178.100.10 -> 10.200.2.235), puis NAT se déroulera, mangling le package pour restaurer l'adresse de destination d'origine. Ensuite, vous avez un filtrage de path inverse sur le package résultant:

192.178.100.10 -> 192.168.0.33 iff vpn

Essayons d'apather 192.168.0.33 vers 192.178.100.10 … la table de search VPN … par défaut via 10.200.0.1 qui est sur dev vpn: PASS.

Maintenant, vous souhaitez faire des choses de votre hôte, en tant que 192.168.0.5 ou 10.200.2.235 avec la marque 3. Vous l'envoyez à votre VPN, qui envoie cela de 192.168.0.5 à la télécommand vpn. Vous obtenez une réponse de la même manière, puis VPN décapsule (192.178.100.10 -> 192.168.0.5 (ou 10.200.2.235)), puis le filtrage du path inverse sera effectué.

192.168.0.5 ou 10.200.2.235 -> 192.178.100.10 … ne search pas de table VPN (il n'a pas de marque et ne provient pas de 192.168.0.32/27), donc il finit dans le tableau principal, qui lui dit d'utiliser interface eth0. Le filtrage du path inverse échoue, de sorte que le package est supprimé en tant que tentative de falsification de source IP. Ainsi, vous ne voyez pas les résultats.

En ce qui concerne pourquoi tcpdump ne montre pas ces packages … peut-être il existe également un problème de routing sur le point final VPN.

En ce qui concerne une solution, dans votre cas, j'utiliserais la marque de connection de conntrack et définir la marque du package entrant sur la marque de la connection de conntrack:

 # keep that rule OUTPUT -m owner .... -j MARK 0x3 # add this one after the previous one: it saves the current mark into connmark OUTPUT -j CONNMARK --save-mark # and add this one (in mangle), which sets the mark to the connmark # if conntrack determines that it is from the same connection. PREROUTING -j CONNMARK --restore-mark 

MODIFIER:

Vous ne devriez pas avoir à désactiver le filtrage du path inverse pour que cette solution iptables fonctionne. Désactiver rp_filter inutilement n'est pas un bon moyen de résoudre des problèmes, il ne les masque que.

Maintenant, pour le hasard:

  • Je continue à faire des suppositions quant à l'adresse IP utilisée par vos programmes. Trouvez un programme qui imprime effectivement l'adresse IP source qu'il utilise. Cela ou dites à telnet de se lier à 192.168.0.35 ou au 10.200.2.235. tcpdump affichera seulement le package sortant une fois qu'il est NATed, et ne montrera que le package entrant avant qu'ils ne soient NON NON, donc il ne vous dit pas lequel est réellement utilisé. En tant que solution experte, vous pouvez également essayer de mettre nflog dans une string et examiner avec tcpdump ce qui se trouve dans cette string.

  • Ne masclatez pas tout ce qui va vers vpn, seules les choses qui ne proviennent pas de l'IP ou du sous-réseau de vpn . Masquer votre propre trafic car votre propre trafic semble inutile. Peut-être que conntrack est confus par cela.

OK a fonctionné … Je ne sais toujours pas ce que j'ai fait mal auparavant. De toute façon, pour fonctionner, j'ai utilisé:

 iptables -t mangle -A OUTPUT -m owner --uid-owner 2000 -j MARK --set-mark 3 iptables -t nat -A POSTROUTING -o vpn -j MASQUERADE ip rule add fwmark 3 lookup VPN ip route add default via xxxx table VPN sysctl -w net.ipv4.conf.vpn.rp_filter=2 

J'espère que cela aide les autres aussi.

Je pense que ce qui doit être clarifié est le rôle de:
voir p116 de Gheorghe "Conception et implémentation de pare-feu linux et QoS …")

Chaîne d'ENTRÉ de nat: (jamais mentionnée dans la page de manuel de Fedora 18)
et
Chaîne INPUT de mangle: (pour les packages entrant dans la boîte elle-même selon la page de manuel iptables)

Quelle est leur relation avec la string INPUT de la table de filtrage ?

et
la string FORWARD et la string FORWARD de FORWARD de Mangle.
Quelle est la différence entre les deux strings FORWARD?
(Ok, j'ai trouvé une réponse, mais quelqu'un pourrait-il examiner cela: http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_: Ch14 : _Linux_Firewalls_Using_iptables # .UMUF0HTqOIU )

  • Pourquoi est-ce que je reçois une erreur de permission refusée?
  • Le conteneur lxc ne démarre pas car - lxc_conf - n'a pas configuré la console
  • Besoin d'append un nouvel hdd sur le server Ubuntu existant 12.04
  • L'invité kvm ne peut pas se connecter à l'extérieur de l'hôte, vice versa
  • Impossible d'installer nginx + php5-fpm dans une nouvelle installation pour get 404
  • Pauvres fonctionnalités d'E / S invitées KVM Ubuntu 12.04
  • Charge élevée due à l'attente d'E / S dans Ubuntu 12.04 sur l'instance EC2
  • La meilleure façon de récupérer mysql à partir d'un "chmod -R 777 /" avec des bases de données intactes
  • La configuration Dovecot (avec Postfix) a une connection refusée lors de l'access à auth-userdb
  • Quelle fonction doit être désactivée / activée dans php.ini pour les servers d'hébergement Web?
  • Mis à niveau vers Ubuntu 12.04 à partir de 10.04 et doit transférer la database de Postgresql 8.4 vers 9.1
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.