Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS Linux Debian openvpn entre deux debian : très très très très lent

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

6 réponses
Avatar
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 =E0 Brest (le
client) via SSH (les deux machines sont chez le m=EAme FAI-sfr - derri=E8re
des box).

L'utilisation de SSH est tr=E8s "confortable" en terme de temps de
r=E9ponse.

une fois le vpn =E9tablit, la communication sur le vpn est tr=E8s lente !
un ping depuis brest sur une machine =E0 Ascain donne ceci :

64 bytes from store-ascain (192.168.3.50): icmp_req=3D88 ttl=3D63
time=3D273621 ms

Les montages nfs tombent en time-out avant d'avoir =EAtre =E9tabli.

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

L'=E9tablissement de la connexion prend du temps plus de 10 secondes

openvpn en tcp sur le port 1193 (apr=E8s avoir =E9t=E9 en UDP), les
redirection depuis la box neuf vers le serveur VPN (dom xen) sont
faits, les iptables sont assez "l=E2ches" pour l'instant, le cipher est
un DES-EDE3-CBC...

D'o=F9 cela peut-il provenir ?

En l'=E9tat l'utilisation du VPN n'est pas viable :-(

root@alphonse:~# netstat -rn
Table de routage IP du noyau
Destination Passerelle Genmask Indic MSS Fen=EAtre
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=20
RX bytes:7789770 (7.4 MiB) TX bytes:2947916 (2.8 MiB)
Interruption:41 Adresse de base:0x8000=20

lo Link encap:Boucle locale =20
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:H=F4te
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=20
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=20
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=3D1 ttl=3D64 time=3D0.053 ms
64 bytes from 192.168.100.10: icmp_req=3D2 ttl=3D64 time=3D0.042 ms
64 bytes from 192.168.100.10: icmp_req=3D3 ttl=3D64 time=3D0.041 ms
64 bytes from 192.168.100.10: icmp_req=3D4 ttl=3D64 time=3D0.034 ms
^C
--- 192.168.100.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev =3D 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=3D1 ttl=3D64 time=3D75.6 ms
64 bytes from 192.168.100.1: icmp_req=3D2 ttl=3D64 time=3D72.5 ms
64 bytes from 192.168.100.1: icmp_req=3D3 ttl=3D64 time=3D74.0 ms
64 bytes from 192.168.100.1: icmp_req=3D4 ttl=3D64 time=3D72.8 ms
^C
--- 192.168.100.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev =3D 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=3D1 ttl=3D64 time=3D74.3 ms
64 bytes from 192.168.3.70: icmp_req=3D2 ttl=3D64 time=3D73.6 ms
64 bytes from 192.168.3.70: icmp_req=3D3 ttl=3D64 time=3D18328 ms
64 bytes from 192.168.3.70: icmp_req=3D4 ttl=3D64 time=3D72713 ms
64 bytes from 192.168.3.70: icmp_req=3D5 ttl=3D64 time=3D71733 ms
64 bytes from 192.168.3.70: icmp_req=3D6 ttl=3D64 time=3D70725 ms
64 bytes from 192.168.3.70: icmp_req=3D7 ttl=3D64 time=3D69717 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
Signaler un problème avec ce contenu

6 réponses

Supprimer
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
Avatar
Jean-Yves F. Barbier
On Mon, 12 Sep 2011 19:06:31 +0200, Yann Cohen wrote:

...
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/
Avatar
Erwan David
On 12/09/11 19:58, Jean-Yves F. Barbier wrote:
On Mon, 12 Sep 2011 19:06:31 +0200, Yann Cohen wrote:

...
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/
Avatar
Jean-Yves F. Barbier
On Mon, 12 Sep 2011 20:16:52 +0200, Erwan David wrote:



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/
Avatar
Christophe Le Roy
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 wrote:
>
> ...
>> 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/
Avatar
Yann COHEN
Le Mon, 12 Sep 2011 19:58:33 +0200,
"Jean-Yves F. Barbier" a écrit :

On Mon, 12 Sep 2011 19:06:31 +0200, Yann Cohen wrote:

...
> 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/
Avatar
Yves Rutschle
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/