Utiliser Internet sans connexion IPv4

• Après une panne de courant, dans une situation où seule la connectivité IPv4 du côté du FAI était coupée tandis qu’IPv6 fonctionnait encore, un VPS Hetzner disposant à la fois d’IPv4 et d’IPv6 ainsi qu’un tunnel WireGuard ont été utilisés pour rétablir l’accès aux sites IPv4-only
• L’incident semblait venir de la couche CG-NAT, où les paquets IPv4 n’étaient pas correctement traduits et étaient abandonnés ; les services prenant en charge IPv6, comme Google et Meta, restaient accessibles
• En installant un serveur WireGuard sur le VPS et en configurant le client pour utiliser l’adresse IPv6 du VPS comme endpoint, le trafic IPv4 peut passer par le VPS et la navigation web classique être rétablie
• Le VPN professionnel et Docker nécessitaient un traitement séparé : ils ont été exécutés dans un espace de noms réseau basé sur vopono, avec des contournements comme unshare et un bind mount de /sys
• Le symptôme où seuls certains sites ne se chargeaient pas venait d’un MTU WireGuard trop élevé ; le réduire à 1280, le MTU minimal d’IPv6, a immédiatement résolu le problème

---

Panne après coupure de courant : seule l’IPv4 ne fonctionnait plus

• Après une coupure de courant, le disjoncteur a été réenclenché, mais GitHub et plusieurs sites web restaient inaccessibles, tandis que Google et Meta fonctionnaient normalement
• En vérifiant ping -6 et traceroute sur la machine locale et la page de diagnostic du routeur, le problème s’est avéré limité à la connexion aux serveurs IPv4
• Le FAI a indiqué qu’une visite d’un technicien pourrait être nécessaire et que cela pourrait prendre plusieurs jours après le week-end ; avec l’accès professionnel et le travail sur un article de recherche, il était difficile d’attendre la résolution de la panne
• Le VPS Hetzner existant disposait d’adresses IPv4 et IPv6 statiques, et comme le site de Hetzner prend en charge IPv6, il a été possible d’accéder à la console et de procéder à la configuration

La dépendance à IPv4 créée par NAT et CG-NAT

• Une adresse IPv4 fait 32 bits et, en excluant les blocs réservés, il n’existe qu’environ 3,7 milliards d’adresses IPv4 publiques, ce qui ne permet pas d’attribuer une adresse directe à chaque appareil connecté à Internet
• Le NAT permet à plusieurs appareils de partager une même IP publique
  • Un routeur domestique remplace l’IP locale d’un appareil, comme 192.168.1.xxx, par sa propre IPv4 publique
  • Sous Linux, conntrack conserve une table associant l’IP et le port source d’origine au port traduit
  • Lorsqu’un paquet de réponse arrive sur ce port, conntrack rétablit la destination vers l’IP et le port internes d’origine
  • Sous Linux, les correspondances enregistrées peuvent être consultées avec conntrack -L de conntrack-tools
• Le NAT agit comme un pare-feu implicite : les services d’un appareil local derrière le routeur sont difficiles à atteindre depuis l’extérieur sans redirection de port explicite
• En raison de la pénurie d’IPv4, les FAI peuvent aussi appliquer une couche supplémentaire de NAT en interne ; on parle alors de Carrier Grade NAT (CG-NAT)
  • De la même manière qu’un routeur domestique NATe plusieurs appareils locaux, le routeur du FAI NATe plusieurs routeurs domestiques
  • Selon le nombre d’adresses IPv4 détenues par le FAI et sa politique d’allocation, cela peut être répété sur plusieurs niveaux, par exemple à l’échelle régionale
• Dans cet incident, il semblait qu’à un endroit de la couche CG-NAT, les paquets IPv4 n’étaient pas correctement NATés et étaient abandonnés, coupant totalement le trafic IPv4
• Pour les méthodes de contournement de la traversée NAT, l’article de Tailscale How NAT Traversal Works est une bonne référence

Pourquoi IPv6 continuait de fonctionner

• Une adresse IPv6 fait 128 bits et, même en tenant compte des blocs réservés, fournit environ 3,4E38 adresses
• Il est courant qu’un routeur domestique reçoive un sous-réseau /64, ce qui représente 1,84E19 adresses
• Avec IPv6, chaque appareil peut avoir directement une adresse sur Internet sans utiliser de NAT sur le routeur domestique
  • Les problèmes de redirection de port sont réduits
  • En contrepartie, le routeur ou chaque appareil doit disposer de règles de pare-feu appropriées pour bloquer les nouvelles connexions externes arbitraires
• Comme IPv6 n’était pas soumis au CG-NAT, il n’a pas été affecté par cette panne
• Certains serveurs web, comme GitHub, ne sont toujours pas accessibles en IPv6, si bien qu’une simple connexion IPv6 ne permettait pas d’utiliser directement tout Internet

Créer un tunnel IPv4 au-dessus d’IPv6 avec WireGuard

• La solution a consisté à installer WireGuard sur le VPS et à configurer le tunnel de sorte que le client utilise l’adresse IPv6 du VPS comme endpoint
• Une fois le tunnel établi, le trafic IPv4 fonctionne normalement en passant par le VPS
  • La latence augmente en passant par le VPS
  • Le fonctionnement est proche d’un Dual-Stack Lite configuré manuellement
• Le serveur était un VPS Hetzner sur lequel Arch Linux avait déjà été installé avec vps2arch, en s’appuyant sur l’image Debian récente de Hetzner
• La configuration WireGuard s’appuyait sur l’exemple cas d’usage spécifique : serveur VPN de l’ArchWiki, avec l’ajout du trafic IPv6
• La configuration serveur inclut notamment
  • Address = 10.200.200.1/24, fd42:42:42::1/64, 2001:db8:abcd:1234::1/128
  • le forwarding IPv4 via MASQUERADE d’iptables
  • le NAT de l’ULA IPv6 avec SNAT --to-source d’ip6tables
  • l’activation du forwarding IPv4/IPv6
  • deux exemples de peers : foo, qui utilise directement une IPv6 Global Unicast Address, et bar, qui utilise une ULA IPv6 NATée
• Contrairement aux fichiers de configuration de style .ini, wg-quick permet de spécifier plusieurs fois PostUp et PostDown, puis exécute chaque commande dans l’ordre
  • L’implémentation correspondante se trouve dans wg-quick linux.bash

NAT IPv6, SNAT et configuration client

• IPv6 n’a pas forcément besoin de NAT ; si le VPS dispose d’un bloc IPv6 /64, comme chez Hetzner, il est possible d’attribuer directement une Global Unicast Address (GUA) aux peers
• Pour utiliser l’adressage direct, il faut remplacer l’Unique Local Address (ULA) du peer et de l’interface par une adresse IPv6 publique et supprimer les règles ip6tables MASQUERADE
  • Chaque peer devient directement adressable sur Internet avec l’adresse IPv6 qui lui a été attribuée
  • Cette approche est adaptée si l’on veut rediriger ses propres services depuis plusieurs appareils
  • Le pare-feu du VPS doit gérer correctement le trafic entrant
• Si l’on est certain que l’adresse IP du VPS est statique et ne changera pas, on peut utiliser SNAT au lieu de MASQUERADE
  • MASQUERADE consulte l’IP de l’interface à l’exécution
  • SNAT spécifie directement l’adresse, ce qui est légèrement plus efficace
• Dans la configuration client, l’adresse IPv6 du serveur doit être entourée de crochets, par exemple Endpoint = [2001:db8:abcd:1234::1]:51820
• AllowedIPs = 0.0.0.0/0, ::/0 envoie l’ensemble du trafic IPv4/IPv6 dans le tunnel
• Après exécution des deux côtés, la navigation classique a de nouveau fonctionné, et il était aussi possible de se connecter directement au serveur en SSH via les adresses IPv4 et IPv6 locales du tunnel
• Sous Linux, il a également été simple d’installer le client WireGuard sur la machine de sa femme

Isoler le VPN professionnel avec un espace de noms réseau

• Se connecter directement au VPN professionnel au-dessus de la connexion WireGuard provoquait des conflits et le rendait inutilisable
• vopono a été utilisé pour exécuter le VPN professionnel et les applications nécessaires dans un espace de noms réseau
• L’essentiel est de faire en sorte que la règle MASQUERADE transmette le trafic vers l’interface WireGuard en cours d’exécution (foo ou bar), et non vers l’interface réseau réelle
• Le trafic à l’intérieur de l’espace de noms ne tient pas directement compte des règles nftables WireGuard de l’hôte, mais il est en pratique routé via le tunnel WireGuard
• Quand il est disponible, wg-quick préfère nftables à iptables, ce qui évite les conflits avec les règles iptables standard de Docker
• Exemple d’exécution avec vopono

$ vopono -v exec --create-netns-only --provider None --protocol None -i bar bash
$ sudo ip netns exec vo_none_none bash
$ (inside netns) ./vpn.sh

