Origine mia blog-agordo estis planita kiel pura IPv6-projekto per WireGuard, ĉar la tuto estas funkciigata sur hejma servilo (senpagajn IPv6-adresojn oni cetere ricevas ĉe route64.org). Por plibonigi la atingeblon, mi nun aldonis eksteran IPv4-prokurilon (Dankon al @Larvitz).

Tamen tuj aperis SSL-problemoj: Ĉar origine kaj la A- kaj la AAAA-rikordo iris tra la prokurilo, la validigo de Let's Encrypt malsukcesis sur mia servilo.

La solvo: La „IPv6-truko“

La solvo estis direkti la AAAA-rikordon eksplicite al la WireGuard-IP de mia servilo, anstataŭ gvidi ĝin same tra la prokurilo.

  • Domanio: blog.burningboard.org
  • A-rikordo (Prokurilo): 194.28.98.217
  • AAAA-rikordo (Servilo): 2a11:6c7:f05:a8::2 (WireGuard)

Per tiu rekta AAAA-rikordo al mia WireGuard-IP, Let’s Encrypt daŭre atingas mian servilon rekte per IPv6 (ĉar la AAAA-rikordo estas defaŭlte prioritatita) kaj eldonas la SSL-atestilon. La IPv4-trafiko estas plusendita al mi ĉifrite de la prokurilo.

La fina agordo

Por ke la komunikado funkciu senprobleme, ni devis adapti la Caddy-servilojn:

1. Sur mia servilo (NixOS, blog.nix)

Por ke la veraj IP-adresoj de la vizitantoj alvenu ĝuste kaj ne estu anstataŭigitaj per la IP de la prokurilo, tiu ĉi devas esti markita kiel fidinda:

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

2. Sur la ekstera prokurilo (Caddy)

Por ke la prokurilo ĝuste kontaktu mian servilon per HTTPS, ĝi devas kune sendi la gastigan nomon (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
    }
}

La blogo nun estas atingebla per IPv4 kaj IPv6, sekure ĉifrita, kaj mia hejma IP-adreso tamen restas privata! 🚀

MD-Blog