Comment faire fonctionner plusieurs liaisons montantes iproute2 avec masquerading

Question

J'ai le problème suivant avec routage + NAT: Si j'ai deux ISP et j'utilise deux nexthop en route par défaut avec MASQUERADE sur les deux liens ISP, je vois le routage le cache est régénéré, mais parfois les paquets envoyés à un nouveau lien (après la régénération du cache) utilisent une mauvaise adresse source pour le masquage.

Voici la config.

J'ai deux liens vers l'extérieur par deux fournisseurs différents: eth1 et eth2 eth0 est le réseau local

$ ip une (partie de la production, puisque nous avons plus de 3 interfaces désactivées)
2: eth1: 1500 mtu qdisc pfifo_fast qlen 1000
iNet 192.168.1.254/24 BRD portée 192.168.1.255 eth1 mondiale
3: eth2: 1500 mtu qdisc pfifo_fast qlen 1000
iNet 192.168.2.254/24 BRD 192.168.2.255 champ eth2 global
6: eth0: 1500 mtu qdisc pfifo_fast qlen 1000
iNet 192.168.5.1/24 BRD 192.168.5.255 portée mondiale eth0

tables Roting:

$ ip r 192.168.5.0/24 dev eth0 proto noyau lien src étendue 192.168.5.1
192.168.2.0/24 dev eth2 scope link proto noyau src 1 92.168.2.254
192.168.1.0/24 dev eth1 lien de portée proto noyau src 192.168.1.254
défaut nexthop via 192.168.1.1 dev eth1 poids 1
nexthop via 192.168.2.1 dev eth2 poids 1

premier ip $ eth1
par défaut 192.168.1.1 dev eth1

$ ip premier eth2
par défaut 192.168.2.1 dev eth2

Règles:

$ ip ru
0: de toute recherche locale
32450: de 192.168.2.254 recherche eth2
32717: de 192.168.5.124 recherche eth1
32766: de tous rechercher principale
32767: de toute défaut de recherche

Q1: si je fais pings à partir de deux PC dans LAN: 5.137 et 5.147, au même IP (195.60.1.1) comment peuvent-ils aller via des liens différents (ping 195.60.1.1 est exécuté sur les deux ordinateurs) ?

$ ip rg 195.60.1.1 de 192.168.5.137 ssi eth0
195.60.169.6 de 192.168.5.137 via 192.168.1.1 dev eth1 src 192.168.5.1
cache mtu 1500 advmss 1460 HOP 128 ssi eth0

$ ip rg 195.60.1.1 de 192.168.5.147 ssi eth0
195.60.169.6 de 192.168.5.147 via 192.168.2.1 dev eth2 src 192.168.5.1
cache mtu 1500 advmss 1460 HOP 128 ssi eth0

Le routage dans mon cas doit être la même pour tous les utilisateurs. il devrait toujours envoyer des paquets à la même destination via le même lien (même si l'IP source est différente). n'est-ce pas?

Q2: Parfois, je vois dans tcpdump sur des interfaces externes que le cache de routage a été régénéré. Cela peut être forcé par ip r t t cache. Cela entraîne parfois un changement du lien pour mes pings. Mais l'une des deux machines perd soudainement la connexion. De tcpdump Je trouve que cela se produit parce que le routage a décidé d'utiliser un autre lien, mais la Mascarade était pas à jour selon:

$ tcpdump -i eth1
IP 192.168.2.254 > 195.60.1.1 : Requête d'écho ICMP, id 10677, seq 242, longueur 64
IP 192.168.1.254> 195.60.1.1: requête d'écho ICMP, id 37387, seq 244, longueur 64 IP 195.60.1.1> 192.168.1.254: réponse d'écho ICMP, id 37387, seq 244, longueur 64

Les deuxième et troisième paquets sont demande de réponse de/à 5,137

Le premier paquet est la demande de .5.147 avec mauvaise adresse source sur cette interface en raison Masquerade pas mis à jour après la purge du cache de routage - par conséquent, pas de réponse, car l'adresse source du paquet MASQUERADEd est fausse.

Voici mon MASCARADE mise

$ iptables -L -t nat
chaîne POSTROUTING (politique ACCEPTER 752K paquets, 48M octets)
pkts octets opt prot cible destination source sur
2840K 256M MASQUERADE tous - tout eth1 192.168.5.0/24 partout
2491K tous Masquerade 229 M - tout eth2 192.168.5.0/24 partout

Je comprends que je peux utiliser conntrack pour marquer des paquets, mais c'est un peu plus compliqué. Je préférerais utiliser IP de destination comme clé pour le routage. Quel est le problème dans ce scénario? pourquoi les purges de cache de routage n'informent pas le moteur NAT des modifications de routage?

Answer 1

Ok, la réponse a finalement été trouvée en utilisant les moteurs de recherche.

Ce comportement particulier est un bogue dans le noyau Linux connu au moins depuis 2005. Julian Anastasov a écrit un patch pour contourner cette erreur (voir http://www.ssi.bg/~ja/#routes)

Quoi qu'il en soit, il a été constaté que le scénario choisi avec l'équilibrage de charge et NAT n'est pas bon, car il peut casser l'autorisation sur certains sites et scintille Jabber et Skype en raison du retrait des routes entraînant des changements d'itinéraires pour chaque destination (puisque nous utilisons NAT, l'IP externe change aussi et Skype et d'autres services voient vous comme connecté à partir d'un autre ordinateur).

Une meilleure façon de partager plusieurs liens sur un grand bureau est de diviser les utilisateurs par canaux. Ainsi, nous avons assigné un canal préféré pour chaque ordinateur de notre réseau et si ce canal n'est pas en place, nous choisissons un autre canal pour l'ordinateur. Cette stratégie conserve la même adresse IP externe (après NATing) pour chaque ordinateur de notre réseau. La mise en place d'un canal préféré nous permet d'envoyer des employés critiques via des canaux plus rapides, tandis que les employés traitent de gros fichiers sur des canaux à faible cos mais lents. Nous utilisons 4 canaux, puisque tous les FAI de notre région descendent au moins 2 fois par semaine pendant plusieurs heures.