Le Mon, 12 Sep 2011 19:58:33 +0200, "Jean-Yves F. Barbier" <12u...@gmail.com> a écrit :
> On Mon, 12 Sep 2011 19:06:31 +0200, Yann Cohen <y...@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)? > -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20110922185907.4eb37...@samyan.ianco.homelinux.org
