Tester son IPv6
Une IPv6 « incluse » ne signifie pas qu'un service répond en IPv6. Il faut une adresse sur le serveur, un service à l'écoute sur cette pile, un pare-feu qui laisse passer le port et un enregistrement AAAA qui pointe vers elle. Testez chaque maillon plutôt que de conclure au hasard.
Tester depuis le client
Ouvrez la page test IPv6 depuis un réseau qui annonce IPv6 : elle indique l'adresse vue par le site. Si vous voyez une adresse IPv4, votre accès n'utilise pas IPv6, et le test du serveur sera faussé.
En ligne de commande, forcez la famille d'adresses :
curl -6 -sS -o /dev/null -w "%{http_code} %{remote_ip}\n" https://votre-domaine.fr/
curl -4 -sS -o /dev/null -w "%{http_code} %{remote_ip}\n" https://votre-domaine.fr/La première commande doit renvoyer 200 et une adresse contenant :. La seconde sert de comparaison. Poursuivez avec le nom :
dig AAAA votre-domaine.fr +short
ping -6 -c 3 VOTRE_IPV6ping6 existe encore comme lien symbolique sur Debian, mais ping -6 est la forme portable. Un échec de ping n'est pas concluant à lui seul : beaucoup de serveurs filtrent ICMPv6.
Tester sur le serveur
Vérifiez d'abord que l'adresse est configurée et que la route par défaut existe :
ip -6 addr show
ip -6 route show defaultSur un conteneur système, l'adresse est fournie par la plateforme : ne l'ajoutez pas à la main. Puis regardez ce qui écoute réellement :
ss -6 -lntpUne ligne [::]:80 indique une écoute sur les deux piles. Si ss -lntp n'affiche que 0.0.0.0:80, l'écoute est IPv4 seule : Nginx doit alors avoir une directive listen [::]:80; dans le même bloc server. Vérifiez la configuration avant de recharger :
sudo nginx -t && sudo systemctl reload nginxCôté pare-feu, UFW gère IPv6 lorsque IPV6=yes est présent dans /etc/default/ufw, ce qui est le cas par défaut sur Debian. sudo ufw allow 80,443/tcp ouvre les deux familles. Vérifiez avec sudo ufw status verbose, ou sudo nft list ruleset si vous utilisez nftables directement.
Vérifier le DNS et le navigateur
Le nom doit avoir un AAAA vers l'adresse du service. Un A seul ne suffit pas. Si les deux existent, le navigateur privilégie souvent IPv6 : un AAAA créé alors que le port est fermé provoque des timeouts chez certains visiteurs.
Après un changement, attendez l'expiration du TTL, puis contrôlez avec un résolveur public :
dig @1.1.1.1 AAAA votre-domaine.fr +shortDans le navigateur, la barre d'adresse n'affiche pas la famille utilisée. Les outils de développement, onglet Réseau, montrent l'adresse distante de la requête.
Diagnostiquer
| Symptôme | Cause probable | Contrôle |
|---|---|---|
| Timeout en IPv6 seulement | pare-feu ou service lié à IPv4 | ss -6 -lntp, ufw status |
curl -6 fonctionne, navigateur non |
IPv6 locale cassée ou cache AAAA | test IPv6, cache local |
Aucune réponse AAAA |
enregistrement absent ou mauvaise zone | dig AAAA, dig NS |
| Connexion refusée | service pas à l'écoute sur :: |
configuration du serveur web |
| Fonctionne depuis un réseau, pas un autre | routage du réseau client | test depuis un autre accès |
Terminez par un test fonctionnel : page complète, formulaire, téléchargement. Une connexion TCP qui aboutit ne garantit pas que l'application répond correctement sur les deux piles.
Publicité
Cet article vous a-t-il aidé ?
À lire aussi
- Configurer le reverse DNSPTR, FCrDNS et délivrabilité e-mail : ce que vous pouvez régler, et ce qui dépend du fournisseur.
- Diagnostiquer un problème DNSLire les codes de dig, distinguer NXDOMAIN de SERVFAIL et séparer panne locale et erreur de zone.
- Comprendre la propagation DNSDes caches qui expirent, pas une diffusion mondiale : délais réels, vérification et purge locale.