• /etc/netns/vo_none_none/ est monté sur /etc par ip netns exec, ce qui permet de définir un resolv.conf propre à cet espace de noms
• Si l’on veut privilégier la résolution DNS IPv4, on peut aussi ajuster gai.conf de la même façon
  • Cette configuration a été utilisée pendant le débogage des problèmes de trafic du tunnel IPv6
  • L’exemple s’appuie sur une réponse AskUbuntu
• Après connexion au VPN professionnel, en plaçant le serveur DNS interne dans /etc/netns/vo_none_none/resolv.conf, les applications lancées ensuite dans cet espace de noms fonctionnent normalement
• Il est possible d’exécuter des applications comme Chrome dans l’espace de noms avec les droits d’un utilisateur standard

$ vopono -v exec -i bar --provider None --protocol None google-chrome-stable

Exécuter Docker dans le même espace de noms

• Docker ne fonctionne pas simplement en l’exécutant dans un autre espace de noms réseau comme une application ordinaire
  • Le socket Docker activé par systemd a été créé en dehors de l’espace de noms
  • La connectivité interne n’est donc pas assurée
• Même en arrêtant le Docker externe et en essayant de recréer dockerd et le socket dans l’espace de noms, le problème n’est pas immédiatement résolu
  • ip netns exec crée un mount namespace et remonte /sys
  • Le /sys/fs/cgroup de l’hôte n’est donc pas visible
• Dans ce cas, l’erreur suivante peut apparaître

Error: OCI runtime error: runc: runc create failed: no cgroup mount found in mountinfo

• Le contournement consiste à créer un bind mount de /sys avec unshare, puis à démonter le /sys interne créé par ip netns exec
  • Cette méthode s’appuie sur un article Unix StackExchange
  • Ensuite, le /sys dans le mount namespace devient un bind mount du /sys de l’hôte
• Exemple de commandes

$ sudo systemctl stop docker && sudo systemctl stop docker.socket
$ sudo -E unshare -m sh -c 'mount --bind /sys /sys; exec ip netns exec vo_none_none sudo --user youruser --preserve-env bash'
$ sudo umount /sys
$ sudo dockerd --host=unix:///var/run/docker-netns.sock --data-root=/var/lib/docker-netns
$ DOCKER_OPTS="--dns=YOURDNSHERE" DOCKER_HOST=unix:///var/run/docker-netns.sock sudo --user youruser --preserve-env docker ...

• En exécutant dockerd et les commandes Docker dans la même session, ils partagent le même espace de noms réseau et le même mount namespace
• La configuration DNS de Docker peut aussi être placée dans /etc/netns/vo_none_none/docker/daemon.json
• Cette approche a suffi pour les tâches nécessitant des conteneurs auxiliaires et des conteneurs connectés via le réseau Docker, mais elle peut ne pas fonctionner telle quelle pour des configurations Docker plus complexes nécessitant des bridges, par exemple

Déboguer un problème de MTU WireGuard

• Après redémarrage, la connexion WireGuard semblait active, mais seules certaines pages se chargeaient et des sites comme GitHub ne s’ouvraient pas
• ping, ping -6 et wg show étaient normaux, ce qui rendait la cause difficile à identifier
• Des pings de différentes tailles ont montré que les gros paquets échouaient

$ ping6 -s 1400 fd42:42:42::1
$ ping6 -s 1200 fd42:42:42::1
$ ping6 -s 800 fd42:42:42::1

• La taille 1400 échouait tandis que 1200 et 800 réussissaient, confirmant que la configuration MTU était en cause
• En réduisant le MTU de l’interface WireGuard locale, la pile IP du noyau ne crée plus de paquets plus grands que cette valeur
  • Le paquet UDP final, auquel s’ajoute l’overhead d’encapsulation WireGuard, n’est alors plus abandonné sur les liens du chemin dont le MTU est plus faible
• Chaque routeur sur le chemin possède son propre MTU, et les paquets plus grands que le plus petit MTU peuvent être abandonnés
• Le trafic du tunnel ajoute environ 32 octets d’overhead avec l’encapsulation WireGuard, ce qui peut aggraver les problèmes de MTU
• Les messages Path MTU Discovery peuvent être transmis par les routeurs intermédiaires via ICMP, mais les pare-feu abandonnent souvent l’ICMP, ce qui peut empêcher l’ajustement automatique
• Le MTU minimal défini par la spécification IPv6 est 1280 ; cette valeur devrait donc toujours fonctionner pour un tunnel WireGuard au-dessus d’IPv6

Options d’exploitation restantes après rétablissement

