Pierwotnie mój setup bloga był planowany jako projekt wyłącznie IPv6 przez WireGuard, ponieważ całość działa na serwerze domowym (darmowe adresy IPv6 można nawiasem mówiąc uzyskać na route64.org). Aby zwiększyć dostępność, dodałem teraz zewnętrzny serwer proxy IPv4 (podziękowania dla @Larvitz).

Pojawiły się jednak natychmiastowe problemy z SSL: Ponieważ pierwotnie zarówno rekord A, jak i AAAA przechodziły przez proxy, walidacja Let's Encrypt na moim serwerze kończyła się niepowodzeniem.

Rozwiązanie: „IPv6-Hack”

Rozwiązaniem było jawne skierowanie rekordu AAAA bezpośrednio na adres IP WireGuard mojego serwera, zamiast prowadzenia go również przez proxy.

• Domena: blog.burningboard.org
• Rekord A (Proxy): 194.28.98.217
• Rekord AAAA (Serwer): 2a11:6c7:f05:a8::2 (WireGuard)

Dzięki temu bezpośredniemu wpisowi AAAA na mój adres IP WireGuard, Let’s Encrypt nadal dociera do mojego serwera bezpośrednio przez IPv6 (ponieważ rekord AAAA jest domyślnie priorytetyzowany) i wystawia certyfikat SSL. Ruch IPv4 jest przekazywany do mnie przez proxy w formie zaszyfrowanej.

Finałowa konfiguracja

Aby komunikacja przebiegała bez zakłóceń, musieliśmy dostosować serwery Caddy:

1. Na moim serwerze (NixOS, blog.nix)

Aby prawdziwe adresy IP odwiedzających docierały poprawnie i nie były nadpisywane przez IP serwera proxy, musi on zostać oznaczony jako zaufany:

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

2. Na zewnętrznym serwerze proxy (Caddy)

Aby proxy poprawnie łączyło się z moim serwerem przez HTTPS, musi przesyłać nazwę hosta (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
    }
}

Blog jest teraz dostępny przez IPv4 i IPv6, bezpiecznie zaszyfrowany, a mój domowy adres IP pozostaje prywatny! 🚀