Quel test unitaire illustre le problème que corrige "-j TCPMSS --clamp-mss-to-pmtu" ?

Le
Olivier
--00000000000026b231058d659b9b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Bonjour,

Dans mon labo, j'ai mis en place un environnement qui simule une connexion
d'Orange s'appuyant sur PPPoE.

Tout à fait par hasard, en jouant le rôle d'utilisateur se connec=
tant avec
son terminal à cet environnement, je me suis rendu compte que pouvais
surfer sur de multiples sites web (lemonde.fr, ) et que j'échouais
systématiquement sur l'un d'eux.

Poutant, en me connectant à ce site, via un autre réseau local, l=
a
connexion s'établissait normalement.

Avec des captures Wireshark, j'ai vu que dans l'environnement en défau=
t, un
message "ICMP Don't Fragment" était émis. Ce message m'a fait pen=
ser à un
problème de MTU.
En me documentant sur des problèmes de MTU, j'ai découvert dans [=
1] le MSS
Clamping.
En ajoutant à un firewall la règle ci-après, j'ai pu me conn=
ecter au site
web qui posait problème.

iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o ppp0 -j
TCPMSS --clamp-mss-to-pmtu

Cette anomalie découverte par hasard me donne envie d'avoir une m=
thode
plus rationnelle pour vérifier le bon fonctionnement d'un service r=
seau.

Plus spécifiquement, j'aimerai a minima, savoir quelle commande permet=
de
détecter le problème corrigé par la cible -j TCPMSS --clamp-=
mss-to-pmtu de
mes règles iptables ?

[1] https://inetdoc.net/guides/iptables-tutorial/tcpmsstarget.html

Slts

--00000000000026b231058d659b9b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir="ltr"><div>Bonjour,</div><div><br></div><div>Dans mon labo, j&#3=
9;ai mis en place un environnement qui simule une connexion d&#39;Orange s&=
#39;appuyant sur PPPoE.</div><div><br></div><div>Tout à fait par hasar=
d, en jouant le rôle d&#39;utilisateur se connectant avec son terminal=
à cet environnement, je me suis rendu compte que pouvais surfer sur d=
e multiples sites web (<a href="http://lemonde.fr">lemonde.fr</a>, ) e=
t que j&#39;échouais systématiquement sur l&#39;un d&#39;eux.</di=
v><div><br></div><div>Poutant, en me connectant à ce site, via un autr=
e réseau local, la connexion s&#39;établissait normalement.<br></=
div><div><br></div><div>Avec des captures Wireshark, j&#39;ai vu que dans l=
&#39;environnement en défaut, un message &quot;ICMP Don&#39;t Fragment=
&quot; était émis. Ce message m&#39;a fait penser à un probl=
ème de MTU.</div><div>En me documentant sur des problèmes de MTU,=
j&#39;ai découvert dans [1] le MSS Clamping.</div><div>En ajoutant =
à un firewall la règle ci-après, j&#39;ai pu me connecter au=
site web qui posait problème.<br></div><div><br></div><div>iptables -=
t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o ppp0 -j TCPMSS --=
clamp-mss-to-pmtu</div><div><br></div><div>Cette anomalie découverte p=
ar hasard me donne envie d&#39;avoir une méthode plus rationnelle pour=
vérifier le bon fonctionnement d&#39;un service réseau.</div><di=
v><br></div><div>Plus spécifiquement, j&#39;aimerai a minima, savoir q=
uelle commande permet de détecter le problème corrigé par la=
cible -j TCPMSS --clamp-mss-to-pmtu de mes règles iptables ?<br></div=
><div><br></div><div>[1] <a href="https://inetdoc.net/guides/iptables-tut=
orial/tcpmsstarget.html">https://inetdoc.net/guides/iptables-tutorial/tcpms=
starget.html</a></div><div><br></div><div>Slts<br></div></div>

