Opprinnelig var bloggoppsettet mitt planlagt som et rent IPv6-prosjekt via WireGuard, ettersom det hele kjøres på en hjemmeserver (gratis IPv6-adresser kan man forresten få hos route64.org). For å øke tilgjengeligheten har jeg nå lagt til en ekstern IPv4-proxy (takk til @Larvitz).

I den forbindelse oppstod det umiddelbart SSL-problemer: Siden både A- og AAAA-oppføringene opprinnelig gikk via proxyen, feilet Let's Encrypt-valideringen på serveren min.

Løsningen: «IPv6-hacket»

Løsningen var å peke AAAA-oppføringen eksplisitt direkte til serverens WireGuard-IP, i stedet for å rute den via proxyen også.

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

Gjennom denne direkte AAAA-oppføringen til min WireGuard-IP, når Let’s Encrypt fortsatt serveren min direkte via IPv6 (siden AAAA-oppføringer prioriteres som standard) og utsteder SSL-sertifikatet. IPv4-trafikken blir videresendt kryptert fra proxyen til meg.

Den endelige konfigurasjonen

For at kommunikasjonen skal fungere knirkefritt, måtte vi tilpasse Caddy-serverne:

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

For at de ekte besøks-IP-ene skal ankomme korrekt og ikke bli overskrevet av proxyens IP, må denne markeres som tiltrodd:

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

2. På den eksterne proxyen (Caddy)

For at proxyen skal kontakte serveren min korrekt via HTTPS, må den sende med vertsnavnet (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
    }
}

Bloggen er nå tilgjengelig via både IPv4 og IPv6, er sikkert kryptert, og hjemme-IP-en min forblir fortsatt privat! 🚀

MD-Blog