• La configuration obtenue inclut
  • un serveur VPN WireGuard sur un VPS disposant à la fois d’IPv4 et d’IPv6
  • la prise en charge à la fois d’IPv6 directe et de trafic IPv6 NATé
  • l’exécution du VPN professionnel dans un espace de noms réseau
  • l’exécution de Docker dans le même espace de noms réseau via le contournement unshare
  • le débogage des problèmes de MTU WireGuard
• En télétravail, les problèmes de connectivité Internet restent toujours un facteur de risque ; dans ce cas, les outils Linux ont permis de contourner l’incident sans attendre le rétablissement de la configuration par le FAI
• Le VPS Hetzner prend en charge les tunnels WireGuard et les usages généraux légitimes ; le scan de ports, l’usurpation de trafic et le minage de cryptomonnaies ne sont pas autorisés
• Les VPN prenant en charge la redirection de port, comme AirVPN, ProtonVPN ou AzireVPN, peuvent aussi servir d’alternative pour exposer les ports d’un serveur domestique sans dépendre du FAI
• Avec un routeur OpenWRT, il est possible de pousser plus loin le débogage côté routeur et de gérer ce type de contournement directement via WireGuard sur le routeur, plutôt que de le configurer séparément sur chaque appareil

[GN⁺]

Avis de Hacker News

• Le titre prête un peu à confusion. Plus exactement, il s’agit d’accéder à l’Internet IPv4 via un tunnel IPv6 passant par un VPS, ce qu’on appelle aussi souvent 4in6.
  Cela reste intéressant. Du point de vue d’un FAI, la nature des problèmes de support est assez différente selon qu’on casse IPv4 ou IPv6. Une panne IPv4 correspond généralement à un état clairement « down » : les utilisateurs sont très mécontents, mais le problème est simple. À l’inverse, une panne IPv6 se manifeste sous des formes étranges : panne partielle, démarrage lent à cause du fallback, passerelle persuadée qu’IPv6 est disponible, etc.

  • La dernière fois qu’IPv4 est tombé, je m’en suis surtout rendu compte parce que Github ne fonctionnait plus. Aujourd’hui, la plupart des sites web grand public fonctionnent même uniquement en IPv6.
    En revanche, les personnes dont le routeur n’avait que des serveurs DNS IPv4 configurés ont subi une panne totale. Si Microsoft avait fait un peu de ménage dans ses actifs défaillants, le principal souci aurait sans doute été de se souvenir du nom d’hôte mDNS attribué au routeur pour s’y connecter et vérifier si IPv4 était revenu.
  • La longue traîne d’IPv4 existe clairement, mais la dernière fois qu’IPv4 a été coupé chez moi, ma femme ne s’en est absolument pas aperçue. Google, Facebook, Apple/iCloud, ainsi que la plupart des hébergements CloudFlare, continuaient de fonctionner en IPv6.
  • C’est aussi mon expérience. Les problèmes IPv6 sont frustrants à classer et à reproduire, avec beaucoup de situations du type « ça marche sur mon ordinateur ».
  • La plupart des FAI bloquent encore purement et simplement IPv6. Beaucoup de petits opérateurs essaient IPv6 une fois puis oublient des choses comme la mise à jour des enregistrements AAAA, ce qui donne à l’utilisateur l’impression que son service de niche préféré fonctionne sur d’autres réseaux, mais pas chez le FAI qu’il paie.
    C’est un problème étrange, et je ne sais pas s’il existe une bonne solution en dehors d’espérer qu’IPv4 disparaisse un jour. Happy Eyeballs était censé régler ce problème, mais il apparaît souvent bien au-dessus de la couche applicative ; comme les applications peuvent faire n’importe quoi, il est difficile de le résoudre avec un protocole générique sans abstraction qui fuit. Personnellement, je fais un compromis assez insatisfaisant : j’active IPv6 sur le réseau, mais je désactive le DNS IPv6 dans tous les navigateurs.

