Le hic, c'est que j'ai quelques soucis :
- Impossible d'envoyer de "gros" mails (long contenu ou pièce jointe),
l'envoi se bloque en plein milieu
- Impossible d'afficher certaines pages (genre certaines pages de
phpMyAdmin) - Déconnexions fréquentes en SSH (je parcours un fichier et
pouf, la connexion SSH se gèle)
Ce qui selon ce que j'ai pu voir sur le net s'apparente à un problème de
MTU.
Le hic, c'est que j'ai quelques soucis :
- Impossible d'envoyer de "gros" mails (long contenu ou pièce jointe),
l'envoi se bloque en plein milieu
- Impossible d'afficher certaines pages (genre certaines pages de
phpMyAdmin) - Déconnexions fréquentes en SSH (je parcours un fichier et
pouf, la connexion SSH se gèle)
Ce qui selon ce que j'ai pu voir sur le net s'apparente à un problème de
MTU.
Le hic, c'est que j'ai quelques soucis :
- Impossible d'envoyer de "gros" mails (long contenu ou pièce jointe),
l'envoi se bloque en plein milieu
- Impossible d'afficher certaines pages (genre certaines pages de
phpMyAdmin) - Déconnexions fréquentes en SSH (je parcours un fichier et
pouf, la connexion SSH se gèle)
Ce qui selon ce que j'ai pu voir sur le net s'apparente à un problème de
MTU.
On Thursday 25 June 2009 00:27, cyberjujum wrote:Le hic, c'est que j'ai quelques soucis :
- Impossible d'envoyer de "gros" mails (long contenu ou pièce
jointe),
l'envoi se bloque en plein milieu
- Impossible d'afficher certaines pages (genre certaines pages de
phpMyAdmin) - Déconnexions fréquentes en SSH (je parcours un
fichier et
pouf, la connexion SSH se gèle)
Ce qui selon ce que j'ai pu voir sur le net s'apparente à un
problème de
MTU.
Bonjour,
La réencapsulation de données, propre au mécanisme VPN
(que ce soit ESP,
GRE, ou autre), provoque une diminution de la MTU utile. Cela entraîne un
phénomène de fragmentation, voir de drop de paquet (si le bit DF
desdits
paquets est positionné).
La réduction de la MTU côté client ne fait que
déplacer le problème. La
solution consiste à appliquer une limite MSS sur les flux VPN (la valeur
doit être égale à la MTU actuelle, moins la taille de
l'entête TCP, moins
la taille de l'entête IP, moins l'overhead de réencapsulation).
Attention: MSS est une option TCP, et ne sera donc appliquée qu'aux
connexions TCP.
Cordialement,
Mateusz Viste
On Thursday 25 June 2009 00:27, cyberjujum wrote:
Le hic, c'est que j'ai quelques soucis :
- Impossible d'envoyer de "gros" mails (long contenu ou pièce
jointe),
l'envoi se bloque en plein milieu
- Impossible d'afficher certaines pages (genre certaines pages de
phpMyAdmin) - Déconnexions fréquentes en SSH (je parcours un
fichier et
pouf, la connexion SSH se gèle)
Ce qui selon ce que j'ai pu voir sur le net s'apparente à un
problème de
MTU.
Bonjour,
La réencapsulation de données, propre au mécanisme VPN
(que ce soit ESP,
GRE, ou autre), provoque une diminution de la MTU utile. Cela entraîne un
phénomène de fragmentation, voir de drop de paquet (si le bit DF
desdits
paquets est positionné).
La réduction de la MTU côté client ne fait que
déplacer le problème. La
solution consiste à appliquer une limite MSS sur les flux VPN (la valeur
doit être égale à la MTU actuelle, moins la taille de
l'entête TCP, moins
la taille de l'entête IP, moins l'overhead de réencapsulation).
Attention: MSS est une option TCP, et ne sera donc appliquée qu'aux
connexions TCP.
Cordialement,
Mateusz Viste
On Thursday 25 June 2009 00:27, cyberjujum wrote:Le hic, c'est que j'ai quelques soucis :
- Impossible d'envoyer de "gros" mails (long contenu ou pièce
jointe),
l'envoi se bloque en plein milieu
- Impossible d'afficher certaines pages (genre certaines pages de
phpMyAdmin) - Déconnexions fréquentes en SSH (je parcours un
fichier et
pouf, la connexion SSH se gèle)
Ce qui selon ce que j'ai pu voir sur le net s'apparente à un
problème de
MTU.
Bonjour,
La réencapsulation de données, propre au mécanisme VPN
(que ce soit ESP,
GRE, ou autre), provoque une diminution de la MTU utile. Cela entraîne un
phénomène de fragmentation, voir de drop de paquet (si le bit DF
desdits
paquets est positionné).
La réduction de la MTU côté client ne fait que
déplacer le problème. La
solution consiste à appliquer une limite MSS sur les flux VPN (la valeur
doit être égale à la MTU actuelle, moins la taille de
l'entête TCP, moins
la taille de l'entête IP, moins l'overhead de réencapsulation).
Attention: MSS est une option TCP, et ne sera donc appliquée qu'aux
connexions TCP.
Cordialement,
Mateusz Viste
On Thursday 25 June 2009 00:27, cyberjujum wrote:Le hic, c'est que j'ai quelques soucis :
- Impossible d'envoyer de "gros" mails (long contenu ou pièce
jointe),
l'envoi se bloque en plein milieu
- Impossible d'afficher certaines pages (genre certaines pages de
phpMyAdmin) - Déconnexions fréquentes en SSH (je parcours un
fichier et
pouf, la connexion SSH se gèle)
Ce qui selon ce que j'ai pu voir sur le net s'apparente à un
problème de
MTU.
Bonjour,
La réencapsulation de données, propre au mécanisme VPN
(que ce soit ESP,
GRE, ou autre), provoque une diminution de la MTU utile. Cela entraîne un
phénomène de fragmentation, voir de drop de paquet (si le bit DF
desdits
paquets est positionné).
La réduction de la MTU côté client ne fait que
déplacer le problème. La
solution consiste à appliquer une limite MSS sur les flux VPN (la valeur
doit être égale à la MTU actuelle, moins la taille de
l'entête TCP, moins
la taille de l'entête IP, moins l'overhead de réencapsulation).
Attention: MSS est une option TCP, et ne sera donc appliquée qu'aux
connexions TCP.
Cordialement,
Mateusz Viste
On Thursday 25 June 2009 00:27, cyberjujum wrote:
Le hic, c'est que j'ai quelques soucis :
- Impossible d'envoyer de "gros" mails (long contenu ou pièce
jointe),
l'envoi se bloque en plein milieu
- Impossible d'afficher certaines pages (genre certaines pages de
phpMyAdmin) - Déconnexions fréquentes en SSH (je parcours un
fichier et
pouf, la connexion SSH se gèle)
Ce qui selon ce que j'ai pu voir sur le net s'apparente à un
problème de
MTU.
Bonjour,
La réencapsulation de données, propre au mécanisme VPN
(que ce soit ESP,
GRE, ou autre), provoque une diminution de la MTU utile. Cela entraîne un
phénomène de fragmentation, voir de drop de paquet (si le bit DF
desdits
paquets est positionné).
La réduction de la MTU côté client ne fait que
déplacer le problème. La
solution consiste à appliquer une limite MSS sur les flux VPN (la valeur
doit être égale à la MTU actuelle, moins la taille de
l'entête TCP, moins
la taille de l'entête IP, moins l'overhead de réencapsulation).
Attention: MSS est une option TCP, et ne sera donc appliquée qu'aux
connexions TCP.
Cordialement,
Mateusz Viste
On Thursday 25 June 2009 00:27, cyberjujum wrote:Le hic, c'est que j'ai quelques soucis :
- Impossible d'envoyer de "gros" mails (long contenu ou pièce
jointe),
l'envoi se bloque en plein milieu
- Impossible d'afficher certaines pages (genre certaines pages de
phpMyAdmin) - Déconnexions fréquentes en SSH (je parcours un
fichier et
pouf, la connexion SSH se gèle)
Ce qui selon ce que j'ai pu voir sur le net s'apparente à un
problème de
MTU.
Bonjour,
La réencapsulation de données, propre au mécanisme VPN
(que ce soit ESP,
GRE, ou autre), provoque une diminution de la MTU utile. Cela entraîne un
phénomène de fragmentation, voir de drop de paquet (si le bit DF
desdits
paquets est positionné).
La réduction de la MTU côté client ne fait que
déplacer le problème. La
solution consiste à appliquer une limite MSS sur les flux VPN (la valeur
doit être égale à la MTU actuelle, moins la taille de
l'entête TCP, moins
la taille de l'entête IP, moins l'overhead de réencapsulation).
Attention: MSS est une option TCP, et ne sera donc appliquée qu'aux
connexions TCP.
Cordialement,
Mateusz Viste
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth0 -j
TCPMSS --clamp-mss-to-pmtu
ou
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth0 -j
TCPMSS --set-mss <valeur>
La première règle n'a absolument rien changé.
Par contre, la deuxième, avec un MSS très bas (128) a résolu mon problème !
L'envoi du mail est un peu long mais fonctionne. Par contre ça me chiffonne de
fixer un MSS si bas... et quand j'augmente ça ne fonctionne plus, à 140 par
exemple c'est déjà mort.
La méthode que j'ai suivie est-elle la bonne et y-a-t-il une explication à ce
phénomène... plutôt bizarre ? Est-ce gênant d'avoir un MSS aussi bas ?
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth0 -j
TCPMSS --clamp-mss-to-pmtu
ou
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth0 -j
TCPMSS --set-mss <valeur>
La première règle n'a absolument rien changé.
Par contre, la deuxième, avec un MSS très bas (128) a résolu mon problème !
L'envoi du mail est un peu long mais fonctionne. Par contre ça me chiffonne de
fixer un MSS si bas... et quand j'augmente ça ne fonctionne plus, à 140 par
exemple c'est déjà mort.
La méthode que j'ai suivie est-elle la bonne et y-a-t-il une explication à ce
phénomène... plutôt bizarre ? Est-ce gênant d'avoir un MSS aussi bas ?
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth0 -j
TCPMSS --clamp-mss-to-pmtu
ou
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth0 -j
TCPMSS --set-mss <valeur>
La première règle n'a absolument rien changé.
Par contre, la deuxième, avec un MSS très bas (128) a résolu mon problème !
L'envoi du mail est un peu long mais fonctionne. Par contre ça me chiffonne de
fixer un MSS si bas... et quand j'augmente ça ne fonctionne plus, à 140 par
exemple c'est déjà mort.
La méthode que j'ai suivie est-elle la bonne et y-a-t-il une explication à ce
phénomène... plutôt bizarre ? Est-ce gênant d'avoir un MSS aussi bas ?
Salut,
cyberjujum a écrit :
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth0 -j
TCPMSS --clamp-mss-to-pmtu
ou
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth0 -j
TCPMSS --set-mss <valeur>
La première règle n'a absolument rien changé.
Normal, la MTU d'eth0 est à 1500.Par contre, la deuxième, avec un MSS très bas (128) a
résolu mon problème !
L'envoi du mail est un peu long mais fonctionne. Par contre ça me
chiffonne de
fixer un MSS si bas... et quand j'augmente ça ne fonctionne plus,
à 140 par
exemple c'est déjà mort.
La méthode que j'ai suivie est-elle la bonne et y-a-t-il une
explication à ce
phénomène... plutôt bizarre ? Est-ce gênant d'avoir
un MSS aussi bas ?
Oui, c'est gênant car le rendement protocolaire est mauvais : pour un
segment TCP contenant 128 octets de charge utile, le total des en-têtes
IP+TCP est de 40 octets, sans compter l'encapsulation du VPN. Cela pèse
sur le débit utile comme tu l'as constaté. Pour mémoire,
IPv6, le
successeur d'IPv4, impose un MTU minimum de 1280 octets afin de limiter
la surcharge protocolaire.
Il y a aussi un léger défaut dans ta règle : elle affecte
indifféremment
toutes les connexions TCP passant par eth0, et pas seulement celles qui
passent à travers le VPN.
Mais surtout, je ne vois pas ce qui pourrait imposer une valeur de MTU
aussi basse. Il pourrait être intéressant de faire des tests de
ping
pour voir quelle est la taille de paquet maximum qui passe dans chaque
sens, et de faire des captures de trafic à tous les points possibles
pour déterminer à quel endroit les paquets sont perdus : eth0,
tun0,
trafic encapsulé, à l'autre bout du VPN. Quel est le type de VPN
?
OpenVPN, VTun, autre ?
Salut,
cyberjujum a écrit :
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth0 -j
TCPMSS --clamp-mss-to-pmtu
ou
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth0 -j
TCPMSS --set-mss <valeur>
La première règle n'a absolument rien changé.
Normal, la MTU d'eth0 est à 1500.
Par contre, la deuxième, avec un MSS très bas (128) a
résolu mon problème !
L'envoi du mail est un peu long mais fonctionne. Par contre ça me
chiffonne de
fixer un MSS si bas... et quand j'augmente ça ne fonctionne plus,
à 140 par
exemple c'est déjà mort.
La méthode que j'ai suivie est-elle la bonne et y-a-t-il une
explication à ce
phénomène... plutôt bizarre ? Est-ce gênant d'avoir
un MSS aussi bas ?
Oui, c'est gênant car le rendement protocolaire est mauvais : pour un
segment TCP contenant 128 octets de charge utile, le total des en-têtes
IP+TCP est de 40 octets, sans compter l'encapsulation du VPN. Cela pèse
sur le débit utile comme tu l'as constaté. Pour mémoire,
IPv6, le
successeur d'IPv4, impose un MTU minimum de 1280 octets afin de limiter
la surcharge protocolaire.
Il y a aussi un léger défaut dans ta règle : elle affecte
indifféremment
toutes les connexions TCP passant par eth0, et pas seulement celles qui
passent à travers le VPN.
Mais surtout, je ne vois pas ce qui pourrait imposer une valeur de MTU
aussi basse. Il pourrait être intéressant de faire des tests de
ping
pour voir quelle est la taille de paquet maximum qui passe dans chaque
sens, et de faire des captures de trafic à tous les points possibles
pour déterminer à quel endroit les paquets sont perdus : eth0,
tun0,
trafic encapsulé, à l'autre bout du VPN. Quel est le type de VPN
?
OpenVPN, VTun, autre ?
Salut,
cyberjujum a écrit :
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth0 -j
TCPMSS --clamp-mss-to-pmtu
ou
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth0 -j
TCPMSS --set-mss <valeur>
La première règle n'a absolument rien changé.
Normal, la MTU d'eth0 est à 1500.Par contre, la deuxième, avec un MSS très bas (128) a
résolu mon problème !
L'envoi du mail est un peu long mais fonctionne. Par contre ça me
chiffonne de
fixer un MSS si bas... et quand j'augmente ça ne fonctionne plus,
à 140 par
exemple c'est déjà mort.
La méthode que j'ai suivie est-elle la bonne et y-a-t-il une
explication à ce
phénomène... plutôt bizarre ? Est-ce gênant d'avoir
un MSS aussi bas ?
Oui, c'est gênant car le rendement protocolaire est mauvais : pour un
segment TCP contenant 128 octets de charge utile, le total des en-têtes
IP+TCP est de 40 octets, sans compter l'encapsulation du VPN. Cela pèse
sur le débit utile comme tu l'as constaté. Pour mémoire,
IPv6, le
successeur d'IPv4, impose un MTU minimum de 1280 octets afin de limiter
la surcharge protocolaire.
Il y a aussi un léger défaut dans ta règle : elle affecte
indifféremment
toutes les connexions TCP passant par eth0, et pas seulement celles qui
passent à travers le VPN.
Mais surtout, je ne vois pas ce qui pourrait imposer une valeur de MTU
aussi basse. Il pourrait être intéressant de faire des tests de
ping
pour voir quelle est la taille de paquet maximum qui passe dans chaque
sens, et de faire des captures de trafic à tous les points possibles
pour déterminer à quel endroit les paquets sont perdus : eth0,
tun0,
trafic encapsulé, à l'autre bout du VPN. Quel est le type de VPN
?
OpenVPN, VTun, autre ?
Pour la règle, effectivement un
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -i tun0 -o
eth0 -j TCPMSS --set-mss 128
serait mieux pour ne modifier que les paquets qui viennent du VPN :)
Je vais essayer de faire quelques tests de ping. Le plus déconcertant c'est que
depuis la passerelle tout roule (si je lance un client mail directement depuis
la passerelle et que j'envoie un mail, no problemo).
Le VPN est un VPN Cisco IPSec, je m'y connecte avec vpnc.
PS : Comment faites-vous pour ne pas citer tout le message précédent ?
Je n'ai
vu que deux liens "Répondre à ce message" et "Répondre au sujet initial" qui me
citent tous les deux automatiquement tout le message précédent en entier, c'est
assez pénible :D
Pour la règle, effectivement un
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -i tun0 -o
eth0 -j TCPMSS --set-mss 128
serait mieux pour ne modifier que les paquets qui viennent du VPN :)
Je vais essayer de faire quelques tests de ping. Le plus déconcertant c'est que
depuis la passerelle tout roule (si je lance un client mail directement depuis
la passerelle et que j'envoie un mail, no problemo).
Le VPN est un VPN Cisco IPSec, je m'y connecte avec vpnc.
PS : Comment faites-vous pour ne pas citer tout le message précédent ?
Je n'ai
vu que deux liens "Répondre à ce message" et "Répondre au sujet initial" qui me
citent tous les deux automatiquement tout le message précédent en entier, c'est
assez pénible :D
Pour la règle, effectivement un
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -i tun0 -o
eth0 -j TCPMSS --set-mss 128
serait mieux pour ne modifier que les paquets qui viennent du VPN :)
Je vais essayer de faire quelques tests de ping. Le plus déconcertant c'est que
depuis la passerelle tout roule (si je lance un client mail directement depuis
la passerelle et que j'envoie un mail, no problemo).
Le VPN est un VPN Cisco IPSec, je m'y connecte avec vpnc.
PS : Comment faites-vous pour ne pas citer tout le message précédent ?
Je n'ai
vu que deux liens "Répondre à ce message" et "Répondre au sujet initial" qui me
citent tous les deux automatiquement tout le message précédent en entier, c'est
assez pénible :D
cyberjujum a écrit :Le VPN est un VPN Cisco IPSec, je m'y connecte avec vpnc.
Connais pas.
cyberjujum a écrit :
Le VPN est un VPN Cisco IPSec, je m'y connecte avec vpnc.
Connais pas.
cyberjujum a écrit :Le VPN est un VPN Cisco IPSec, je m'y connecte avec vpnc.
Connais pas.
Attention, vpnc utilise udp.
Attention, vpnc utilise udp.
Attention, vpnc utilise udp.
On Friday 26 June 2009 11:48, GuiGui wrote:Attention, vpnc utilise udp.
Qu'importe, ce qui nous intéresse, c'est le flux
déchiffré, pas le flux
ESP (ou UDP s'il y a du NAT-T). Le but de la limite MSS est de limiter le
payload des paquets en clair, de manière à ne pas dépasser
la MTU
disponible après encapsulation...
Cordialement,
Mateusz Viste
On Friday 26 June 2009 11:48, GuiGui wrote:
Attention, vpnc utilise udp.
Qu'importe, ce qui nous intéresse, c'est le flux
déchiffré, pas le flux
ESP (ou UDP s'il y a du NAT-T). Le but de la limite MSS est de limiter le
payload des paquets en clair, de manière à ne pas dépasser
la MTU
disponible après encapsulation...
Cordialement,
Mateusz Viste
On Friday 26 June 2009 11:48, GuiGui wrote:Attention, vpnc utilise udp.
Qu'importe, ce qui nous intéresse, c'est le flux
déchiffré, pas le flux
ESP (ou UDP s'il y a du NAT-T). Le but de la limite MSS est de limiter le
payload des paquets en clair, de manière à ne pas dépasser
la MTU
disponible après encapsulation...
Cordialement,
Mateusz Viste
Et pour l'histoire du TCP/UDP, est-ce que ça vaut le coup que je change de
client alors ? Sous Windows, le client Cisco a la facheuse tendance à "bloquer"
toutes les autres connexions (plus de réseau local par exemple). Comme le VPN
auquel je me connecte ne me donne accès qu'à une poignée de serveurs et oblige à
passer par un proxy pour atteindre l'extérieur, c'est assez embêtant... vpnc n'a
pas cet inconvénient, je ne sais pas si la version linux du client Cisco l'aura
:)
Et pour l'histoire du TCP/UDP, est-ce que ça vaut le coup que je change de
client alors ? Sous Windows, le client Cisco a la facheuse tendance à "bloquer"
toutes les autres connexions (plus de réseau local par exemple). Comme le VPN
auquel je me connecte ne me donne accès qu'à une poignée de serveurs et oblige à
passer par un proxy pour atteindre l'extérieur, c'est assez embêtant... vpnc n'a
pas cet inconvénient, je ne sais pas si la version linux du client Cisco l'aura
:)
Et pour l'histoire du TCP/UDP, est-ce que ça vaut le coup que je change de
client alors ? Sous Windows, le client Cisco a la facheuse tendance à "bloquer"
toutes les autres connexions (plus de réseau local par exemple). Comme le VPN
auquel je me connecte ne me donne accès qu'à une poignée de serveurs et oblige à
passer par un proxy pour atteindre l'extérieur, c'est assez embêtant... vpnc n'a
pas cet inconvénient, je ne sais pas si la version linux du client Cisco l'aura
:)