À l'origine, la configuration de mon blog était prévue comme un projet exclusivement IPv6 via WireGuard, car le tout est hébergé sur un serveur domestique (on peut d'ailleurs obtenir des adresses IPv6 gratuites sur route64.org). Pour améliorer l'accessibilité, j'ai maintenant ajouté un proxy IPv4 externe (merci à @Larvitz).

Cependant, des problèmes SSL sont immédiatement apparus : comme les enregistrements A et AAAA passaient initialement tous deux par le proxy, la validation Let's Encrypt a échoué sur mon serveur.

La solution : le « hack IPv6 »

La solution a consisté à pointer explicitement l'enregistrement AAAA directement vers l'IP WireGuard de mon serveur, au lieu de le faire passer également par le proxy.

• Domaine : blog.burningboard.org
• Enregistrement A (Proxy) : 194.28.98.217
• Enregistrement AAAA (Serveur) : 2a11:6c7:f05:a8::2 (WireGuard)

Grâce à cet enregistrement AAAA direct vers mon IP WireGuard, Let's Encrypt continue d'atteindre mon serveur directement via IPv6 (car l'enregistrement AAAA est prioritaire par défaut) et délivre le certificat SSL. Le trafic IPv4 est transmis de manière chiffrée par le proxy jusqu'à moi.

La configuration finale

Pour que la communication fonctionne sans accroc, nous avons dû adapter les serveurs Caddy :

1. Sur mon serveur (NixOS, blog.nix)

Pour que les adresses IP réelles des visiteurs arrivent correctement et ne soient pas écrasées par l'IP du proxy, celui-ci doit être marqué comme fiable :

services.caddy.globalConfig = ''
  servers {
      trusted_proxies static 2a06:9801:1c:1000::10
  }
'';

2. Sur le proxy externe (Caddy)

Pour que le proxy communique correctement avec mon serveur via HTTPS, il doit envoyer le nom d'hôte (SNI) :

reverse_proxy [https://[2a11:6c7:f05:a8::2]:443](https://[2a11:6c7:f05:a8::2]:443) {
    header_up Host {host}
    transport http {
        tls_server_name blog.burningboard.org
    }
}

Le blog est désormais accessible via IPv4 et IPv6, chiffré de manière sécurisée, et mon IP domestique reste tout de même privée ! 🚀