openvpn entre deux debian : très très très très lent

Le
Yann Cohen
Bonjour,

Je viens de mettre en place un lien openvpn entre deux machines (brest
et Ascain).

Depuis Ascain (le serveur), je me connecte sur la machine à Brest (le
client) via SSH (les deux machines sont chez le même FAI-sfr - derrière
des box).

L'utilisation de SSH est très "confortable" en terme de temps de
réponse.

une fois le vpn établit, la communication sur le vpn est très lente !
un ping depuis brest sur une machine à Ascain donne ceci :

64 bytes from store-ascain (192.168.3.50): icmp_req=88 ttl=63
time=273621 ms

Les montages nfs tombent en time-out avant d'avoir être établi.

Dans le log du client à Brest on voit souvent :
read TCPv4_CLIENT []: No route to host (code=113)

L'établissement de la connexion prend du temps plus de 10 secondes

openvpn en tcp sur le port 1193 (après avoir été en UDP), les
redirection depuis la box neuf vers le serveur VPN (dom xen) sont
faits, les iptables sont assez "lâches" pour l'instant, le cipher est
un DES-EDE3-CBC

D'où cela peut-il provenir ?

En l'état l'utilisation du VPN n'est pas viable :-(

root@alphonse:~# netstat -rn
Table de routage IP du noyau
Destination Passerelle Genmask Indic MSS Fenêtre
irtt Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 0
0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0
U 0 0 0 eth0 192.168.3.0 192.168.100.9
255.255.255.0 UG 0 0 0 tun0 192.168.4.0
192.168.100.9 255.255.255.0 UG 0 0 0 tun0
192.168.100.1 192.168.100.9 255.255.255.255 UGH 0 0
0 tun0 192.168.100.9 0.0.0.0 255.255.255.255 UH 0
0 0 tun0 root@alphonse:~# ifconfig eth0 Link
encap:Ethernet HWaddr 00:23:54:4f:d8:d2 inet adr:192.168.1.30
Bcast:192.168.1.255 Masque:255.255.255.0 adr inet6:
fe80::223:54ff:fe4f:d8d2/64 Scope:Lien UP BROADCAST RUNNING MULTICAST
MTU:1500 Metric:1 RX packets:21200 errors:0 dropped:0 overruns:0
frame:0 TX packets:8498 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:7789770 (7.4 MiB) TX bytes:2947916 (2.8 MiB)
Interruption:41 Adresse de base:0x8000

lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:16 errors:0 dropped:0 overruns:0 frame:0
TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:1000 (1000.0 B) TX bytes:1000 (1000.0 B)

tun0 Link encap:UNSPEC HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet
adr:192.168.100.10 P-t-P:192.168.100.9 Masque:255.255.255.255 UP
POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0
errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0
overruns:0 carrier:0 collisions:0 lg file transmission:100
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

root@alphonse:~# ping 192.168.100.10
PING 192.168.100.10 (192.168.100.10) 56(84) bytes of data.
64 bytes from 192.168.100.10: icmp_req=1 ttl=64 time=0.053 ms
64 bytes from 192.168.100.10: icmp_req=2 ttl=64 time=0.042 ms
64 bytes from 192.168.100.10: icmp_req=3 ttl=64 time=0.041 ms
64 bytes from 192.168.100.10: icmp_req=4 ttl=64 time=0.034 ms
^C
192.168.100.10 ping statistics
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 0.034/0.042/0.053/0.009 ms
root@alphonse:~# ping 192.168.100.1
PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
64 bytes from 192.168.100.1: icmp_req=1 ttl=64 time=75.6 ms
64 bytes from 192.168.100.1: icmp_req=2 ttl=64 time=72.5 ms
64 bytes from 192.168.100.1: icmp_req=3 ttl=64 time=74.0 ms
64 bytes from 192.168.100.1: icmp_req=4 ttl=64 time=72.8 ms
^C
192.168.100.1 ping statistics
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 72.590/73.782/75.629/1.252 ms
root@alphonse:~# ping 192.168.3.70
PING 192.168.3.70 (192.168.3.70) 56(84) bytes of data.
64 bytes from 192.168.3.70: icmp_req=1 ttl=64 time=74.3 ms
64 bytes from 192.168.3.70: icmp_req=2 ttl=64 time=73.6 ms
64 bytes from 192.168.3.70: icmp_req=3 ttl=64 time=18328 ms
64 bytes from 192.168.3.70: icmp_req=4 ttl=64 time=72713 ms
64 bytes from 192.168.3.70: icmp_req=5 ttl=64 time=71733 ms
64 bytes from 192.168.3.70: icmp_req=6 ttl=64 time=70725 ms
64 bytes from 192.168.3.70: icmp_req=7 ttl=64 time=69717 ms


