Oprindeligt var mit blog-setup planlagt som et rent IPv6-projekt via WireGuard, da det hele kører på en homeserver (man kan i øvrigt få gratis IPv6-adresser hos route64.org). For at øge tilgængeligheden har jeg nu tilføjet en ekstern IPv4-proxy (tak til @Larvitz).

I den forbindelse opstod der dog straks SSL-problemer: Da både A- og AAAA-recorden oprindeligt kørte via proxyen, fejlede Let's Encrypt-valideringen på min server.

Løsningen: „IPv6-hacket“

Løsningen var eksplicit at pege AAAA-posten direkte mod min servers WireGuard-IP i stedet for også at lede den gennem proxyen.

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

Gennem denne direkte AAAA-post til min WireGuard-IP kan Let’s Encrypt fortsat nå min server direkte via IPv6 (da AAAA-recorden som standard prioriteres) og udstede SSL-certifikatet. IPv4-trafikken videresendes krypteret fra proxyen til mig.

Den endelige konfiguration

For at kommunikationen skal fungere problemfrit, var vi nødt til at tilpasse Caddy-serverne:

1. På min server (NixOS, blog.nix)

For at de rigtige besøgs-IP'er ankommer korrekt og ikke bliver overskrevet af proxyens IP, skal denne markeres som betroet:

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

2. På den eksterne proxy (Caddy)

For at proxyen kan kontakte min server korrekt via HTTPS, skal den sende værtsnavnet (SNI) med:

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

Bloggen er nu tilgængelig via både IPv4 og IPv6, sikkert krypteret, og min hjemme-IP forbliver stadig privat! 🚀

MD-Blog