• Si vous voulez essayer IPv6 mais que votre FAI ne le propose pas, Hurricane Electric fournit un service de tunnel depuis des années.
  https://tunnelbroker.net
  https://ipv6.he.net
  Il existe aussi des scripts pour créer une interface tun sur le système ou le routeur et router le trafic : https://fedoraproject.org/wiki/IPv6_tunnel_via_Hurricane_Ele..., https://brandonrozek.com/blog/obtaining-ipv6-address-hurrica..., https://wiki.dd-wrt.com/wiki/index.php/IPv6_setup_Hurricane_..., https://forum.mikrotik.com/t/auto-update-script-for-hurrican..., https://docs.rockylinux.org/guides/network/hurricane_electri...

  • Le point agaçant avec ce type de tunnel, c’est que les services de streaming les bloquent comme des VPN utilisés pour contourner les restrictions géographiques ; il faut donc savoir comment désactiver le tunnel si nécessaire.
    Cela dit, ça fonctionne bien. Même si le routeur ne prend pas en charge les tunnels HE, la puissance de RA permet d’attribuer une adresse IPv6 à tous les appareils du réseau. N’importe quel appareil qui annonce un /64 devient un routeur IPv6. Bien sûr, cela suppose que le routeur ne filtre pas RA pour des raisons de sécurité. C’est très utile pour héberger des services sur son réseau domestique sans toucher aux règles de redirection de ports.
  • Hurricane Electric est excellent, mais à mesure que de plus en plus de gens utilisent l’IPv6 fourni par leur FAI, les utilisateurs « ordinaires » quittent les tunnels, et les services réseau ont commencé à signaler les tunnels he.net comme abusifs.
    Trop de sites mettent des barrières ou refusent carrément de fonctionner, si bien que j’ai dû arrêter d’utiliser IPv6 sur la majeure partie de mon réseau.
  • À savoir : pour autant que je sache, les tunnels HE ne fonctionnent que lorsque le FAI vous attribue une IPv4 publique. Si vous êtes derrière un NAT de niveau opérateur, il vous faudra malheureusement une autre solution pour amener IPv6 chez vous.
  • « Client » satisfait ici. J’utilise depuis environ cinq ans un tunnel 6in4 gratuit avec OpenBSD, sans problème notable.
    La configuration se fait uniquement avec des fichiers d’interface réseau OpenBSD comme /etc/hostname.gif0 : tunnel, inet6 128 alias, !route -n add -inet6 default. J’utilise cette connexion pour accéder à un cluster de VPS AWS configuré volontairement sans adresse IPv4 publique. Sinon, à cause de gens comme Jeff Bezos qui monétisent activement l’espace d’adressage IPv4, cela représenterait une part importante du coût mensuel.

• Si, dans un véritable environnement exclusivement IPv6, vous avez rapidement besoin d’une connectivité IPv4, vous pouvez utiliser une passerelle publique DNS64+NAT64. La liste se trouve sur https://nat64.net/public-providers
  Pour un usage courant, il suffit de changer de serveur DNS. DNS64 synthétise des enregistrements DNS AAAA pointant vers une box NAT64 pour les cibles qui n’ont pas d’enregistrement AAAA : $ dig +short @2a00:1098:2c::1 AAAA github.com → 2a01:4f8:c2c:123f:64:5:141a:9cd7. NAT64 effectue ensuite la conversion de protocole et le NAT pour le trafic qui lui arrive à cause de DNS64 : $ curl --resolve github.com:443:[2a01:4f8:c2c:123f:64:5:141a:9cd7] [https://github.com/](<https://github.com/>;)

  • Je venais dire ça. En Europe, au moins https://nat64.net/ lui-même est plutôt bon. Je n’ai eu que de bonnes expériences
  • Avec Cloudflare WARP, ce sera beaucoup plus rapide. Via WARP, on peut aussi se connecter directement à des adresses IPv4

• Donc cet utilisateur d’Internet exclusivement IPv6 qu’on croyait mythique existe vraiment :) C’est du très bon ingénierie réseau
  J’avais eu besoin de quelque chose de similaire autrefois, pour l’objectif inverse, plus courant : faire des choses liées à IPv6 depuis une connexion uniquement IPv4. Si l’on contrôle entièrement un serveur, une solution plus limitée mais rapide consiste à créer un proxy SOCKS5 avec ssh -D 1080 -N myserver, puis à le configurer dans le navigateur. On pourrait sans doute aussi le configurer à l’échelle du système, mais je me demande si cela ne casserait pas la connexion ssh d’origine et ne ferait pas tout s’écrouler

