Ursprünglich war mein Blog-Setup als reines IPv6-Projekt über WireGuard geplant, da das Ganze auf einem Homeserver betrieben wird (kostenlose IPv6-Adressen bekommt man übrigens bei route64.org). Um die Erreichbarkeit zu erhöhen, habe ich nun einen externen IPv4-Proxy dazugeholt (Danke @Larvitz).

Dabei gab es jedoch sofort SSL-Probleme: Da ursprünglich sowohl der A wie auch der AAAA Record über den Proxy liefen, schlug die Let's Encrypt-Validierung auf meinem Server fehl.

Die Lösung: Der „IPv6-Hack“

Die Lösung war, den AAAA-Eintrag explizit direkt auf die WireGuard-IP meines Servers zu richten, anstatt ihn ebenfalls über den Proxy zu leiten.

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

Durch diesen direkten AAAA-Eintrag auf meine WireGuard-IP erreicht Let’s Encrypt meinen Server weiterhin direkt via IPv6 (da der AAAA-Record standardmäßig priorisiert wird) und stellt das SSL-Zertifikat aus. Der IPv4-Traffic wird vom Proxy verschlüsselt an mich weitergereicht.

Die finale Konfiguration

Damit die Kommunikation reibungslos klappt, mussten wir die Caddy-Server anpassen:

1. Auf meinem Server (NixOS, blog.nix)

Damit die echten Besucher-IPs korrekt ankommen und nicht durch die IP des Proxys überschrieben werden, muss dieser als vertrauenswürdig markiert werden:

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

2. Auf dem externen Proxy (Caddy)

Damit der Proxy meinen Server korrekt per HTTPS anspricht, muss er den Hostnamen (SNI) mitschicken:

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

Der Blog ist jetzt über IPv4 und IPv6 erreichbar, sicher verschlüsselt und meine Heim-IP bleibt trotzdem privat! 🚀