Passerelle, routage, VPN, MTU

Passerelle, routage, VPN, MTU - Réseaux - Réseaux grand public / SoHo

Marsh Posté le 25-06-2009 à 00:18:03    

Bonjour à tous,
 
Pour les pros du réseau, une petite question qui me fait tourner en bourrique depuis un bon moment maintenant :
 
J'ai une passerelle sous Ubuntu server, qui en gros me sert à partager une connexion VPN. Cette passerelle profite de ma connexion perso pour se connecter à un VPN qui ne me donne accès qu'à certains serveurs et a des routes configurées pour dispatcher les paquets là où il faut (mon FAI pour le net "classique", le VPN pour les serveurs à accès restreint). Comme ça mes autres PC clients (PC de bureau, laptop...) ont une connexion prête à l'emploi en passant par cette passerelle.
 
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.
 
Ces problèmes apparaissent seulement avec les serveurs accessibles via le VPN (impossible d'envoyer un mail avec pièce jointe via un serveur SMTP accessible via ce VPN, alors qu'avec celui de mon FAI c'est nickel ; le seul phpMyAdmin qui foire est hébergé sur un serveur auquel j'accède via ce VPN, idem pour les décos SSH...).
 
Voici quelques infos :

Code :
  1. root@gateway:/usr/local/share/gateway2# ifconfig
  2. eth0      Link encap:Ethernet  HWaddr 00:22:15:d3:8e:28 
  3.           inet addr:192.168.1.254  Bcast:192.168.1.255  Mask:255.255.255.0
  4.           inet6 addr: fe80::222:15ff:fed3:8e28/64 Scope:Link
  5.           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  6.           RX packets:4583 errors:0 dropped:0 overruns:0 frame:0
  7.           TX packets:3917 errors:0 dropped:0 overruns:0 carrier:0
  8.           collisions:0 txqueuelen:1000
  9.           RX bytes:1462854 (1.4 MB)  TX bytes:1479658 (1.4 MB)
  10.           Interrupt:220 Base address:0xe000
  11. lo        Link encap:Local Loopback 
  12.           inet addr:127.0.0.1  Mask:255.0.0.0
  13.           inet6 addr: ::1/128 Scope:Host
  14.           UP LOOPBACK RUNNING  MTU:16436  Metric:1
  15.           RX packets:4 errors:0 dropped:0 overruns:0 frame:0
  16.           TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
  17.           collisions:0 txqueuelen:0
  18.           RX bytes:840 (840.0 B)  TX bytes:840 (840.0 B)
  19. tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 
  20.           inet addr:10.31.46.251  P-t-P:10.31.46.251  Mask:255.255.248.0
  21.           UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1390  Metric:1
  22.           RX packets:924 errors:0 dropped:0 overruns:0 frame:0
  23.           TX packets:1164 errors:0 dropped:0 overruns:0 carrier:0
  24.           collisions:0 txqueuelen:500
  25.           RX bytes:719440 (719.4 KB)  TX bytes:384407 (384.4 KB)


 
Mon script iptables (j'ai ouvert autant que j'ai pu tellement je désespère :)) :

Code :
  1. echo 1 > /proc/sys/net/ipv4/ip_forward
  2. # Réinitialisation
  3. iptables -F
  4. iptables -X
  5. iptables -P INPUT ACCEPT
  6. iptables -P OUTPUT ACCEPT
  7. iptables -P FORWARD ACCEPT
  8. # Idem, table NAT
  9. iptables -t nat -F
  10. iptables -t nat -X
  11. iptables -t nat -P PREROUTING ACCEPT
  12. iptables -t nat -P POSTROUTING ACCEPT
  13. iptables -t nat -P OUTPUT ACCEPT
  14. iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE


 
 
J'ai remarqué le MTU 1390 sur l'interface tun0 (justement celle du VPN). J'ai essayé de passer le MTU de mes postes clients à 1390 voire moins, ça ne résoud pas le problème (peut être un peu de mieux, cad que je peux envoyer un long mail ou accéder à des pages qui ne voulaient pas se charger auparavant, mais je finis toujours par avoir des décos en SSH, les mails avec pièce jointe ne passent toujours pas, etc...).
 
Voyez-vous quelque chose qui cloche ?
 
 
Merci beaucoup ! :)

Reply

Marsh Posté le 25-06-2009 à 00:18:03   

Reply

Marsh Posté le 25-06-2009 à 18:25:07    

Informations complémentaires : le VPN en question c'est de l'IPSec (Cisco).
 
Mon problème ressemble un peu à ce que j'ai pu voir ici http://blog.aurel32.net/?p=39 mais apparemment il n'a pas trouvé de solution...
 
Je précise aussi que depuis la passerelle il n'y a aucun problème (si je lance un client mail sur la passerelle et que j'envoie un mail il passe nickel, idem pour les connexions SSH etc...). Le problème ne se manifeste que pour des PC clients derrière la passerelle, et qui veulent accéder à des serveurs accessibles via le VPN en question.
 
Voilà voilà... j'espère que quelqu'un aura une idée, merci ! :)

Reply

Marsh Posté le 26-06-2009 à 20:02:10    

ça m'a l'air d'etre un soucis de path mtu discovery si il y a un filtrage excessif de l'icmp quelque part.
 
essaye donc ça :


iptables -I FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu


 
si ça résoud ton probleme, c'est que c'était bien ça ...

Reply

Marsh Posté le 28-06-2009 à 13:16:05    

Hello,
 
Merci six_dfx mais j'avais essayé ça, et ça ne changeait rien (j'avais aussi utilisé la version avec -set-mss et une valeur arbritraire) :/
 
Problème résolu sur un groupe Usenet : un firewall entre les serveurs distants et moi modifiait les numéros de séquence des paquets en oubliant ceux des SACK, du coup dès que les serveurs distants m'envoyaient des acquittements sélectifs leurs numéros de séquence étaient incohérents et ils étaient classés comme INVALID donc non traités par le masquerading de ma passerelle. D'où les coupures de connexion en SSH, les interruptions lors d'envois de gros mails...
 
Le passage de /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal à 1 sur la passerelle pour que le suivi des connexions TCP soit plus permissif à résolu le problème :)

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed