La Fibre
Télécom => Réseau => 
VPN => Discussion démarrée par: Fric-Box le 21 février 2020 à 09:06:38
-
Bonjour à tous,
Je poste ici car j'ai un "problème" assez étrange que je n'arrive pas à régler. J'ai un serveur Kimsufi avec IPv6 fonctionnelle. À la maison, j'ai une installation full IPv6 fonctionnelle. Lorsque je navigue avec ma connexion, je suis en IPv6 sur tous les sites qui le prennent en charge. J'héberge un serveur Wireguard sur le Kimsufi, auquel je me connecte de mes pc à la maison, le tout avec des configs IPv6 et IPv4. Tout fonctionne, j'arrive à joindre les sites en IPv4, IPv6 et IPv6 Only (exemple : https://ipv6-c.lafibre.info/images_test/). Le problème c'est que lorsque le site prend en charge les deux systèmes, c'est l'IPv4 qui est utilisée. Or j'aimerais que l'IPv6 soit utilisée en priorité. Avez-vous une astuce pour que ça fonctionne ?
Config serveur :
[Interface]
#wg0
PrivateKey = oKqku**Clé supprimée**NI1ng=
Address = 10.10.0.1/24
Address = fd42:42:42::1/64
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 51234 -j DNAT --to-destination 10.10.0.2:51234; ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; ip6tables -t nat -A PREROUTING -i eth0 -p tcp --dport 51234 -j DNAT --to-destination [fd42:42:42::2]:51234
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; iptables -t nat -D PREROUTING -i eth0 -p tcp --dport 51234 -j DNAT --to-destination 10.10.0.2:51234; ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ip6tables -t nat -D PREROUTING -i eth0 -p tcp --dport 51234 -j DNAT --to-destination [fd42:42:42::2]:51234
ListenPort = 443
[Peer]
#client1(ordiFlo)
PublicKey = 95XCjLF1nu**Clé supprimée**yu5DkLeYDg=
AllowedIPs = 10.10.0.2/32, fd42:42:42::2/128
Config client :
[Interface]
PrivateKey = 2LHU**Clé supprimée**lov18=
Address = 10.10.0.2/32, fd42:42:42::2/128
DNS = 1.1.1.1
[Peer]
PublicKey = AiF2**Clé supprimée**qk8=
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = [2001:**IPv6duserveur::1]:443
PersistentKeepalive = 25
-
J'ai remarqué la même chose, et apparemment c'est un choix fait par les développeurs de wireguard (en tout cas ça se voit dans le code source).
-
Tiens donc... Merci de ta réponse, si quelqu'un peut m'expliquer ce choix, parce que j'ai du mal à le comprendre... :o
-
Je comprend pas bien le problème. Le choix du protocole se fait par l'application cliente utilisée qui soit délègue a l'OS la réso DNS soit fait du happy eyeballs.
En quoi le tunnel intervient ?
edit: sur Windows, par défaut les IPv4 sont prio sur les IPv6 ULAs (cf netsh interface ipv6 show prefixpolicies)
Commes tu utilises des ULAs et pas GUAs le comportement est différent. Ce n'est pas a cause du tunnel lui-même mais a cause du type d’adresses IPv6 utilisées.
sur client Linux c'est dans /etc/gai.conf
-
bonjour,
j'avais le même souci avec des adresse fd sous android... pour résoudre le souci, j'ai utilisé une solution "crade" en faisant des adresses ipv6 3000::1 3000::2 3000::3 ...
je sais bien que c'est une solution crade, mais j'ai pas trouvé d'autre solution
si il en existe une / d'autres, sans mettre un range d'une connexion spécifique, je suis preneur.
Jerem
-
j'avais le même souci avec des adresse fd sous android...
Tu parles d'un problème différent: La préférence entre IPv6 et IPv4 à l'intérieur du tunnel, et oui, tu as raison, pour beaucoup de systèmes IPv4 à la préférence sur IPv6 ULA (et c'est pourquoi sur mes DNS internes je n'annonce plus d'enregistrement A vu que tous ce que j'héberge est en dual stack).
Le sujet ici c'est l'établissement du tunnel (les 2 endpoints étant sur internet ils ont tous les 2 des adresses IPv6 publiques donc le problème de préférence devrait être à l'avantage d'IPv6).
Ok, donc c'est moi qui ait mal compris je pense. J'ai cru que le sujet était qu'en cas de dual stack des 2 cotés, ce soit IPv4 qui soit privilégié pour la communication entre les 2 endpoints, ce qui en pratique est le cas, au moins pour certains clients : mon iPhone en dual stack IPv4/IPv6 publiques établit systématiquement un tunnel en IPv4 vers mon serveur aussi en dual stack. Evidemment j'ai bien un enregistrement A et AAAA pour le FQDN de mon serveur wireguard. Dans les mêmes conditions, le téléphone privilégie IPv6 pour tout le reste (safari par exemple).
Et pour revenir au sujet, pour les mêmes raisons que vous j'ai pour l'instant abandonné l'idée de faire de l'IPv6 dans mes tunnels wireguard (parce que de toute façon je n'ai pas envie de faire du NAT6), vu que je n'ai pas la garantie d'avoir un préfixe fixe chez Orange. Je reconsidérerai ce choix quand https://github.com/WireGuard/wg-dynamic/blob/master/docs/idea.md sera une réalité.
-
Merci pour ces réponses fort instructives !
-
Je me suis installé un serveur wireguard et je constate le même fonctionnement avec des ULA.
Je vais voir comment on configure wireguard avec des GUA (enfin si c'est possible).
-
les ULA moins prio que les IPv4, c'est normal, c'est by design :)
-
Configurer des GUA ou des ULA c’est la même chose, la différence c’est que si le préfixe fourni par l’opérateur change, alors il faut modifier la configuration sur le serveur et sur tous les clients, ce qui est plutôt chiant si ça arrive souvent...
-
J'avoue que je sèche, je vois la manipulation avec DNAT mais avoir un préfixe en direct, je n'ai pas encore réussi.
-
Le serveur wireguard est sur un routeur perso connecté en direct ? Sur un routeur perso ou PC derrière une box ?
Si le serveur est sur le routeur d'accès, ça devrait fonctionner directement comme de l'ULA, mais sans mettre de DNAT évidement.
Si le serveur est derrière une box opérateur, là c'est mal barré, parce qu'il faudrait pouvoir rajouter une route dans la box, ce qui est impossible, sauf à ma connaissance chez Free.
Chez moi j'ai ce schéma:
ONT <---> ER4 <---> routeur VyOS (VM proxmox)
Mon serveur Wireguard est sur le routeur VyOS. Ma méthode est la suivante:
- Je prends un /64 non utilisé dans le /56 fourni par Orange (qui peut changer, mais ça ne m'est pas arrivé depuis plus d'un an)
- Je configure l'interface wg0 sur le routeur VyOS avec ce /64, ainsi que tous les clients wireguard
- Je fais de l'OSPFv3 (geek inside et clairement overkill) entre mon ER4 et le routeur VyOS pour que l'ER4 soit au courant qu'il doit router le /64 choisi en "1" vers le routeur VyOS. On peut faire sans mais alors il faut rajouter une route statique dans le routeur d'accès...
- Si le /56 fourni par Orange change, je recommence "1" et "2" (et "3" si on n'utilise pas de protocole de routage)
-
Je suis dans un cas simple, le serveur est sur le routeur d'accès mais même en taillant un /64 dans le /56 que j'ai, l'IPv6 n'est pas fonctionnelle.
Je vais reprendre la doc de wireguard.
-
Est-ce qu'une interface wireguard peut fonctionner avec ndppd ?
-
C'est moche et pas "think ipv6", mais ici, le plus simple que j'ai trouvé, c'est :
- endpoint ipv4 only
- Passer le serveur d'un ::1/64 sur un subnet en ::1/72 en fixe (dans les network-scripts/ifcfg-eth0)
- Configurer l'interface wg0 sur un autre /72 en fixe
- Ajouter les adresses des peers sur ce même subnet
Ça fonctionne plutôt bien. Et le truc drôle, c'est si je supprime le MASQUERADE en ipv4, on se retrouve avec un fonctionnement ipv6 only :)
-
Petit déterrage pour signaler un problème assez gênant.
Par rapport à la priorisation IPv4, y'a une belle régression sur le mobile chez Bouygues et Orange en IPv6 only : Si le 464XLAT ne fonctionne pas pour X ou Y raison, impossible de se connecter au VPN sans manip supplémentaire.
Bien que le DNS64 fasse son boulot et renvoie une ipv6, il renvoie aussi l'ipv4 et c'est le drame : Wireguard sélectionne l'ipv4 et commence sa séquence d'initialisation, qui évidemment n’aboutira jamais
Seule solution : mettre en dur l'adresse DNS64isé ou avoir un serveur compatible ipv6.
-
Ça c'est plus un problème côté Wireguard qui je ne sais pour qu'elle raison met IPv4 en prioritaire pour le tunnel et même le traffic a l'intérieur... J'espère qu'un jour ça sera changé...
-
Bien que le DNS64 fasse son boulot et renvoie une ipv6, il renvoie aussi l'ipv4 et c'est le drame : Wireguard sélectionne l'ipv4 et commence sa séquence d'initialisation, qui évidemment n’aboutira jamais
Seule solution : mettre en dur l'adresse DNS64isé ou avoir un serveur compatible ipv6.
Je confirme que les VPN d'entreprise ont une facheuse tendance à avoir des soucis sur un réseau IPv6 only. Ils sont bien souvent configurés avec une seule IPv4 littérale à la place d'un record DNS...
J'ai eu le cas avec le VPN d'un client (openvpn dans ce cas) et j'ai fini par faire la même manip que toi: convertir l'IPv4 littérale en IPv6 dans le préfixe NAT64.
Ca peut valoir le coup de faire un bugreport en détaillant ton use case, pour faire prendre conscience aux développeurs/administrateurs IT qu'il n'est pas rare d'être connecté à un accès single-stack IPv6-only de nos jours.
-
hello,
Si ça peut aider, j'avais posté un message sur la liste wireguard parlant de ce problème, qui pour moi est une véritable régression
https://lists.zx2c4.com/pipermail/wireguard/2021-January/006251.html
si l'ipv6 est dispo, il faut utiliser l'ipv6, et sinon, se rabatre sur l'ipv4. je comprends pas qu'on puisse faire autrement, sans nous laisser le choix, en plus de ça.
du coup, si je veux utiliser mon tunel wg en ipv6, je suis obligé de faire une entré AAAA uniquement et quand j'arrive sur un réseau qui a que de l'ipv4, je suis bloqué.
Jerem
-
Ca peut valoir le coup de faire un bugreport en détaillant ton use case, pour faire prendre conscience aux développeurs/administrateurs IT qu'il n'est pas rare d'être connecté à un accès single-stack IPv6-only de nos jours.
C'est mon VPN perso, donc c'est pas trop gênant (c'est d'ailleurs pour ça que j'ai réactivé l'ipv6 y'a pas longtemps quand je me suis rendu compte du problème).
-
Pourrais tu tester avec Tailscale (c'est gratuit) pour voir si leur client Android a le meme souci (a priori ils utilisent wireguard-go et pas la version Java de Wireguard).
au pire si tu ne veut pas de Tailscale, tu peux toujours basculer sur https://github.com/juanfont/headscale qui est compatible avec le client Android Tailscale.
-
J’avais regardé un peu le code source de wireguard-go pour comprendre (parce qu’il y a exactement le même problème sur iOS), et en fait il s’avère que c’est le comportement par défaut de je ne sais plus quelle librairie Go qu’ils utilisent. J’ai pas cherché à patcher et faire une version custom du client iOS cependant.
-
Je n'ai pas testé en 4G/5G mais avec Android en wifi , tailscale fait bien le tunnel sur IPv6 en prio.