• Je suis dans la même situation. Cela fait deux semaines qu’on me dit seulement que « le ticket est ouvert et qu’un technicien va bientôt regarder », et c’est assez frustrant
  Je ne sais pas si la priorité est basse parce que l’IPv6 fonctionne, donc ils ne considèrent pas ça comme une panne complète. En Allemagne, il existe une loi garantissant une indemnisation des consommateurs dans ce genre de cas, et je vais bientôt vérifier si cela s’applique aussi ici. La solution de ce billet de blog a le problème que plusieurs endpoints bloquent entièrement des plages d’IP de datacenters ou exigent plusieurs CAPTCHA, et c’est pareil avec les fournisseurs de VPN classiques. Je voulais réparer tout le réseau domestique, donc il fallait le faire au niveau du routeur, et le fait d’avoir un appareil non standard comme un Ubiquiti EdgeRouter a aidé pour configurer le routage Wireguard et les règles NAT. Je ne sais pas comment j’aurais fait avec un équipement comme une FritzBox. L’inconvénient est que les performances du routeur ne suffisent pas pour gérer beaucoup de connexions, donc il faudrait passer à IPsec, qui prend en charge l’offloading matériel

  • En fait, les FritzBox disposent aussi d’une interface graphique pour configurer les connexions VPN plutôt correcte. La fonction vise les connexions entre FritzBox, mais n’importe quel VPN compatible peut convenir. On peut aussi configurer des routes IPv4/IPv6 statiques
    Le plus gros problème sera probablement de déterminer quelle configuration de chiffrement IPsec est attendue de l’autre côté. Wireguard peut être beaucoup plus simple, mais on peut alors se heurter au problème de l’accélération matérielle. Si nécessaire, on peut aussi sauvegarder le fichier de configuration de la FritzBox, modifier le dump pour configurer manuellement l’endpoint VPN, puis recalculer la somme de contrôle avant de le réimporter. AVM a beaucoup de paramètres auxquels l’utilisateur n’a pas accès et qu’on peut ajuster ainsi, mais ils ont rendu l’accès un peu difficile pour éviter de briquer le routeur par erreur
  • Je ne connais pas la situation en Allemagne, mais aux Pays-Bas, si l’on utilise le fixe et le mobile chez le même FAI et que la connexion fixe tombe en panne, on peut demander des données mobiles gratuites jusqu’à ce que la panne soit corrigée
    C’est peut-être une option à demander à votre FAI

• L’un des points que j’apprécie dans les règles de l’App Store d’Apple, c’est l’exigence que toutes les apps fonctionnent sur un réseau exclusivement IPv6. Cette règle existe depuis des années
  En tant que développeur, c’est un peu surprenant la première fois qu’on y est confronté, mais en tant qu’utilisateur, je suis content qu’elle existe

  • Si on utilise une app, Github est-il aussi accessible en IPv6 ?
  • Mais cela ne veut pas dire que le serveur doit avoir une adresse IPv6

• Si je vivais la même chose, je pourrais très facilement créer un proxy ssh avec ssh -D 8080 user@hostname
  Une fois la connexion établie, il suffit de configurer le navigateur pour utiliser localhost:8080 comme proxy SOCKS

  • J’allais donner le même conseil. Pour un problème temporaire, c’est une solution beaucoup plus simple, et cela peut aussi servir d’outil permanent quand on a besoin d’un proxy
    Pour utiliser cette fonction, AllowTcpForwarding doit être activé dans sshd_config
  • Je fais toujours ça quand j’utilise un Wi-Fi public. Sans payer pour un VPN ni avoir à faire confiance à un VPN, je fais tout passer en forwarding SOCKS vers mon serveur infomaniak

