Possible problème de MTU

Le
dyrmak
Bonjour,

J'ai un problème sous Linux sur mon serveur de courrier,
certains domaines "archi-connus" pour ne pas les citer, laissent
dans mes logs la trace comme quoi ils se sont bien connectés au serveur,
mais ne peuvent pas transmettre leurs messages, EOM: connection
closed prematurely, j'y trouve le nom du serveur et l'adresse
des personnes qui voulaient envoyer un message.

La solution à ce problème n'est pas aisée et selon les recherches
que j'ai faites plusieurs pistes seraient à explorer, certaines
solutions signalent des problèmes avec sendmail lui-même, mais
ma configuration de sendmail ne semble pas être en cause, les gens
qui m'écrivent doivent m'écrire, ce ne sont pas de spammeurs.

Une autre solution parle de modifier les paramètres
suivants que j'ai déjà modifiés avec les valeurs suivantes.

sysctl -w net.ipv4.tcp_keepalive_time`0
sysctl -w net.ipv4.tcp_keepalive_intvl`
sysctl -w net.ipv4.tcp_keepalive_probes

L'ennui c'est que les logs ont toujours le même message
SYSERROR:ROOT EOM:connection closed prematurely.

À ce niveau, je me demande si les valeurs que j'ai mises
sont disparates, auquel cas par exemple je ferais passer
la valeur 600 à 14400 par exemple.

Compte tenu que ces paramètres n'empêchent pas les autres
messages d'atteindre le serveur, je me dis que ces paramètres
ne changent pas de toutes façons la donne, ce qui me conduit
à envisager une autre piste concernant le MTU.

Dans ce cas, sendmail et sa configuration n'y sont pour
rien, ce n'est pas un problème de traitement software qui
en serait la cause, cependant intervient dans le même temps
une. Disons une procédure de "découverte de chemin MTU"
afin d'éviter la fragmentation de paquets mais que quelqu'un entre
mon réseau et le réseau d'en face ne fait pas bien ce contrôle
et laisse passer les gros morçeaux sans de-fragmenter. Ces
gros morçeaux par définition ne passent pas , personne n'en est
averti et la connexion finit par se fatiguer et lâche.

Il faudrait dans ce cas imposer soit même la valeur du MTU
en cherchant le plus petit possible. En admettant que je trouve
un MTU 1460 à partir duquel je n'ai plus de fragmentation et
que je modifie ma carte réseau pour réfleter ce changement
est-ce je dois modifier de la sorte toutes les interfaces réseaux
de mon réseau local y compris le routeur? Je ne sais
pas d'ailleurs s'il est possible de modifier le MTU
d'un routeur.

Si vous connaissez une autre solution à ce problème de réception
j'en serait très intéressé, merci de toutes façons de m'avoir lu, c'est
un peu long.

dyrmak
--
¿ Cómo era aquello del rayo verde ?
++++ ++++
Linux operating system
++++ ++++
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Hambourg
Le #25170322
Salut,

dyrmak a écrit :

J'ai un problème sous Linux sur mon serveur de courrier,
certains domaines "archi-connus" pour ne pas les citer, laissent
dans mes logs la trace comme quoi ils se sont bien connectés au serveur,
mais ne peuvent pas transmettre leurs messages, EOM: connection
closed prematurely, j'y trouve le nom du serveur et l'adresse
des personnes qui voulaient envoyer un message.


[...]
ce qui me conduit
à envisager une autre piste concernant le MTU.



C'est plausible. Au début de la connexion les segments échangés sont de
petite taille (commandes SMTP et réponses), puis de taille maximum lors
du transfert des données.

Il faudrait dans ce cas imposer soit même la valeur du MTU
en cherchant le plus petit possible. En admettant que je trouve
un MTU 1460 à partir duquel je n'ai plus de fragmentation et
que je modifie ma carte réseau pour réfleter ce changement
est-ce je dois modifier de la sorte toutes les interfaces réseaux
de mon réseau local y compris le routeur?