Yann.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20110912190631.284d6260@yan.ianco.homelinux.org
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
Jean-Yves F. Barbier
Le #23753091
On Mon, 12 Sep 2011 19:06:31 +0200, Yann Cohen
...
64 bytes from store-ascain (192.168.3.50): icmp_reqˆ ttlc
time'3621 ms


...
D'où cela peut-il provenir ?



C'est de dieu et nul mortel ne peut s'y soustraire.








































Plus sérieusement, je suppose que comme tu peux pinger tu es bridged e t non
routed... Ce qui est intriguant, c'est que les 2 premiers pings sont bons
et que ça se dégrade violemment à partir du 3ème; ce qu i parait relativement
suspect.

PING 192.168.3.70 (192.168.3.70) 56(84) bytes of data.
64 bytes from 192.168.3.70: icmp_req=1 ttld timet.3 ms
64 bytes from 192.168.3.70: icmp_req=2 ttld times.6 ms
64 bytes from 192.168.3.70: icmp_req=3 ttld time328 ms
64 bytes from 192.168.3.70: icmp_req=4 ttld timer713 ms



Par ailleurs, certains ISPs font du DPI pour pouvoir détecter et restr eindre
l'usage de certains ports/Sces, histoire de bien te faire comprendre qu'il faut
utiliser leurs services (payants) si tu veux que ça fonctionne correct ement
(ft & sfr, au hasard).

Perso, j'ai bagarré pendant un après-midi sur un OpenVPN entre un
cellulaire (sfr) et un bureau (ft), pour m'apercevoir que le même type de
PB que ce que tu rencontres a automagistracalmement disparu lorsque j'ai ch angé
le port de 1193 vers 443

Si ça ne marche pas, il faudra revenir et nous dire:
* ce que disent les routes?
* ce que dit un traceroute?
* et si on peut voir les 2 fichiers de conf (cli/svr)?

--
< Overfiend> well, excellent. I get to tear someone a new asshole.
-- in #debian-devel

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Erwan David
Le #23753221
On 12/09/11 19:58, Jean-Yves F. Barbier wrote:
On Mon, 12 Sep 2011 19:06:31 +0200, Yann Cohen
...
64 bytes from store-ascain (192.168.3.50): icmp_reqˆ ttlc
time'3621 ms


...
D'où cela peut-il provenir ?



C'est de dieu et nul mortel ne peut s'y soustraire.




Par cp,ntre ça permet de voir que la stack TCP de linux ne respecte pas
les specs...
TTL doit décroitre à chaque saut de max(1,nb secondes sur le lien).

Pas de 1...

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Jean-Yves F. Barbier
Le #23753301
On Mon, 12 Sep 2011 20:16:52 +0200, Erwan David


Par cp,ntre ça permet de voir que la stack TCP de linux ne respecte pas
les specs...



Rooooh! Faut ab-so-lu-ment le dire aux devs du kernel, ces cons doublés
d'incapables.

TTL doit décroitre à chaque saut de max(1,nb secondes sur le li en).

Pas de 1...



When a router forwards a packet, it MUST reduce the TTL by at least one. If it
holds a packet for more than one second, it ***MAY*** decrement the TTL by one
for each second. This way, Time-to-Live is used as a time count.

--
Reply hazy, ask again later.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Christophe Le Roy
Le #23759201
Le lundi 12 septembre 2011 à 20:16 +0200, Erwan David a écrit :
On 12/09/11 19:58, Jean-Yves F. Barbier wrote:
> On Mon, 12 Sep 2011 19:06:31 +0200, Yann Cohen >
> ...
>> 64 bytes from store-ascain (192.168.3.50): icmp_reqˆ ttlc
>> time'3621 ms
> ...
>> D'où cela peut-il provenir ?
>
> C'est de dieu et nul mortel ne peut s'y soustraire.
>

Par cp,ntre ça permet de voir que la stack TCP de linux ne respecte pas
les specs...
TTL doit décroitre à chaque saut de max(1,nb secondes sur le lien).

Pas de 1...



Bonjour,

Premièrement, rien à voir avec le TCP, c'est la pile IP qui se charge de
ça.
Deuxièmement, cette décrémentation s'effectue lors de la traversée d'un
routeur. Il s'agit très probablement d'un ping routeur à routeur voisin
ici...

Cordialement,

