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.
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
++++ --- ++++
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal Hambourg
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.
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.
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
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 ++++ --- ++++
En 50 lignes Pascal Hambourg a écrit
dans news:ke0cr5$ksa$1@saria.nerim.net
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
++++ --- ++++
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
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 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.
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
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 ++++ --- ++++
En 20 lignes Pascal Hambourg a écrit
dans news:kef2lf$2j8u$1@saria.nerim.net
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
++++ --- ++++
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
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:
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 ++++ --- ++++
En 63 lignes dyrmak a écrit
dans news:slrnkgv4t5.a7e.dyrmak@quelite.terre
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:
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
++++ --- ++++
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:
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
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:
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 ++++ --- ++++
En 83 lignes dyrmak a écrit
dans news:slrnkh81ie.85n.dyrmak@quelite.terre
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:
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:
