Un hébergeur cloud a annoncé que ses nouvelles offres de VPS ne fourniraient plus systématiquement une adresse IPv4 dédiée, poussant vers une double pile IPv4/IPv6 par défaut, l’IPv4 seul restant disponible en option payante. Pour un client dont le contrat arrivait à échéance de renouvellement, la migration vers la double pile devenait la voie la plus économique, à condition de la mener sans casser l’accessibilité du site pour la part de visiteurs encore uniquement en IPv4.
Passer d’IPv4 seul à une double pile ne consiste pas à activer une simple case dans un panneau d’administration : le DNS, le serveur web et le pare-feu doivent chacun être mis à jour pour reconnaître et traiter correctement les deux familles d’adresses, en parallèle, sans jamais en négliger une au profit de l’autre.
Étape 1 : ajouter l’enregistrement AAAA, sans toucher au A
Le DNS distingue deux types d’enregistrements pour les adresses : le A pour IPv4, le AAAA pour IPv6. Passer en double pile consiste à ajouter un AAAA en plus du A existant, jamais à le remplacer — un visiteur dont le réseau ne supporte que l’IPv4 continuera d’utiliser le A, tandis qu’un réseau compatible IPv6 privilégiera automatiquement le AAAA si les deux sont présents.
exemple.fr. 3600 IN A 198.51.100.42
exemple.fr. 3600 IN AAAA 2001:db8:85a3::8a2e:370:7334
Étape 2 : configurer le serveur web pour écouter les deux familles
nginx doit explicitement écouter sur l’adresse IPv6, en plus de l’IPv4 : sans cette déclaration, une requête arrivant en IPv6 échoue purement et simplement, même si l’enregistrement AAAA est correctement déclaré côté DNS.
server {
listen 80;
listen [::]:80;
listen 443 ssl;
listen [::]:443 ssl;
server_name exemple.fr;
...
}
L’oubli le plus fréquent à cette étape concerne le certificat TLS : un certificat Let’s Encrypt délivré uniquement pour le nom de domaine reste valable pour les deux familles d’adresses (le certificat couvre un nom, pas une IP), donc aucune action supplémentaire n’est requise côté Certbot pour cette partie précise.
Étape 3 : vérifier le pare-feu, souvent oublié pour IPv6
Un piège classique de cette bascule : un pare-feu configuré historiquement avec iptables ne filtre que le trafic IPv4. Sans règles équivalentes pour IPv6 via ip6tables (ou une configuration nftables couvrant nativement les deux familles), le serveur se retrouve exposé sur IPv6 sans aucune des protections appliquées côté IPv4 — un oubli qui annule tout le travail de durcissement fait par ailleurs.
ip6tables -A INPUT -p tcp --dport 22 -s 2001:db8:1::/48 -j ACCEPT
ip6tables -A INPUT -p tcp --dport 22 -j DROP
ip6tables -A INPUT -p tcp --dport 443 -j ACCEPT
ip6tables -A INPUT -p tcp --dport 80 -j ACCEPT
Étape 4 : tester réellement l’accessibilité en IPv6
Un test depuis un poste ou un réseau ne disposant que d’IPv4 ne révèle jamais un problème de configuration IPv6 : il faut un test explicite, soit depuis un réseau IPv6 natif, soit via un service en ligne dédié qui simule une requête IPv6 pure.
curl -6 -v https://exemple.fr
ping6 exemple.fr
Étape 5 : surveiller les journaux applicatifs pour les faux positifs de sécurité
Certains plugins de sécurité WordPress, notamment ceux qui limitent les tentatives de connexion par adresse IP, reposent parfois sur des hypothèses écrites pour IPv4 uniquement (par exemple des masques de sous-réseau /24 mal adaptés au format IPv6). Un audit rapide de la configuration de ce type de plugin après bascule évite des blocages erronés de visiteurs légitimes arrivant en IPv6.
- Vérifier qu’aucun plugin de restriction d’accès ne bloque silencieusement le format IPv6
- Contrôler les journaux nginx pour confirmer la présence de requêtes en IPv6 après la bascule
- Conserver l’IPv4 actif en parallèle : la double pile n’a de sens que tant qu’IPv4 reste majoritaire côté visiteurs
La double pile ne remplace rien, elle ajoute une voie d’accès supplémentaire ; toute la vigilance doit porter sur le fait qu’aucune couche du serveur — DNS, web, pare-feu — n’oublie l’une des deux voies.
En résumé
Basculer en double pile IPv4/IPv6 demande de traiter chaque couche de l’infrastructure séparément — DNS, serveur web, pare-feu — sans supposer qu’une seule modification suffit à couvrir l’ensemble. Bien menée, la bascule reste invisible pour les visiteurs, ce qui constitue précisément le signe qu’elle a été correctement exécutée.
