Inițial, configurația blogului meu a fost planificată ca un proiect pur IPv6 prin WireGuard, deoarece totul rulează pe un server de acasă (apropo, puteți obține adrese IPv6 gratuite de la route64.org). Pentru a îmbunătăți accesibilitatea, am adăugat acum un proxy IPv4 extern (mulțumesc @Larvitz).

Totuși, au apărut imediat probleme SSL: deoarece inițial atât înregistrarea A, cât și AAAA treceau prin proxy, validarea Let's Encrypt pe serverul meu a eșuat.

Soluția: „IPv6-Hack”-ul

Soluția a fost direcționarea explicită a înregistrării AAAA direct către IP-ul WireGuard al serverului meu, în loc să o trec și pe aceasta prin proxy.

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

Prin această înregistrare AAAA directă către IP-ul meu WireGuard, Let’s Encrypt continuă să îmi acceseze serverul direct prin IPv6 (deoarece înregistrarea AAAA este prioritizată implicit) și emite certificatul SSL. Traficul IPv4 este redirecționat către mine de către proxy, fiind criptat.

Configurația finală

Pentru ca procesul de comunicare să funcționeze fără probleme, a trebuit să ajustăm serverele Caddy:

1. Pe serverul meu (NixOS, blog.nix)

Pentru ca IP-urile reale ale vizitatorilor să ajungă corect și să nu fie suprascrise de IP-ul proxy-ului, acesta trebuie marcat ca fiind de încredere:

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

2. Pe proxy-ul extern (Caddy)

Pentru ca proxy-ul să apeleze corect serverul meu prin HTTPS, acesta trebuie să trimită și numele de gazdă (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
    }
}

Blogul este acum accesibil prin IPv4 și IPv6, criptat în siguranță, iar IP-ul meu de acasă rămâne în continuare privat! 🚀