Auteur Sujet: OVH filtrerait certains types de tunnels? (Lu 3157 fois)

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 :

Code: [Sélectionner]

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?

obinou · « **Réponse #1 le:** 14 mai 2019 à 09:30:26 »

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)

vivien · « **Réponse #2 le:** 14 mai 2019 à 10:12:53 »

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

Code: [Sélectionner]

[Match]

[Network]
Tunnel=he-ipv6

sudo nano /etc/systemd/network/he-ipv6-tunnel.netdev

Code: [Sélectionner]

[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=255

Note: 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

Code: [Sélectionner]

# 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

altf4arnold · « **Réponse #3 le:** 14 mai 2019 à 18:14:13 »

Citation de: vivien le 14 mai 2019 à 10:12:53

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é

cali · « **Réponse #4 le:** 14 mai 2019 à 18:25:16 »

Le trafic GRE n'est pas bloqué chez OVH.

Il faudrait un peu de tcpdump..

altf4arnold · « **Réponse #5 le:** 14 mai 2019 à 18:36:15 »

Citation de: cali le 14 mai 2019 à 18:25:16

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)

Hugues · « **Réponse #6 le:** 15 mai 2019 à 13:10:40 »

C'est du 6in4 (proto 41 contre 47 pour GRE) de mémoire...

BadMax · « **Réponse #7 le:** 16 mai 2019 à 12:41:57 »

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.

altf4arnold · « **Réponse #8 le:** 16 mai 2019 à 17:47:37 »

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 :

Code: [Sélectionner]

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

BadMax · « **Réponse #9 le:** 16 mai 2019 à 21:49:57 »

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.

altf4arnold · « **Réponse #10 le:** 16 mai 2019 à 22:21:14 »

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

Code: [Sélectionner]

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

Code: [Sélectionner]

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

Code: [Sélectionner]

ip -6 neigh | grep 2001:470 n'output rien

BadMax · « **Réponse #11 le:** 16 mai 2019 à 22:31:24 »

Il faut aussi faire un tcpdump de l'autre côté pour savoir si le trafic arrive.