Re: openvpn entre deux debian : très très très très lent
Le Mon, 12 Sep 2011 19:58:33 +0200,
"Jean-Yves F. Barbier" <12ukwn@gmail.com> a écrit :
> On Mon, 12 Sep 2011 19:06:31 +0200, Yann Cohen <yann@ianco.org> wrote:
>
> ...
> > 64 bytes from store-ascain (192.168.3.50): icmp_req=88 ttl=63
> > time=273621 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 puis
arrêté les domU, le dom0. Attendu les quelques secondes nécessaires et
relancer le tout...
Alléluia, tout semble être rentrer dans l'ordre ! Mais je n'ai pas 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" du 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 du 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 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
>
> 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)?
>
Reply to: