La Fibre
Télécom => Réseau => VPN => Discussion démarrée par: renaud07 le 18 mars 2021 à 01:12:01
-
Bonsoir,
Il y a quelques jours, mon DSLAM a été changé ce qui m'a enfin permis de migrer en DHCP.
A priori si tout fonctionne bien pour la navigation normale, je rencontre un gros problème avec mon tunnel wireguard qui était qu'une stabilité remarquable avant la migration. Maintenant, je ne peux plus utiliser certains protocoles (genre SMB) mais HTTP et SSH par exemple fonctionnent presque comme si de rien n'était. Le plus troublant est que dans une machine virtuelle (virtualbox), tout est purement et simplement inaccessible, j'arrive seulement à ping les équipements, mais aucun protocole ne fonctionne.
Lorsque j'étais en PPPoE j'avais :
-tunnel V6 HE (pour avoir une IP fixe) : MTU 1472
-interfaces wg MTU 1420
-le reste du LAN en 1500
En DHCP :
-plus de tunnel HE (je me connecte en V4)
-interfaces wg toujours en 1420
Avec cette config, HTTP et SSH fonctionnent de même que les partages SMB mais seulement à partir de mon PC portable en wifi ??? (sur mon desktop relié par câble, c'est niet). Depuis une VM (sur le portable ou le desktop, rien ne fonctionne comme mentionné précédemment).
Je me suis alors dit que je devrais peut-être augmenter légèrement la MTU des interfaces WG à 1440 pour éviter la fragmentation : ça ne fonctionne pas mieux.
Voici un exemple de ce que j'ai quand je fais une capture de VM windows (ici c'est une tentative d'ajout d'une station à mon domaine active directory) c'est peu ou prou la même si je tente d'accéder à l'interface du routeur en face.
J'ai l’impression que ça touche TCP et non UDP car tout ce qui est requête DNS par ex, passe bien.
Merci d'avance
-
Je viens repasser en PPPoE sur les 2 connexions pour voir si mon problème se résolvait, mais ce n'est pas le cas... toujours impossible d'accéder au LAN d'en face via les VM.
Franchement je ne vois pas ce qui pourrait clocher. La seule chose qui a changée dans le setup c'est la version d'OWRT sur le routeur "remote" qui est en 18.06.0, j'avais déjà eu des problèmes de stablité par le passé avec cette version, et je l'avais remise pour tester la connectivité IPv6 car sinon le client n'était pas en mesure d'envoyer les options.
Je vais donc faire un rollback sur la 17.04. En espérant que ce soit bien la source du problème.
-
Firmware d'origine restauré... ça ne fonctionne toujours pas :(
Honnêtement j'ai plus d'idée. Tout est comme à l'origine et rien... ou alors c'est le DSLAM lui-même (je n'ai pas pensé de faire un test complet avant de modifier) mais ça serait quand même très improbable.
-
Avec cette config, HTTP et SSH fonctionnent de même que les partages SMB mais seulement à partir de mon PC portable en wifi ??? (sur mon desktop relié par câble, c'est niet).
C'est bizarre cette histoire.
Ils sont montés où tes tunnels ? Directement sur le PC fixe ?
Je n'ai pas très bien compris pourquoi le tunnel HE était HS. Tu peux en dire plus ?
-
C'est vrai que j'aurais du détailler un peu.
Les tunnels HE sont montés directement sur les routeurs. Ils servent exclusivement d'ip fixe pour WG.
Pour WG, de mon côté c'est sur mon Raspberry Pi et de l'autre il est dans une VM debian sur proxmox.
Concernant le tunnel HE "HS" il ne l'a jamais été. Vu que j'ai du DHCP et une IPv4 fixe maintenant je l'avais simplement enlevé de l'équation.
Pour mes partages SMB, une fois que j'ai eu fini de tout remettre d’origine (donc PPPoE + HE) j'ai refait un nouveau test et cette fois j'arrive bien à y accéder depuis mon PC fixe... Bref, c'est un peu confus.
Seules les VM et je viens de le découvrir mon smartphone n'a plus accès au LAN d'en face. Alors que ça fonctionnait hyper bien depuis des mois auparavant. Vraiment je ne comprends pas où ça coince.
J'ai à priori trouvé un contournement possible pour les VM : en les mettant en mode NAT, elles utilisent l'ip de l’hôte et là le trafic passe bien, mais ce n'est pas idéal...
-
Oh pu**** j'ai enfin trouvé la source du problème et vous n'allez jamais le croire.
C'était une case cochée en trop : Drop invalid packets dans le firewall d'OWRT (dont je ne me rappelais plus que j'y avais touché tellement j'ai fait de manip ces derniers jours). Désormais tout est débloqué : les VM ont de nouveau accès au LAN en mode bridge ainsi que mon smartphone !
Je pouvais m'amuser longtemps avec la MTU ::)
Vais-je pouvoir enfin configurer la connexion en DHCP ? :P
-
Configuration DHCP effectuée sur les deux routeurs : ça tourne nickel.
Tout ça pour une maudite case...
-
C’est quand même étonnant qu’il faille autoriser les paquets invalides pour que WireGuard fonctionne correctement.
Et d’autant plus parce que de mon côté sur mon ER4 je droppe les paquets invalides sur toutes mes interfaces et que je n’ai aucun problème avec mon serveur WireGuard (qui, de plus, est une VM proxmox sur un hôte en mode bridge avec openvswitch)...
-
Moi aussi je suis perplexe.
C'est quel types de paquets qui sont considéré comme invalide ?
Car je vois que j'ai beaucoup de retransmission ou duplicate sur le trafic des VMs justement (et quasi rien à partir de l’hôte). Je me demande si ça vient pas de là.
-
J'ai fait un petit ping pour voir le temps que ça mettait : je passe de ~100ms à ~35ms en V4 vs V6 avec HE 8)
Mais une chose m'interpelle : si je fais un traceroute pour joindre l'autre bout je ne passe que par un routeur (ce qui est logique les 2 lignes sont sur le même NRA).
ping 86.194..x
PING 86.194.x.x (86.194.x.x) 56(84) bytes of data.
64 octets de 86.194.x.x : icmp_seq=1 ttl=62 temps=38.1 ms
64 octets de 86.194.x.x : icmp_seq=2 ttl=62 temps=36.5 ms
64 octets de 86.194.x.x : icmp_seq=3 ttl=62 temps=38.0 ms
64 octets de 86.194.x.x : icmp_seq=4 ttl=62 temps=36.8 ms
64 octets de 86.194.x.x : icmp_seq=5 ttl=62 temps=38.3 ms
64 octets de 86.194.x.x : icmp_seq=6 ttl=62 temps=37.3 ms
64 octets de 86.194.x.x : icmp_seq=7 ttl=62 temps=36.4 ms
64 octets de 86.194.x.x : icmp_seq=8 ttl=62 temps=37.1 ms
64 octets de 86.194.x.x : icmp_seq=9 ttl=62 temps=37.9 ms
64 octets de 86.194.x.x : icmp_seq=10 ttl=62 temps=36.8 ms
^C
--- statistiques ping 86.194.x.x ---
10 paquets transmis, 10 reçus, 0 % paquets perdus, temps 9012 ms
traceroute 86.194.x.x
traceroute to 86.194.x.x (86.194.x.x), 30 hops max, 60 byte packets
1 bt.lpa.lan (192.168.1.1) 2.769 ms 2.634 ms 2.947 ms
2 80.10.238.65 (80.10.238.65) 19.792 ms 21.025 ms 24.904 ms
3 lfbn-lyo-1-x-x.w86-194.abo.wanadoo.fr (86.194.x.x) 40.273 ms 42.827 ms 43.106 ms
Mais ce que je n'explique pas c'est qu'un ping vers lafibre soit plus rapide à ~20ms avec pas moins de 7 routeurs traversés.
ping lafibre.info
PING lafibre.info (80.67.167.77) 56(84) bytes of data.
64 octets de lafibre.cust.milkywan.net (80.67.167.77) : icmp_seq=1 ttl=54 temps=21.7 ms
64 octets de lafibre.cust.milkywan.net (80.67.167.77) : icmp_seq=2 ttl=54 temps=22.3 ms
64 octets de lafibre.cust.milkywan.net (80.67.167.77) : icmp_seq=3 ttl=54 temps=21.7 ms
64 octets de lafibre.cust.milkywan.net (80.67.167.77) : icmp_seq=4 ttl=54 temps=22.6 ms
64 octets de lafibre.cust.milkywan.net (80.67.167.77) : icmp_seq=5 ttl=54 temps=21.4 ms
64 octets de lafibre.cust.milkywan.net (80.67.167.77) : icmp_seq=6 ttl=54 temps=22.9 ms
64 octets de lafibre.cust.milkywan.net (80.67.167.77) : icmp_seq=7 ttl=54 temps=21.7 ms
64 octets de lafibre.cust.milkywan.net (80.67.167.77) : icmp_seq=8 ttl=54 temps=24.7 ms
64 octets de lafibre.cust.milkywan.net (80.67.167.77) : icmp_seq=9 ttl=54 temps=21.7 ms
64 octets de lafibre.cust.milkywan.net (80.67.167.77) : icmp_seq=10 ttl=54 temps=23.3 ms
^C
--- statistiques ping lafibre.info ---
10 paquets transmis, 10 reçus, 0 % paquets perdus, temps 9015 ms
rtt min/avg/max/mdev = 21.361/22.405/24.655/0.959 ms
traceroute lafibre.info
traceroute to lafibre.info (80.67.167.77), 30 hops max, 60 byte packets
1 bt.lpa.lan (192.168.1.1) 1.341 ms 1.481 ms 2.068 ms
2 80.10.238.65 (80.10.238.65) 19.300 ms 20.581 ms 21.198 ms
3 ae93-0.nclyo201.rbci.orange.net (193.251.109.166) 22.910 ms 23.999 ms 24.921 ms
4 ae42-0.nrlyo201.rbci.orange.net (193.252.101.234) 26.234 ms 27.897 ms 28.392 ms
5 ae43-0.nolyo101.rbci.orange.net (193.252.101.225) 28.717 ms 29.179 ms 29.827 ms
6 193.252.227.98 (193.252.227.98) 30.441 ms 28.583 ms 29.439 ms
7 appliwave.ly1-1.hopus.net (37.77.39.11) 30.045 ms 21.659 ms 19.765 ms
8 lo0.ccr2004.edge.vnx.bb.ip4.milkywan.net (80.67.167.2) 20.899 ms 25.975 ms 27.705 ms
9 te0.rb4011.col.vnx.infra.ip4.milkywan.net (80.67.167.194) 27.656 ms 27.619 ms 20.033 ms
10 lafibre.cust.milkywan.net (80.67.167.77) 21.654 ms 23.886 ms 25.828 ms
Une idée ?
-
Mais une chose m'interpelle : si je fais un traceroute pour joindre l'autre bout je ne passe que par un routeur (ce qui est logique les 2 lignes sont sur le même NRA).
L'autre bout de ton tunnel WG est sur une autre ligne ADSL ?
Une idée ?
Visiblement, entre toi et le premier routeur (80.10.238.65) tu as 19ms. Donc je trouve normal que tu ais 38ms pour aller sur un autre ADSL proche de chez toi.
L'ADSL amène beaucoup de latence. Beaucoup plus que la fibre (c'est sûrement une histoire de codage/décodage, correction d'erreurs, mais je ne m'y connais pas trop en ADSL).
Pour lafibre.info, le ping n'est que légèrement supérieur à 21ms car tu es visiblement près de Lyon, et Orange est connecté à Milkywan à Lyon. Or, lafibre.info est porté par Milkywan (au moins en partie), et est près de Lyon. Ce qui fait que tu as très peu de ping vers lafibre.info
-
L'autre bout de ton tunnel WG est sur une autre ligne ADSL ?
Yep
Visiblement, entre toi et le premier routeur (80.10.238.65) tu as 19ms. Donc je trouve normal que tu ais 38ms pour aller sur un autre ADSL proche de chez toi.
L'ADSL amène beaucoup de latence. Beaucoup plus que la fibre (c'est sûrement une histoire de codage/décodage, correction d'erreurs, mais je ne m'y connais pas trop en ADSL).
Pour lafibre.info, le ping n'est que légèrement supérieur à 21ms car tu es visiblement près de Lyon, et Orange est connecté à Milkywan à Lyon. Or, lafibre.info est porté par Milkywan (au moins en partie), et est près de Lyon. Ce qui fait que tu as très peu de ping vers lafibre.info
Après réflexion j'en étais arrivé un peu à la même conclusion. J'ai plus de latence entre mes 2 lignes car les paquets doivent passer 4 fois par de l'adsl alors que vers la fibre.info, la majorité passe par de la fibre et 2 fois par la ligne.