• Il y a des points de blocage quand on coupe IPv4 : la plupart des moteurs de recherche alternatifs ne semblent pas proposer de connectivité IPv6, et GitHub, lors de la dernière vérification, n’avait pas du tout d’IPv6
  Comme c’est Microsoft, il ne faut pas s’attendre à du bon, mais plutôt au pire. Récemment, ils ont même cassé le noscript/basic (x)html dans les issues. Je ne sais même pas s’il est encore possible de créer un compte avec un navigateur noscript/basic (x)html, un e-mail auto-hébergé et un littéral IP(v6) du type mailbox@[ipv6:...]. Steam ou les jeux, je n’ai pas vérifié récemment non plus, mais j’imagine que beaucoup de CDN/serveurs de jeux, ou une part importante d’entre eux, restent encore uniquement en IPv4. Pour les serveurs e-mail aussi, beaucoup bloquent les serveurs mail auto-hébergés et utilisent souvent des listes de blocage maladroites et inadaptées, produites par des sociétés douteuses de Suisse ou d’Andorre comme Spamhaus. Par ailleurs, beaucoup d’applications réseau n’exploitent pas les avantages d’IPv6. Par exemple, les applications client-serveur comme le Web devraient utiliser, pour chaque session, une adresse IPv6 générée aléatoirement, tant que le FAI ne fournit pas un préfixe trop petit. Les FAI IPv6 mobiles semblent attribuer des adresses IPv6/128 arbitraires dans le préfixe, mais ils devraient fournir un préfixe stable, probablement d’environ 96 bits, afin que les applications des terminaux puissent choisir une adresse IPv6 « fixe » pour les appels vocaux/vidéo directs sans résolution de noms centrale en ligne. Il faudrait aussi un nouveau service au niveau utilisateur dans l’OS pour coordonner les adresses IPv6 entre applications utilisateur. Cela dit, il faut se méfier de la complexité stupide que certains fournisseurs et développeurs imposeront pour enfermer les utilisateurs et les développeurs d’apps

  • Dans mon mini homelab, le tout IPv6 fonctionnait bien, jusqu’à ce que quelque chose nécessite GitHub et casse l’ensemble. J’ai donc mis en place NAT64+NAT64
    C’est vraiment regrettable d’avoir dû faire ça juste à cause de GitHub. J’en aurais sans doute eu besoin un jour à cause d’un serveur mail, mais comme raison d’avoir besoin de NAT64 aussi tôt, c’était vraiment nul. J’y vois l’un des nombreux inconvénients du fait que les gens utilisent GitHub comme moyen de distribution de logiciels
  • Il y a quelques mois, j’ai dû me battre avec Spamhaus. Pour une raison quelconque, l’adresse IPv6 de mon VPS s’est retrouvée sur la liste de blocage de Spamhaus
    Je n’ai absolument aucune idée du pourquoi. Cette machine ne faisait tourner rien qui puisse envoyer des e-mails et, à ma connaissance, DigitalOcean bloque aussi SMTP, donc il était littéralement impossible pour cette machine d’envoyer des e-mails. Spamhaus n’a été d’aucune aide pour résoudre le problème, et DO non plus
  • À cause du fait que beaucoup de CDN/serveurs de jeux restent uniquement en IPv4, j’ai créé un proxy DNS. Il ajoute les bons enregistrements AAAA à ces domaines
    https://gitlab.com/miyurusankalpa/IPv6-dns-server
  • Je peux confirmer que Steam a besoin d’IPv4. C’est aussi le cas de certains jeux qui nécessitent une authentification pour jouer
  • Sauf dans les cas où il y a une remise à fonctionner en IPv6 uniquement, comme avec certains services VPS, il semble que personne n’envisage encore sérieusement d’abandonner IPv4
    En réalité, on continuera très probablement à avoir une connectivité IPv4 sous une forme ou une autre, mais il est de plus en plus probable qu’elle passe par du CGNAT. GitHub m’énerve tout particulièrement. Ils ont testé pendant quelques semaines et tout semblait bien fonctionner, puis ils sont revenus à de l’IPv4 uniquement. Les serveurs e-mail, de toute façon, vivent dans le monde d’il y a 10 à 20 ans. Même désactiver la prise en charge de SSL 3.0 ou TLS 1.0 sur un serveur e-mail est difficile sans risquer des problèmes de délivrabilité. Le support et les filtres antispam de Microsoft Outlook semblent même ne pas reconnaître les serveurs mail capables d’IPv6. Et ce, alors qu’en regardant les en-têtes, on dirait qu’ils utilisent IPv6 en interne depuis longtemps. J’aimerais qu’IPv6 soit davantage exploité, mais la crainte que cela puisse fonctionner un peu moins bien pour une minorité de clients semble geler toute tentative d’utiliser réellement la technologie. Si l’on observe des comportements IP étranges chez les opérateurs mobiles, c’est très probablement à cause de la façon dont IP fonctionne dans les réseaux mobiles. Quand on passe un appel en roulant sur l’autoroute ou assis dans un train à grande vitesse, le téléphone effectue sans cesse des handovers, et l’adresse IP a besoin d’un certain niveau de stabilité. Même lorsqu’on traverse une frontière et que l’on bascule sur un réseau étranger, toute la pile doit maintenir une connexion sans coupure. À l’intérieur des réseaux cellulaires, il existe des systèmes de routage spécifiques, dont certains tirent très bien parti des fonctionnalités d’IPv6, mais qui rendent difficile la fourniture au téléphone d’une adresse unicast globale statique « normale ». On essaie de donner l’apparence la plus standard possible, mais atteindre ce niveau de stabilité n’est pas aussi simple que sur une connexion Internet fixe à domicile

