La Fibre
Télécom => Réseau => 
IPv6 => Discussion démarrée par: altf4arnold le 14 mai 2019 à 05:19:43
-
Bonjour, Bonsoir, je sais plus...
J'ai passé la nuit a troubleshooter un tunnel vers Huricane Electric qui était placé sur de l'IPv4 pour faire passer de l'IPv6 dedans.
La config /etc/network/interfaces ressemblait à ceci :
auto he-ipv6
iface he-ipv6 inet6 v4tunnel
address 2001:470:12:1d1::2
netmask 64
endpoint 216.66.84.54
local 51.68.176.170
ttl 255
gateway 2001:470:12:1d1::1
J'ai vérifié les valeurs, elles sont toutes correctes. Me demandant ou pouvait être le problème, j'ai essayé d'établir un autre tunnel du même type avec une autre personne et même résultat. Le tunnel n'arrive pas à fonctionner.
Cette personne avec qui j'ai testé m'a dit qu'elle avait déjà essayé ce genre de chôses il y'a quelques années depuis une machine OVH et que ça bloquais spécifiquement sur cette machine.
Est-il possible qu'OVH filtre ce genre de trafique? Si oui, est-ce en accord avec leur dires de réseau neutre?
-
Il ne me semble pas qu'OVH prétende particulièrement à une neutralité technologique. Ils annoncent dès le départ refuser /filtrer certains protocoles ou services , tel que l'IRC et l'ICMP (mais la liste est non exhaustive et non publiée) pour des raisons de protection de leur réseaux & de leurs clients.
Je ne suis pas d'accord avec ça et donc je ne fait plus partie de leurs clients, mais néanmoins on ne peux pas leur reprocher un double discours à ce niveau: On sais ce qu'on achète, et à chacun de faire ses choix.
Il n'est pas exclu non plus que, technologiquement, certaines de leurs solutions complique le fonctionnement des protocoles autres que TCP et UDP (je pense ici au VAC, mais il peux y avoir d'autres équipements tiers)
-
Selon HE, certaines versions récentes du noyau Linux ont un bogue dans le code anti-spoofing qui rompt la connectivité via un tunnel vers des destinations 6in4.
La commande suivante peut corriger cela, jusqu'à ce que le code du noyau soit corrigé :
ip tunnel 6rd dev he-ipv6 6rd-prefix $V6PTPNET/64 6rd-relay_prefix $TSERVV4IP/32
Replacer $V6PTPNET avec l'adresse du serveur IPv6, en supprimant le dernier 1 (donc 2001:470:a::1/64 devient 2001:470:a::/64)
Replacer $TSERVV4IP par l'adresse du serveur IPv4
Sinon de façon plus basique, tu as fait attention que ton système n'est pas passé sur Netplan pour la configuration réseau ?
Pour netplan, il faut créer les fichiers suivants :
sudo nano /etc/systemd/network/he-ipv6.network
[Match]
[Network]
Tunnel=he-ipv6
sudo nano /etc/systemd/network/he-ipv6-tunnel.netdev
[Match]
[NetDev]
Name=he-ipv6
Kind=sit
[Tunnel]
Independent=true
Local=192.168.0.x #IP privée si derrière NAT ou IP publique sans NAT
Remote=216.66.84.42 #Adresse IPv4 du Tunnel broker (ici le serveur de Paris)
TTL=255Note: Si vous utilisez une veille version de systemd (version 234 ou précédente), il faut supprimer la ligne "Independent=true"
Pour connaitre votre version de systemd : systemd --version
sudo nano /etc/netplan/01-netcfg.yaml
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
version: 2
renderer: networkd
ethernets:
he-ipv6:
dhcp4: no
dhcp6: no
addresses: ['2001:470:xxx:xxx::2/64']
gateway6: 2001:470:xxx:xxx::1
enp0s3:
...
sudo systemctl restart systemd-networkd
sudo netplan apply
-
Selon HE, certaines versions récentes du noyau Linux ont un bogue dans le code anti-spoofing qui rompt la connectivité via un tunnel vers des destinations 6in4.
La commande suivante peut corriger cela, jusqu'à ce que le code du noyau soit corrigé :
ip tunnel 6rd dev he-ipv6 6rd-prefix $V6PTPNET/64 6rd-relay_prefix $TSERVV4IP/32
Replacer $V6PTPNET avec l'adresse du serveur IPv6, en supprimant le dernier 1 (donc 2001:470:a::1/64 devient 2001:470:a::/64)
Replacer $TSERVV4IP par l'adresse du serveur IPv4
J'ai essayé avec ça et ce n'est pas passé. J'ai aussi vérifié que je n'étais pas sur netplan.
Du coup, il y'a en effet de fortes chances que ce soit filtré
-
Le trafic GRE n'est pas bloqué chez OVH.
Il faudrait un peu de tcpdump..
-
Le trafic GRE n'est pas bloqué chez OVH.
Il faudrait un peu de tcpdump..
En effet. Le trafique gré n'est pas bloqué chez OVH, j'ai actuellement plusieurs tunnels gre qui fonctionnent sur ce serveur. Mais ce tunnel là foire... (apparament, c'est pas du GRE)
-
C'est du 6in4 (proto 41 contre 47 pour GRE) de mémoire...
-
Hello
Comment/où as-tu configuré 51.68.176.170 ? Je vois que c'est une IP FO, l'as-tu attachée à une loopback, un alias ?
C'est peut-être ce qui gêne le fonctionnement du tunnel. Comme suggéré par Cali, un tcpdump aiderait à comprendre ce qui sort/reviens.
-
j'ai fait un tcpdump. Je constate que les paquets sortent. Quand je fais un ping, ça sort mais ça ne reviens pas.
Concernant l'adresse 51.68.176.170, elle a été configurée comme suit :
auto ens192
iface ens192 inet static
address 51.68.176.170
netmask 255.255.255.255
pointopoint 51.68.180.254
gateway 51.68.180.254
-
Je comprends pas, c'est une VM attachée à un bridge du host ? Le tcpdump tu le fais où ? Dans la VM ou sur le host ?
Si tu ne donnes pas toute ta config, on va avoir du mal à comprendre ton problème.
-
Il s'agit d'une VM sur un ESXI. Le virtual switch de ens192 est dirrectement raccordé à l'interface physique. Je fais mon tcpdump depuis la VM sur ens192 et de là, je vois l'ICMP qui sort mais rien qui revient
ceci sont des extraits de mon /etc/network/interfaces
auto ens192
iface ens192 inet static
address 51.68.176.170
netmask 255.255.255.255
pointopoint 51.68.180.254
gateway 51.68.180.254
auto he-de
iface he-de inet6 v4tunnel
address 2001:470:12:1d1::2
netmask 64
endpoint 216.66.84.54
local 51.68.176.170
ttl 255
Je précise que la commande ip -6 neigh | grep 2001:470 n'output rien
-
Il faut aussi faire un tcpdump de l'autre côté pour savoir si le trafic arrive.
-
Je n'ai pas accès à l'autre côté dans ce cas ci.
Cependant, ça a été fait début de semaine avec un ami, il ne recevait rien de son côté
-
Je t'ai envoyé une IP de test en MP.
-
UPDATE :
On a set up un link du même type avec BadMax (je pars du principe que c'est toi au vu de l'adresse email) et on a réussi à avoir un ping. Cependant, ça n'explique toujours pas du coup, pourquoi l'exacte même config ne passe pas avec HE. Je vais les contacter et j'ajouterai un update