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! 🚀