• Au travail, nous exploitons plusieurs VPN uniquement IPv6 pour accéder à l’infrastructure interne
  Jusqu’ici, le plus gros problème est que les clients Windows et macOS ont besoin d’un serveur DNS IPv6. Sinon, ils n’essaient même pas de résoudre v6onlyhost.vpn.example.com. Comme les clients peuvent se trouver ou non sur un réseau compatible IPv6, il faut faire tourner un serveur DNS dans le VPN et le pousser aux clients ; mais si, après la déconnexion du VPN, l’application WireGuard ne remet pas le DNS d’origine pour une raison quelconque, toutes sortes de problèmes peuvent apparaître

  • Même en utilisant le réseau uniquement IPv4 de mon FAI, macOS pouvait établir une connexion uniquement IPv6 sans ce type de serveur DNS
    Je ne me souviens plus des détails, mais en creusant il y a quelques années, macOS fonctionnait bien de cette manière dès lors qu’il disposait d’une adresse IPv6. Il suffit d’ajouter une adresse ULA à l’hôte. Bien sûr, cela suppose que l’utilisateur sache comment faire. Selon l’application VPN, on peut aussi ajouter un script qui ajoute une ULA lorsqu’on entre dans un réseau uniquement IPv6. En revanche, si une fausse ULA reste en place, cela peut poser problème lorsque l’utilisateur passe sur un réseau compatible IPv6
  • Ce n’est pas un problème Windows. J’ai eu des problèmes similaires sur certains hotspots aléatoires, mais pas tous. À mon avis, cela vient de hotspots idiots qui ne renvoient pas les enregistrements AAAA quand IPv6 est désactivé

• Même après tout ce temps, je ne vois toujours pas de raison suffisamment convaincante pour passer plusieurs jours à m’arracher les cheveux afin de migrer toutes mes machines et mon homelab vers IPv6
  Les redirections de ports et les règles de pare-feu me semblent plus intuitives que de passer des semaines à dépanner tout ça, à reconfigurer le pare-feu et à réadresser le réseau. Qu’est-ce que je rate ?

  • Ce que tu rates, c’est que ce n’est pas aussi difficile qu’on l’imagine. Sauf réseau domestique très complexe, configurer IPv6 prend au plus une soirée
    Dans le cas de mon réseau et de mon FAI, Comcast, il suffit d’activer IPv6 sur le routeur : il récupère un préfixe auprès du FAI, l’annonce en local, puis on ajoute une règle de pare-feu pour ce qu’on veut rendre accessible depuis l’extérieur, et c’est tout
  • Tu ne rates rien. En environnement d’entreprise, les avantages de l’adoption d’IPv6 ne l’emportent pas sur les inconvénients
    Je gère environ 3 500 appareils, 7 bâtiments, deux WAN à 10 Gbit/s et un WAN à 4 Gbit/s, avec environ 26 adresses IPv4 publiques et du NAT. Aujourd’hui encore, il n’y a pas de raison forte de déployer IPv6. Une configuration dual-stack n’ajoute que du trafic et de la complexité inutiles, sans bénéfice notable. Il reste difficile d’obtenir un bloc d’adresses IPv6 statiques ; j’en ai fait la demande deux fois et elle a été refusée. Non seulement le potentiel de gain est faible, mais obtenir un bloc reste encore compliqué. Les critères d’éligibilité de https://www.arin.net/resources/guide/ipv6/first_request/ sont par exemple : détenir une allocation IPv4, prévoir immédiatement du multihoming IPv6, avoir 13 sites finaux dans l’année, utiliser 2 000 adresses IPv6 dans l’année, ou utiliser 200 sous-réseaux /64 dans l’année
  • Pour l’instant, tu ne rates pas grand-chose. Un jour, de grandes entreprises comme Google ou Cloudflare pourraient se lasser du coût des adresses IPv4, qui ne cesse d’augmenter, et inciter à passer à IPv6. Par exemple, elles pourraient commencer à limiter IPv4
    On voit déjà les premiers signes. Avant, AWS ne facturait que les adresses IPv4 Elastic IP non utilisées, mais désormais il les facture qu’elles soient utilisées ou non. Honnêtement, il suffit probablement d’être prêt lors de la prochaine mise à niveau de ta passerelle ou de ton routeur ; tu ne rates rien d’urgent aujourd’hui. On peut aussi utiliser IPv4 et IPv6 en même temps. Même si tu l’actives sur le routeur, les appareils uniquement IPv4 continueront à fonctionner normalement. Un point d’attention : la découverte automatique en IPv6 a été assez chaotique pendant un temps. Il y avait SLAAC, l’auto-configuration d’adresses IPv6 et DHCPv6, et à l’origine l’auto-configuration ne permettait même pas de récupérer les serveurs DNS. Aujourd’hui, les choses se stabilisent plutôt autour de SLAAC, mais les FAI continueront à utiliser DHCPv6 pendant très longtemps