Ursprungligen var min blogguppsättning planerad som ett rent IPv6-projekt via WireGuard, eftersom det hela körs på en hemserver (gratis IPv6-adresser kan man förresten få hos route64.org). För att öka tillgängligheten har jag nu lagt till en extern IPv4-proxy (tack @Larvitz).

I samband med detta uppstod dock omedelbart SSL-problem: Eftersom både A- och AAAA-posterna ursprungligen gick via proxyn, misslyckades Let's Encrypt-valideringen på min server.

Lösningen: ”IPv6-hacket”

Lösningen var att rikta AAAA-posten explicit direkt mot min servers WireGuard-IP, istället för att även leda den via proxyn.

  • Domän: blog.burningboard.org
  • A-post (Proxy): 194.28.98.217
  • AAAA-post (Server): 2a11:6c7:f05:a8::2 (WireGuard)

Genom denna direkta AAAA-post till min WireGuard-IP når Let’s Encrypt fortfarande min server direkt via IPv6 (eftersom AAAA-posten prioriteras som standard) och utfärdar SSL-certifikatet. IPv4-trafiken skickas vidare krypterad från proxyn till mig.

Den slutgiltiga konfigurationen

För att kommunikationen ska fungera smidigt var vi tvungna att anpassa Caddy-servrarna:

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

För att de riktiga besökar-IP-adresserna ska komma fram korrekt och inte skrivas över av proxyns IP, måste denna markeras som betrodd:

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

2. På den externa proxyn (Caddy)

För att proxyn ska anropa min server korrekt via HTTPS måste den skicka med värdnamnet (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 är nu tillgänglig via både IPv4 och IPv6, säkert krypterad, och min hem-IP förblir ändå privat! 🚀

MD-Blog