La Fibre
Télécom => Réseau => 
IPv6 => Discussion démarrée par: altf4arnold le 24 avril 2019 à 00:51:30
-
Bonjour,
Je loue un serveur chez soyoustart (donc OVH).
J'ai actuellement activé l'IPv6 sur toutes mes VM présentes dessus.
OVH fournis un /56 (oui ils disent que c'est un /64. Mais si on suit leur guide ici : https://docs.ovh.com/fr/dedicated/network-ipv6/ ça ne marcheras pas en /64)
Actuellement, j'ai une IPv6 publique sur une VM qui gère des tunnels VPN qui actuellement fonctionnent en full IPv4. Ce que j'aimerai, c'est dédier un /64 complet (ou plus petit si nécessaire) aux machines dans ces tunnels, mais j'aimerai ne pas faire de bridge et laisser mon serveur faire du routage.
Par contre, vu la façon dont OVH déploie son V6, je ne sais pas si il existe une technique qui permet d'annoncer à OVH que X adresses V6 sont utilisées par ce serveur tout en attribuant ces adresses a des machines dans le tunnel se trouvant derrière lui. Y' a-t-il un moyen de le faire? ???
-
L'équivalent d'arp proxy en IPv6 est ndp proxy.
La version incluse dans le noyau linux est un peu contraignante (définition du proxy ip6 par ipv6) mais il existe des deamon userland plus efficace comme ndppd (https://github.com/DanielAdolfsson/ndppd).
-
Je viens de faire un test avec NDP.
J'ai plusieurs VM reliées via un virtual switch directement au routeur d'OVH. En faisant un ping6 depuis un de mes clients VPN, je parviens à ping toutes les machines présentes sur le même virtual switch mais je ne parviens pas à passer le routeur OVH ni à le ping. (J'ai vérifié dans mes routes et je n'ai rien vu de suspect).
ça indique donc que le IPv6 forwarding est bien activé et que le NDP fonctionne. Cependant, je bloque sur pourquoi le routeur d'OVH ne semble pas comprendre d'ou provient cette IP alors que tout les autres noeuds sur le virtual switch le voient. (Je précise que toutes les VM reliées au Vswitch ont un V6 entièrement fonctionnel)
Je précise que je n'ai configuré de pare-feu V6 nulle part (honte à moi)
-
OVH fournis un /56 (oui ils disent que c'est un /64. Mais si on suit leur guide ici : https://docs.ovh.com/fr/dedicated/network-ipv6/ ça ne marcheras pas en /64)
tu peux détaillé ce point stp ?
Je viens de faire un test avec NDP.
J'ai plusieurs VM reliées via un virtual switch directement au routeur d'OVH.
avec NDP ou NDP Proxy ? ce n'est pas le meme chose....
C'est quel virtual switch que tu utilises ?
De ce que je comprend du "machin" d'OVH appelle IPv6 (sigh) ils ne routent pas le prefix (comme n'importe qui de sensé ferait) mais utilisent NDP donc une adresse MAC <-> une IPv6 et par défaut tu ne peux utiliser qu'une IPv6. Il faut déclarer une vMAC pour utiliser plusieurs IPv6.
Ensuite il faut "ndp proxy" entre une "vm routeur" qui porte la vmac coté ovh et les autres.
un truc du genre:
ovh -- (vmac) 'vm routeur' -- lan virtuel -- autres vms
good luck.
-
tu peux détaillé ce point stp ?
Tu remarqueras que OVH te donne un /64 et te place la gateway hors du range /64. Pour que ça fonctionne, tu dois passer en /56
Je vais voir au niveau du proxy
-
Ca ne veut pas dire que c'est un /56 qui t'es alloué ça, peut-être que c'est juste que la GW est mutu avec d'autres clients.
-
avec NDP ou NDP Proxy ? ce n'est pas le meme chose....
C'est quel virtual switch que tu utilises ?
C'est un NDP proxy que j'ai fait. J'utilise le virtual switch de ESXI.
Ca ne veut pas dire que c'est un /56 qui t'es alloué ça, peut-être que c'est juste que la GW est mutu avec d'autres clients.
Je viens de réduire le subnet pour être certain. No change
-
Tu remarqueras que OVH te donne un /64 et te place la gateway hors du range /64. Pour que ça fonctionne, tu dois passer en /56
Tu peux joindre n'importe quelle IPv6 sur une interface sans besoin d'avoir d'être dans le meme prefix (/64 ou plus) que cette IPv6 ou sans passer par la route par défaut. IPv6 est tres différent d'IPv4 a ce niveau.
lecture recommandée: https://tools.ietf.org/html/rfc5942
pour 'voir' le voisinage réseau:
ping6 -c2 -I eth0 ff02::1
ip -6 neigh(ajuster eth0 a l'interface voulue).
on ping6 en broadcast sur ff02::1 (https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml#node-local) = tous les noeuds. puis on affiche le voisinage.
ca donnera des infos sur leur redondance notamment.
C'est un NDP proxy que j'ai fait. J'utilise le virtual switch de ESXI.
Avant de faire un ndp proxy, met 2 ou 3 IPv6 sur la machine qui fait le proxy pour voir si ca marche.
-
Je viens de lire ça :
Si vous désirez utiliser plus d’une adresse IPv6 sur votre serveur (ou si vous désirez l’utiliser sur une Machine Virtuelle) vous devez avoir une adresse IP failover configurée avec une vMAC. Autrement, l’adresse IPv6 ne sera pas routée par nos routeurs et switchs.
Les oufs :-)
Et ça aussi :
Tous les serveurs dédiés comprennent un block /64 IPv6 mis à votre disposition.
C'est faux puisque :
La passerelle par défaut de votre Block IPv6 (IPv6_GATEWAY) est toujours IP:v:6FF:FF:FF:FF:FF.
Donc tout le préfixe n'est pas à la disposition du serveur.
Le préfixe n'est donc pas routé vers le serveur, alors le mieux c'est de créer des alias de l'interface réseau avec ces « vMAC », d'annoncer les IP depuis le serveur et les router vers l'interface VPN.
-
Par rapport à ce qu'ils disent avec des IP de failover, si j'ai bien compris, les ip de failover comme ils les appelles sont les IPv4 Que l'on peut commander qui elles ont effectivement besoin d'être configurées avec une mac address à encoder dans l'interface web de gestion d'OVH. Du coup, je suppose que pour le V6, ils regardent quels mac address sont déjà configurées dans le v4 et n'autorisent que celles-là vu qu'en tout cas chez soyoustart, il n'y a pas moyen d'attribuer mabuellement une mac à une V6 (sinon ça aurait du passer avec un NDP proxy vers OVH tout comme avec les autres machines)
Du coup, je suppose qu'il va faloir que je déclare les addresses avec la mac de la VM elle même pour ensuite les forwarder (y a-t-il un nom pour cette méthode?)
Avant de faire un ndp proxy, met 2 ou 3 IPv6 sur la machine qui fait le proxy pour voir si ca marche.
J'ai testé et ça fonctionne. Il est possible de donner plusieurs v6 en même temps au serveur lui même
-
L'implèmentation de l'IPv6 chez OVH est encore plus constérnante que chez Scaleway, c'est assez stupéfiant.
Effectivement la passerelle/next hop se situe en dehors du réseau ;-)
Ils parlent de vMAC sûrement pour pouvoir faire du bridge mais il vaut mieux s'en passer et laisser le serveur faire office de routeur.
Dans un premier temps il semble judicieux de rajouter une route pour joindre la passerelle en dehors du réseau et ne pas avoir à utilser un réseau /56 :
ip -6 route add $next_hop dev $interface
ip -6 route add default via $next_hope $interface
Ensuite il faut activer le proxy_ndp et le forwarding :
sysctl net.ipv6.conf.all.proxy_ndp=1
sysctl net.ipv6.conf.all.forwarding=1
Puis ajouter une IP à la table proxy :
ip neigh add proxy $une_ipv6 dev $interface
Puis router cette même IP vers l'interface du tunnel :
ip route add $ipv6 dev $interface_tun
Exemple concret :
Réseau /64 : 2607:5300:60:62ac::/64
Next hop : 2607:5300:60:62ff:ff:ff:ff:ff
IP pour le client VPN : 2607:5300:60:62ac::1234
Interface réseau : eth0
Interface VPN : tun0
Interface VPN client : tun1
Côté serveur OVH :
sysctl net.ipv6.conf.all.proxy_ndp=1
sysctl net.ipv6.conf.all.forwarding=1
ip route add 2607:5300:60:62ff:ff:ff:ff:ff dev eth0
ip route add default via 2607:5300:60:62ff:ff:ff:ff:ff dev eth0
ip neigh add proxy 2607:5300:60:62ac::1234 dev eth0
ip route add 2607:5300:60:62ac::1234 dev tun0
Côté client VPN :
ip add add 2607:5300:60:62ac::1234 dev tun1
ip -6 route add default dev tun1
-
Exemple concret :
Réseau /64 : 2607:5300:60:62ac::/64
Next hop : 2607:5300:60:62ff:ff:ff:ff:ff
IP pour le client VPN : 2607:5300:60:62ac::1234
Interface réseau : eth0
Interface VPN : tun0
Interface VPN client : tun1
Alors, ça va être long. J'ai donc fait comme indiqué ici (c'est à peu près ce que je suis entrain de tenter depuis le deuxième post de ce topic. Ne comprenant pas ce qui faisait que ça ne fonctionne pas, j'ai fais un PCAP de l'interface publique du serveur pour regarder comment celle-ci se comporte une fois que le NDP-Proxy est activé.
Le résultat montre que je peux bel et bien ping à travers cette interface mes autres machines présentes sur le virtual switch. Par contre, dès que je teste pour aller plus loins que le routeur, pas de réponse. Pourtant dans le PCAP, j'ai bien vu que la mac address source est la même que celle du serveur et que la mac address de destination est bien celle de la gateway OVH.
Le problème restant le même, je me suis dis que j'allais essayer de mettre l'adresse v6 de mon client directement sur mon serveur (histoire de voir si ça ça passe). Et là, en effet, cette adresse là peut ping l'extérieur et se faire ping. Du coup, je vire l'adresse du serveur et je la repasse au client et là, miracle, ça marche. Je me doute que c'est à cause d'un buffer du côté de chez OVH. Mais je ne comprends pas pourquoi en annoncant l'adresse comme apartenant à mon serveur c'est passé alors que le ndp proxy avait fonctionné sur les autres machines (et a donc fait la même chôse CAD annoncer l'IP sur la mac du serveur si j'ai bien compris)
-
Le résultat montre que je peux bel et bien ping à travers cette interface mes autres machines présentes sur le virtual switch.
Virtual Switch ? C'est à dire niveau 2 ? TAP ?
Si c'est ça c'est parce que tu annonces l'adresse avec la MAC du client et c'est une mauvaise idée. Mieux vaut laisser le serveur gérer le NDP.
-
Virtual Switch ? C'est à dire niveau 2 ? TAP ?
C'est du niveau 2. C'est le virtual-switch de VMWare ESXI qui est lui-même raccordé à la gateway
Si c'est ça c'est parce que tu annonces l'adresse avec la MAC du client et c'est une mauvaise idée. Mieux vaut laisser le serveur gérer le NDP.
L'adresse est annoncée avec la mac du serveur (j'ai suivi les commandes que tu as mises dans le post précédent)
-
L'adresse est annoncée avec la mac du serveur (j'ai suivi les commandes que tu as mises dans le post précédent)
Oui mais si le "virtual switch" est au niveau 2 il va y avoir conflit.
Laisse le serveur gérer tout ce qui est niveau 2 et route le niveau 3 derrière.
Si je devine bien tu as ton "virtual switch" qui comprend toutes les interfaces de tes machines virtuelles + l'interface du serveur. Il faut enlever l'interface du serveur du groupe.
-
Actuellement, ma topologie ressemble à ceci :
------------------ --------------------- -------------------
| | | | | |
| OVH |________________| Serveur VPN |________________ | Client VPN |
|_________| | |___________| |__________|
|
| ----------------------
| | |
|________| Autre serveur |
----------------------
Oui mais si le "virtual switch" est au niveau 2 il va y avoir conflit.
Je t'avoue que je ne vois pas trop comment vu que l'IPv6 du client est annoncée avec la mac du serveur et pas avec la mac du client
-
Actuellement, ma topologie ressemble à ceci :
------------------ --------------------- -------------------
| | | | | |
| OVH |________________| Serveur VPN |________________ | Client VPN |
|_________| | |___________| |__________|
|
| ----------------------
| | |
|________| Autre serveur |
----------------------
C'est quoi comme tunnel entre le serveur et le client ? TUN ou TAP ? ;-)
-
C'est du TUN. J'utilise tincVPN
-
C'est du TUN. J'utilise tincVPN
Ok donc ça devrait être bon.
# tcpdump -ni $INT 'host ${IP}'
-
Ok donc ça devrait être bon.
Oui ça devrait... Pourtant, ça n'a pas fonctionné jusqu'au moment ou j'ai donné la dite IP au serveur
-
Oui ça devrait... Pourtant, ça n'a pas fonctionné jusqu'au moment ou j'ai donné la dite IP au serveur
Le proxy NDP n'a pas fonctionné alors, il faut vérifier qu'il n'y a pas d'autres daemons qui tournent en même temps.