Inizialmente, il setup del mio blog era stato pianificato come un progetto puramente IPv6 tramite WireGuard, poiché il tutto gira su un server domestico (a proposito, è possibile ottenere indirizzi IPv6 gratuiti su route64.org). Per migliorare l'accessibilità, ho aggiunto un proxy IPv4 esterno (grazie a @Larvitz).

Tuttavia, sono sorti immediatamente dei problemi con l'SSL: poiché originariamente sia il record A che quello AAAA passavano attraverso il proxy, la validazione di Let's Encrypt sul mio server falliva.

La soluzione: l'"IPv6-Hack"

La soluzione è stata puntare esplicitamente il record AAAA direttamente sull'IP WireGuard del mio server, invece di instradarlo anch'esso attraverso il proxy.

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

Grazie a questo record AAAA diretto verso il mio IP WireGuard, Let’s Encrypt continua a raggiungere il mio server direttamente via IPv6 (dato che il record AAAA ha la priorità per impostazione predefinita) ed emette il certificato SSL. Il traffico IPv4 viene inoltrato dal proxy a me in modo crittografato.

La configurazione finale

Per far sì che la comunicazione funzioni senza intoppi, abbiamo dovuto adattare i server Caddy:

1. Sul mio server (NixOS, blog.nix)

Affinché i veri IP dei visitatori arrivino correttamente e non vengano sovrascritti dall'IP del proxy, quest'ultimo deve essere contrassegnato come affidabile:

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

2. Sul proxy esterno (Caddy)

Affinché il proxy contatti correttamente il mio server tramite HTTPS, deve inviare l'hostname (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
    }
}

Il blog è ora raggiungibile tramite IPv4 e IPv6, crittografato in modo sicuro, e il mio IP di casa rimane comunque privato! 🚀