Oorspronkelijk was mijn blog-setup gepland als een puur IPv6-project via WireGuard, omdat het geheel op een homeserver draait (gratis IPv6-adressen kun je overigens krijgen bij route64.org). Om de bereikbaarheid te vergroten, heb ik nu een externe IPv4-proxy toegevoegd (met dank aan @Larvitz).

Daarbij ontstonden echter direct SSL-problemen: Omdat oorspronkelijk zowel het A- als het AAAA-record via de proxy liepen, mislukte de Let's Encrypt-validatie op mijn server.

De oplossing: De „IPv6-hack“

De oplossing was om het AAAA-record expliciet rechtstreeks naar het WireGuard-IP van mijn server te laten verwijzen, in plaats van dit ook via de proxy te leiden.

• Domein: blog.burningboard.org
• A-record (Proxy): 194.28.98.217
• AAAA-record (Server): 2a11:6c7:f05:a8::2 (WireGuard)

Door dit directe AAAA-record naar mijn WireGuard-IP bereikt Let’s Encrypt mijn server nog steeds rechtstreeks via IPv6 (omdat het AAAA-record standaard prioriteit krijgt) en wordt het SSL-certificaat uitgegeven. Het IPv4-verkeer wordt door de proxy versleuteld naar mij doorgegeven.

De uiteindelijke configuratie

Om de communicatie soepel te laten verlopen, moesten we de Caddy-servers aanpassen:

1. Op mijn server (NixOS, blog.nix)

Om ervoor te zorgen dat de echte IP-adressen van bezoekers correct aankomen en niet worden overschreven door het IP van de proxy, moet deze als vertrouwd worden gemarkeerd:

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

2. Op de externe proxy (Caddy)

Om ervoor te zorgen dat de proxy mijn server correct via HTTPS benadert, moet deze de hostnaam (SNI) meesturen:

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
    }
}

De blog is nu bereikbaar via IPv4 en IPv6, veilig versleuteld en mijn thuis-IP blijft toch privé! 🚀