Normalement, toutes les interfaces d'un même réseau doivent avoir la
même valeur de MTU. J'ai rencontré deux cas. Soit la valeur de MTU
n'agit que sur l'émission et l'interface peut toujours recevoir des
paquets de la taille maximum normale (1500 en ethernet sauf jumbo
frames), soit elle agit aussi sur la réception (ce qui est stupide AMA),
ce qui peut poser des problèmes. Normalement en TCP cela n'est pas
gênant puisque la valeur de MTU intervient dans le calcul du MSS annoncé
qui va limiter la taille des segments émis par l'autre côté (c'est
d'ailleurs le but de cette opération). Enfin, je me méfierais des
interfaces qui font du TCP segment offloading, qui pourraient modifier à
la volée les MTU, MSS et tailles de segments.

Une autre possibilité que modifier la valeur de MTU globale de
l'interface est d'agir sur le réglage de MTU ou MSS de la route par
défaut (cf. commandes route ou ip route).

Encore une autre possibilité consiste à utiliser une règle iptables avec
la cible TCPMSS pour modifier à la volée la valeur de MSS des connexions
TCP.

Je ne sais pas d'ailleurs s'il est possible de modifier le MTU
d'un routeur....



Rien ne l'interdit a priori, cela dépend du modèle et de ses options de
configuration.
dyrmak
Le #25186602
En 50 lignes Pascal Hambourg a écrit
dans news:ke0cr5$ksa$
le samedi, 26 janvier 2013 à 11:57:36 :


Normalement, toutes les interfaces d'un même réseau doivent avoir la
même valeur de MTU. J'ai rencontré deux cas. Soit la valeur de MTU
n'agit que sur l'émission et l'interface peut toujours recevoir des
paquets de la taille maximum normale (1500 en ethernet sauf jumbo
frames), soit elle agit aussi sur la réception (ce qui est stupide AMA),
ce qui peut poser des problèmes. Normalement en TCP cela n'est pas
gênant puisque la valeur de MTU intervient dans le calcul du MSS annoncé
qui va limiter la taille des segments émis par l'autre côté (c'est
d'ailleurs le but de cette opération). Enfin, je me méfierais des
interfaces qui font du TCP segment offloading, qui pourraient modifier à
la volée les MTU, MSS et tailles de segments.

Une autre possibilité que modifier la valeur de MTU globale de
l'interface est d'agir sur le réglage de MTU ou MSS de la route par
défaut (cf. commandes route ou ip route).

Encore une autre possibilité consiste à utiliser une règle iptables avec
la cible TCPMSS pour modifier à la volée la valeur de MSS des connexions
TCP.




Bonjour.

Tout d'abord, merci de votre intervention, elle a réglé
le problème.

Je pense que j'ai tenu compte de vos remarques à savoir:

- Problème MTU tout à fait possible.
- Pas de jumbo frame sur le serveur.
- Pas de tcp-segmentation-offload sur le serveur.

À partir de là, je me suis efforcé de limiter les
modifications globales pour éviter tout effet secondaire
qui serait susceptible de se produire.

J'ai donc vérifié que le modem-routeur-firewall laisse
passer les ICMP, dans le serveur j'ai ajouté les routes
vers les réseaux qui ne pouvaient pas transmettre via le
modem-routeur en signalant un mtu00. Ainsi au moins j'espère,
si je comprends bien, mon réseau conserve le même MTU
qu'auparavant et quand les autres réseaux se connecteront,
en leur annonçant un MTU inférieur, ils se débrouilleront
pour transmettre des segments TCP plus petits.

Ne sachant pas si c'était suffissant j'ai aussi ajouté
la règle iptables pour redéfinir le MSS.

Trois messages sont arrivés, un des deux réseaux peut
communiquer sans problème, j'attends maintenant les
messages de l'autre réseau qui pose problème.

Pour résumer:

- Le firewall laisse passer les ICMP.
- Dans le rc.local du serveur j'ai ajouté:

ip route add @IP-réseau-1/24 via 192.168.0.1 mtu 1000
ip route add @IP-réseau-2/24 via 192.168.0.1 mtu 1000
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Je ne sais pas d'ailleurs s'il est possible de modifier le MTU
d'un routeur....



Rien ne l'interdit a priori, cela dépend du modèle et de ses options de
configuration.



Mon modem-routeur n'a pas cette possibilité, mais je pense que
ce ne serait utile que si on pouvait modifier ce mtu selon
le réseau de destination, mais bon, je crois que ça mérite
un autre fil de discussion.

Très cordialement,

dyrmak
--
Los tiempos tesoros
++++ --- ++++
Linux operating system
++++ --- ++++
Pascal Hambourg
Le #25188692
dyrmak a écrit :
- Dans le rc.local du serveur j'ai ajouté:

ip route add @IP-réseau-1/24 via 192.168.0.1 mtu 1000
ip route add @IP-réseau-2/24 via 192.168.0.1 mtu 1000
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu



Les règles de la chaîne FORWARD ne traitent que les paquets traversant
une machine servant de routeur, pas les paquets dont la machine est la
source ou la destination. D'autre part, l'option --clamp-mss-to-pmtu
n'est pertinente que pour une machine servant de routeur intermédiaire
pour agir sur les paquets qui la traversent, car la source et la
destination ajustent déjà le MSS à partir du path MTU. Pour ces deux
raisons, sur une machine qui fonctionne en tant qu'hôte non routeur,
cette règle n'a aucun effet.

Pour un hôte, il faut mettre la règle dans la chaîne OUTPUT et/ou
PREROUTING (de la table mangle de préférence, s'agissant d'une
altération de paquet) selon l'effet souhaité et fixer la valeur de MSS
manuellement avec --set-mss.
dyrmak
Le #25199022
En 20 lignes Pascal Hambourg a écrit
dans news:kef2lf$2j8u$
le vendredi, 01 février 2013 à 01:35:54 :

dyrmak a écrit :
- Dans le rc.local du serveur j'ai ajouté:

ip route add @IP-réseau-1/24 via 192.168.0.1 mtu 1000
ip route add @IP-réseau-2/24 via 192.168.0.1 mtu 1000
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS
--clamp-mss-to-pmtu



Les règles de la chaîne FORWARD ne traitent que les paquets traversant
une machine servant de routeur, pas les paquets dont la machine est la
source ou la destination. D'autre part, l'option --clamp-mss-to-pmtu
n'est pertinente que pour une machine servant de routeur intermédiaire
pour agir sur les paquets qui la traversent, car la source et la
destination ajustent déjà le MSS à partir du path MTU. Pour ces deux
raisons, sur une machine qui fonctionne en tant qu'hôte non routeur,
cette règle n'a aucun effet.

Pour un hôte, il faut mettre la règle dans la chaîne OUTPUT et/ou
PREROUTING (de la table mangle de préférence, s'agissant d'une
altération de paquet) selon l'effet souhaité et fixer la valeur de MSS
manuellement avec --set-mss.



Tout à fait !

À force de chercher une demi-solution dans le firewall et une demi-solution
dans le serveur j'avais fini par tout mélanger dans le serveur, heureusement
sans conséquence.
j'enlève inmédiatement cette règle puisque le serveur n'est pas un routeur.

Maintenant, si toutefois je devais envisager le réglage du MSS, est-ce que la
règle suivante dans le serveur serait correcte ?

iptables -t mangle -A POSTROUTING -p tcp --tcp -flags SYNC,RST SYN -o eth0
-j TCPMSS --set-mss 1200

Si elle est correcte, elle imposerait à toute connection entrante une réduction
de MSS, est-ce qu'on peut la modifier pour indiquer explicitement les réseaux
concernés afin de ne modifier le MSS que pour ces réseaux ?

Je ne sais pas vraiment si la règle suivante
réponds à cette dernière question:

iptables -t mangle -A POSTROUTING --destination <@IPréseau-2/24> -p
tcp --tcp -flags SYNC,RST SYN -o eth0 -j TCPMSS --set-mss 1200


J'attendais des messages du deuxième réseau à problèmes, ils arrivent et je ne
les reçois toujours pas, j'ai encore le message d'erreur "connection closed
prematurely", le serveur d'en face utilise plusieurs réseaux et il faudrait
la liste complète de ces réseaux pour pouvoir modifier le mtu correctement.

Merci anticipé pour tout éclairage rélatif à ces questions.

dyrmak
--
La hora que suena
++++ --- ++++
Linux operating system
++++ --- ++++
dyrmak
Le #25208142
En 63 lignes dyrmak a écrit
dans news:
le lundi, 04 février 2013 à 11:55:33 :

Maintenant, si toutefois je devais envisager le réglage du MSS, est-ce que la
règle suivante dans le serveur serait correcte ?

iptables -t mangle -A POSTROUTING -p tcp --tcp -flags SYNC,RST SYN -o eth0
-j TCPMSS --set-mss 1200

