# Basculer un site WordPress d’IPv4 seul à la double pile IPv4 et IPv6

> Un hébergeur impose désormais l'IPv6 sur ses nouvelles offres. Détail complet de la bascule vers la double pile, DNS et configuration du serveur web compris.

- Auteur : Clément Hadrot
- Publié le : 2023-05-24
- Mis à jour le : 2023-05-24
- Catégorie : Hébergement & serveurs
- URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/bascule-ipv4-ipv6-double-pile-wordpress/

## L’essentiel

- Un enregistrement AAAA s'ajoute au A existant, sans le remplacer
- nginx doit écouter explicitement les deux familles d'adresses
- Le pare-feu doit filtrer IPv6 avec la même rigueur que IPv4

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.

> L'essentiel à retenir : Un enregistrement AAAA s'ajoute au A existant, sans le remplacer ; nginx doit écouter explicitement les deux familles d'adresses ; Le pare-feu doit filtrer IPv6 avec la même rigueur que IPv4

## É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.