Eredetileg a blog-beállításomat egy tiszta IPv6-projektnek terveztem WireGuardon keresztül, mivel az egész egy otthoni szerveren fut (ingyenes IPv6-címeket egyébként a route64.org oldalon lehet kapni). Az elérhetőség növelése érdekében most beiktattam egy külső IPv4-proxyt (köszönet @Larvitz-nak).

Ezzel azonban azonnal SSL-problémák adódtak: mivel eredetileg mind az A, mind az AAAA rekord a proxyn keresztül futott, a Let's Encrypt hitelesítés meghiúsult a szerveremen.

A megoldás: Az „IPv6-hack”

A megoldás az volt, hogy az AAAA-bejegyzést kifejezetten a szerverem WireGuard IP-címére irányítottam, ahelyett, hogy azt is a proxyn keresztül vezettem volna.

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

Ezzel a közvetlen, a WireGuard IP-mre mutató AAAA-bejegyzéssel a Let’s Encrypt továbbra is közvetlenül eléri a szerveremet IPv6-on keresztül (mivel az AAAA-rekord alapértelmezés szerint prioritást élvez), és kiállítja az SSL-tanúsítványt. Az IPv4-forgalmat a proxy titkosítva továbbítja felém.

A végleges konfiguráció

Annak érdekében, hogy a kommunikáció zökkenőmentesen működjön, módosítanunk kellett a Caddy szervereket:

1. A szerveremen (NixOS, blog.nix)

Annak érdekében, hogy a látogatók valódi IP-címei helyesen érkezzenek meg, és ne a proxy IP-címe írja felül őket, a proxyt megbízhatóként kell megjelölni:

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

2. A külső proxyn (Caddy)

Ahhoz, hogy a proxy megfelelően, HTTPS-en keresztül szólítsa meg a szerveremet, el kell küldenie a gépnevet (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
    }
}

A blog mostantól IPv4-en és IPv6-on is elérhető, biztonságosan titkosított, és az otthoni IP-címem továbbra is privát marad! 🚀