Si elle est correcte, elle imposerait à toute connection entrante
une réduction de MSS, est-ce qu'on peut la modifier pour indiquer
explicitement les réseaux concernés afin de ne modifier le MSS que
pour ces réseaux ?

Je ne sais pas vraiment si la règle suivante
réponds à cette dernière question:

iptables -t mangle -A POSTROUTING --destination <@IPréseau-2/24> -p
tcp --tcp -flags SYNC,RST SYN -o eth0 -j TCPMSS --set-mss 1200


J'attendais des messages du deuxième réseau à problèmes, ils arrivent
et je ne les reçois toujours pas, j'ai encore le message d'erreur
"connection closed prematurely", le serveur d'en face utilise
plusieurs réseaux et il faudrait la liste complète de ces réseaux
pour pouvoir modifier le mtu correctement.

Merci anticipé pour tout éclairage rélatif à ces questions.





J'ai voulu me répondre à moi même, mais comment faire
si en face je n'ai pas de connection entrante pour le confirmer ?

Dans mon réseau local j'ai un autre serveur de courrier (palmita) à partir
duquel j'ai envoyé un message local au serveur de courrier principal
(courrierlocal) sur lequel je force un mss11 avec la règle:

iptables -t mangle -A POSTROUTING --destination palmita -p tcp
--tcp-flags SYN,RST SYN -o eth0 -j TCPMSS --set-mss 1111

J'ai lancé tcpdump -i eth1 sur palmita et voilà
ce que ça donne:


19:44:43.383799 ARP, Request who-has courrierlocal.terre tell
palmita, length 28
19:44:43.384621 ARP, Reply courrierlocal.terre is-at
52:54:00:12:34:56 (oui Unknown), length 46
19:44:43.384683 IP palmita.45128 > courrierlocal.terre.smtp: Flags
[S], seq 1415882989, win 5840, options [mss 1460,sackOK,TS val
4294928541 ecr 0,nop,wscale 5], length 0
19:44:43.385286 IP courrierlocal.terre.smtp > palmita.45128: Flags
[S.], seq 1549868014, ack 1415882990, win 14480, options [mss
1111,sackOK,TS val 1378475 ecr 4294928541,nop,wscale 4], length 0
19:44:43.385390 IP palmita.45128 > courrierlocal.terre.smtp: Flags
[.], ack 1, win 183, options [nop,nop,TS val 4294928542 ecr 1378475],
length 0
19:44:43.393215 IP courrierlocal.terre.38618 > palmita.auth: Flags
[S], seq 643659387, win 14600, options [mss 1111,sackOK,TS val 1378477
ecr 0,nop,wscale 4], length 0
19:44:43.393263 IP palmita.auth > courrierlocal.terre.38618: Flags
[R.], seq 0, ack 643659388, win 0, length 0
19:44:44.417605 IP courrierlocal.terre.smtp > palmita.45128: Flags
[P.], seq 1:175, ack 1, win 905, options [nop,nop,TS val 1378733 ecr
4294928542], length 174
:

Je vois donc, en cherchant bien, que le serveur courrierlocal répond
mss11, tout le reste étant égal par ailleurs, j'espère qu'il
en sera de même lorsque la vraie connection arrivera.

Certains correspondants ont changé d'adresse mail, n'étant moi-même ni
conseilleur ni payeur, je garderai les routes ou les règles iptables
pour essayer d'indiguer le problème.

dyrmak
--
¿ De quién fue la culpa ? No sé de la suerte
++++ --- ++++
Linux operating system
++++ --- ++++
dyrmak
Le #25208782
En 83 lignes dyrmak a écrit
dans news:
le jeudi, 07 février 2013 à 20:53:50 :

Certains correspondants ont changé d'adresse mail, n'étant moi-même ni
conseilleur ni payeur, je garderai les routes ou les règles iptables
pour essayer d'indiguer le problème.




Je précise que l'astuce qui m'a permis d'envoyer un message au serveur
principal confirme que celui-ci renvoie le bon mss à l'initiateur de
la connexion (palmita) avec la règle:

iptables -t mangle .... destination palmita.....mss 1111


Pour moi, ce problème est résolu.
Merci de m'avoir aidé à trouver les solutions à ce problème.

dyrmak
--
¿ De quién fue la culpa ? No sé de la suerte
++++ --- ++++
Linux operating system
++++ --- ++++
Publicité
Poster une réponse
Anonyme