Christophe

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Yann COHEN
Le #23782271
Le Mon, 12 Sep 2011 19:58:33 +0200,
"Jean-Yves F. Barbier"
On Mon, 12 Sep 2011 19:06:31 +0200, Yann Cohen
...
> 64 bytes from store-ascain (192.168.3.50): icmp_reqˆ ttlc
> time'3621 ms
...
> D'où cela peut-il provenir ?

C'est de dieu et nul mortel ne peut s'y soustraire.



Arrg quand je pense que je me suis arrêté trop longtemps si dans la
réponse...

Il semble que j'ai rencontré un grand moment de solitude ce WE et
qu'aucun dieu ne m'est venu en aide...

Alors en désespoir de cause, j'ai mis à jour mes domU, mon dom0 p uis
arrêté les domU, le dom0. Attendu les quelques secondes néce ssaires et
relancer le tout...

Alléluia, tout semble être rentrer dans l'ordre ! Mais je n'ai pa s pu
en profiter longtemps car la machine distant a fait un caca nerveux en
perdant l'uuid de rootfs !

Pour résumer, le problème semblait être "dans les bridges" d u dom0.
Les communications entre les domU fonctionnaient, ainsi que entre les
brins des réseaux locaux.

Mais lorsque on essayait de joindre un hôte externe (internet)
depuis un domU, on se retrouvait avec des "no route to host" par
exemple ou bien des time out, des traceroute vers dehors se terminait
sur une interface interne...

En "tskarkant" les bridges (celui de la dmz et celui de l'interface
evil où est connecté la porte de sortie vers internet), lors d'un
ping depuis la dmz vers l'internet, de temps en temps des paquets
apparaissaient sur le br_evil (50% env. par rapport à ceux vu sur le
br_dmz).

J'ai donc tout remis en cause, virer les règles compliquées de la
politique du firewall (sur le NAT notamment), mais rien n'y faisait
des paquets se perdaient et n'était pas routés entre les
interfaces...

Le doigt de dieu serait-il le celui qui appuie sur le bouton
reboot !

Donc je ne sais pas pourquoi cela ne fonctionnait pas, mais maintenant
cela refonctionne...

Il doit bien avoir un proverbe shadock pour cette situation !

Merci des pistes,

même si avec mon netbook, le message s'arrêtait avant...


Cordialement.

--
Yann.








































Plus sérieusement, je suppose que comme tu peux pinger tu es bridged
et non routed... Ce qui est intriguant, c'est que les 2 premiers
pings sont bons et que ça se dégrade violemment à partir d u 3ème; ce
qui parait relativement suspect.

> PING 192.168.3.70 (192.168.3.70) 56(84) bytes of data.
> 64 bytes from 192.168.3.70: icmp_req=1 ttld timet.3 ms
> 64 bytes from 192.168.3.70: icmp_req=2 ttld times.6 ms
> 64 bytes from 192.168.3.70: icmp_req=3 ttld time328 ms
> 64 bytes from 192.168.3.70: icmp_req=4 ttld timer713 ms

Par ailleurs, certains ISPs font du DPI pour pouvoir détecter et
restreindre l'usage de certains ports/Sces, histoire de bien te faire
comprendre qu'il faut utiliser leurs services (payants) si tu veux
que ça fonctionne correctement (ft & sfr, au hasard).

Perso, j'ai bagarré pendant un après-midi sur un OpenVPN entre un
cellulaire (sfr) et un bureau (ft), pour m'apercevoir que le même
type de PB que ce que tu rencontres a automagistracalmement disparu
lorsque j'ai changé le port de 1193 vers 443

Si ça ne marche pas, il faudra revenir et nous dire:
* ce que disent les routes?
* ce que dit un traceroute?
* et si on peut voir les 2 fichiers de conf (cli/svr)?




--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Yves Rutschle
Le #23784821
On Fri, Sep 23, 2011 at 08:33:54PM +0000, jean durandt wrote:
je suis preneur pour le courrier qui a précédé ( étant new inscrit ici).
j'ai constaté cela aussi mais ce que j'ai lu de ton message me laisse perplexe : il me manque quelques données

donc si un amateur averti avait l'extrême obligeance de m'adresser l'ensemble de l'échange.... il serait grandement remercié :)



La plupart des listes de distributions ont des archives, et
celles de Debian sont publiques. L'échange commance ici:
http://lists.debian.org/debian-user-french/2011/09/msg00204.html

On peut le retrouver par l'intermédiaire de www.debian.org,
assez facilement.

Y.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Publicité
Poster une réponse
Anonyme