cerhu > linux.debian.user.french

Olivier (11/07/2019, 13h00)
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 connectant 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 message 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 connecter 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 permetde
détecter le problème corrigé par la cible -j TCPMSS --clamp-mss-to-pmtu de
mes règles iptables ?

[1] [..]

Slts
Bernard Schoenacker (11/07/2019, 14h10)
----- Mail original -----

> De: "Olivier" <oza.4h07>
> À: "ML Debian User French" <debian-user-french>
> Envoyé: Jeudi 11 Juillet 2019 12:53:26
> Objet: Quel test unitaire illustre le problème que corrige "-j TCPMSS
> --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 connectant
> 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 message 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 connecter 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] [..]


> Slts


bonjour,

serait il possible de régler le mtu à 1492 sur la passerelle ?
doc à peut près correcte :
[..]

[..]

exemple de conf :
[..]

remarque: je le fait d'après mes souvenirs lorsqu'il fallait utiliser
rpppoe

merci

slt
bernard
Olivier (11/07/2019, 14h40)
Le jeu. 11 juil. 2019 à 14:04, Bernard Schoenacker <
bernard.schoenacker> a écrit :

> bonjour,
> 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" .
En commentant-décommentant ma commande iptables, l'accès au site web marche
ou non.

Par ailleurs, j'ai :
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, mtu=1492

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
(le hack iptables ne change rien à cet égard).
ping -M do -s 1464 192.168.4.254
PING 192.168.4.254 (192.168.4.254) 1464(1492) bytes of data.
1472 bytes from 192.168.4.254: icmp_seq=1 ttl=64 time=1.21 ms
Pascal Hambourg (13/07/2019, 07h10)
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 (13/07/2019, 07h20)
Le 11/07/2019 à 14:38, Olivier a écrit :
> Le jeu. 11 juil. 2019 à 14:04, Bernard Schoenacker <
> 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, mtu=1492
> 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.
Discussions similaires
Test unitaire

Test Unitaire des Web Services (WSE 3.0) Bugg ?

Mon Nom de famille est systématiquement modifié par n'importe quel mot corrigé du Correcteur Orthographique

Quel programme corrige les erreurs d'encodage ?


Fuseau horaire GMT +2. Il est actuellement 06h26. | Privacy Policy