--00000000000026b231058d659b9b--
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Bernard Schoenacker
Le #26521332
----- Mail original -----
De: "Olivier" À: "ML Debian User French" Envoyé: Jeudi 11 Juillet 2019 12:53:26
Objet: Quel test unitaire illustre le problème que corrige "-j TCPMS S
--clamp-mss-to-pmtu" ?
Bonjour,
Dans mon labo, j'ai mis en place un environnement qui simule une
connexion d'Orange s'appuyant sur PPPoE.
Tout à fait par hasard, en jouant le rôle d'utilisateur se conn ectant
avec son terminal à cet environnement, je me suis rendu compte que
pouvais surfer sur de multiples sites web ( lemonde.fr , ...) et que
j'échouais systématiquement sur l'un d'eux.
Poutant, en me connectant à ce site, via un autre réseau local, la
connexion s'établissait normalement.
Avec des captures Wireshark, j'ai vu que dans l'environnement en
défaut, un message "ICMP Don't Fragment" était émis. Ce me ssage m'a
fait penser à un problème de MTU.
En me documentant sur des problèmes de MTU, j'ai découvert dans [1]
le MSS Clamping.
En ajoutant à un firewall la règle ci-après, j'ai pu me co nnecter au
site web qui posait problème.
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o
ppp0 -j TCPMSS --clamp-mss-to-pmtu
Cette anomalie découverte par hasard me donne envie d'avoir une
méthode plus rationnelle pour vérifier le bon fonctionnement d' un
service réseau.
Plus spécifiquement, j'aimerai a minima, savoir quelle commande
permet de détecter le problème corrigé par la cible -j TCP MSS
--clamp-mss-to-pmtu de mes règles iptables ?
[1] https://inetdoc.net/guides/iptables-tutorial/tcpmsstarget.html
Slts


bonjour,
serait il possible de régler le mtu à 1492 sur la passerelle ?
doc à peut près correcte :
https://askubuntu.com/questions/826525/how-do-i-increase-pppoe-mtu
https://samuel.kadolph.com/2015/02/mtu-and-tcp-mss-when-using-pppoe-2/
exemple de conf :
https://blog.confirm.ch/using-pppoe-on-linux/
remarque: je le fait d'après mes souvenirs lorsqu'il fallait utiliser
rpppoe
merci
slt
bernard
Pascal Hambourg
Le #26521444
Le 11/07/2019 à 12:53, Olivier a écrit :
Avec des captures Wireshark, j'ai vu que dans l'environnement en défaut, un
message "ICMP Don't Fragment" était émis.

Ça m'étonnerait. Ce type de message n'existe pas. Tu dois confondre avec
"Fragmentation needed but DF (Don't Fragment) set".
Plus spécifiquement, j'aimerai a minima, savoir quelle commande permet de
détecter le problème corrigé par la cible -j TCPMSS --clamp-mss-to-pmtu de
mes règles iptables ?

Il n'existe pas de commande qui détecte le problème à coup sûr. Cette
cible contourne un problème de gestion de MTU qui se situe dans le sens
descendant : l'émetteur distant n'est pas informé que les paquets qu'il
envoie sont trop gros (soit à cause d'un trou noir de MTU causé par un
pontage PPPoe-PPP par exemple, soit à cause d'un routeur qui ne renvoie
pas de message ICMP "Fragmentation needed" à l'émetteur, soit à cause
d'un filtrage de ce message entre le routeur et l'émetteur, soit parce
que l'émetteur ne tient pas compte de ce message).
Envoyer un gros ping avec -M do (fragmentation interdite) est vain : le
ping sera bloqué dès l'émission alors que le problème à détecter se
situe en réception. Envoyer un gros ping fragmenté a plus de chances de
détecter quelque chose : la cible devrait envoyer une réponse fragmentée
mais en cas de problème seul le petit fragment sera reçu par l'interface
PPPoE.
Pascal Hambourg
Le #26521445
Le 11/07/2019 à 14:38, Olivier a écrit :
Le jeu. 11 juil. 2019 à 14:04, Bernard Schoenacker <
a écrit :
serait il possible de régler le mtu à 1492 sur la passerelle ?

Sauf erreur, le MTU était déjà réglé à 1492 sur le lien ppp0, si j'en crois
la sortie d' "ip link" .

Evidemment, sinon l'option --clamp-mss-to-pmtu serait sans effet.
ping -M do -s 1492 192.168.4.254
PING 192.168.4.254 (192.168.4.254) 1492(1520) bytes of data.
ping: local error: Message too long, mtu92
où 192.168.4.254 est l'IP de mon serveur PPPoE (sur lequel le MTU est aussi
valorisé à 1492).
La valeur la plus grande pour laquelle le ping ci-dessus réussit est 1464

1464 + 8 (en-tête ICMP) + 20 (en-tête IPv4) = 1492
(le hack iptables ne change rien à cet égard).

Normal, il n'affecte que les paquets TCP.
Effectivement, le mot est juste : c'est un hack.
Publicité
Poster une réponse
Anonyme