Problématique
L'utilisation de tunnel sur un niveau 2 non maitrisé implique de l'encapsulation de paquet. Cette encapsulation de paquet ajoute un surplus d'octets pour chaque paquet augmentant ainsi la taille de chaque paquet transitant sur le tunnel. Hors la taille des paquets encapsulé dans nos tunnels est limitée à 1500 - entêtes gre - entêtes ipsec.
Afin de ne pas dégrader les performances des tunnels ipsec, nous avons volontairement limité le mtu des interfaces gre à 1300 (cela pourrait être un peu plus). Ceci garanti que les paquets transitent par les interfaces gre ne seront pas fragmenté en passant sur le tunnel ipsec correspondant.
Le problème actuel réside alors dans le transfert de paquets sur plusieurs segments ethernet ayant des "path mtu" différents. Le protocle pmtud n'est pas une solution viable à elle seule car bon nombre d'opérateur internet filtre les paquets icmp type 3 code 4, nécessaire à son bon fonctionnement.
mtu mtu mtu mtu
1500 1300 1500 ????
<membre> ---- soupirail ---- passavant|batture ---- internet .... <destination>
Solutions possibles
Réduire le mtu des interfaces de chacunes des machines à celle des tunnels gre : C'est la solution qui résoudra la problème pour tous les protocles. Elles nécessitent par contre d'imposer un mtu pour les machines se trouvant derrière grenode.
- Modifier les paquets tcp passant par les tunnels pour imposer un mss
- inférieur à ceux possibles sur les tunnels gre** ( < 1300 - entêtes tcp/ip)
- cette solution permet ne pas imposer un mtu sur les machines derrières les tunnels mais règles le problème uniquement pour les connexions tcp.
Je préconise la première solution qui est simple à mettre en oeuvre.
toutes les intefaces eth1.* (sauf eth1.50, eth1.51, eth1.900) sur soupirail ainsi que toutes les interfaces réseaux des machines membres sont à modifier pour définir un mtu à 1300 (où peut-être affiner le calcul du mtu sur les tunnel gre pour optimiser l'overhead).
Deux références intéressantes :
- http://www.bortzmeyer.org/mtu-et-mss-sont-dans-un-reseau.html
- http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml
Après lecture approfondie, il semble que cela soit plus fin que ça et que le problème ne concerne justement que les connexions TCP. Et que, par conséquent la deuxième solution que tu proposes me semble meilleure car moins contraignante. Elle est documentée dans les deux articles que je propose.
Je m'explique. En fait, de base, dans le protocol IP, il y a un mécanisme de fragmentation de paquet qui fonctionne très bien mais qui diminue les performances des routeurs, notament les routeurs à fort trafic. C'est pour cela que, pour TCP, le protocole PMTUD (Path MTU Discovery) permet d'ajuster automatiquement la taille des segments pour que les paquets ne soient pas fragmentés. Lorsque PMTUD est utilisé le drapeau DF (Don't fragment) est activé, ce qui empêche les routeurs de fragmenter et ce qui fait que les gros paquets sont jetés lorsque l'ICMP est filtré (c'est le cas avec moncompte.laposte.net).
Notre problème se situe seulement dans le cas ou le drapeau DF est activé. En effet, dans les autres cas (comme avec l'utilisation normal d'UDP) les paquets trop gros sont fragmentés.
Le cas de compte.laposte.net
Attention on est dans le cas d'un routage assymétrique, ça sort par batture et ça revient par passavant.
solution 1: mise en pratique
solution 2: mise en pratique
Il suffit de changer la variable CLAMPMSS dans le fichier /etc/shorewall/shorewall.conf de soupirail.
CLAMPMSS=yes
Le calcul du MSS automatique ne fonctionne pas. Pourquoi ? Cela reste à définir.
CLAMPMSS=1200, CLAMPMSS=1100
Affecter la variable CLAMPMSS à 1100 sur shorwall et constater que cela fonctionne. Par contre, pourquoi 1100 ? À 1200 cela ne fonctionne pas. Cela reste à creuser...
Dans le cas du MSS de 1200, compte.laposte.net respecte bien le MSS, mais passavant répond need to frag sur la base d'un MTU de 1206 (donc d'un MSS de 1166). La question est pourquoi passavant calcule un MTU de 1206 alors que le plus bas de la chaine semble être 1300.
solution3:
mtu à 1400 sur tous les tunnels et clampmss à 1360 :
up ip link set $IFACE mtu 1400
up iptables -t mangle -A POSTROUTING -o $IFACE -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360
Remarques
On pourrait aussi imaginer un soft de tunnel qui compresse les paquets entre nos routeurs (comme par exemple openvpn). Vu que nous avons un débit faible actuellement, cela permettrait d'améliorer le débit. Enfin reste quand même à étudier le gain que cela apporte...