Първоначално конфигурацията на моя блог беше планирана като чисто IPv6 проект чрез WireGuard, тъй като всичко се хоства на домашен сървър (между другото, безплатни IPv6 адреси можете да получите от route64.org). За да подобря достъпността, добавих външно IPv4 прокси (благодаря на @Larvitz).

При това обаче веднага възникнаха проблеми със SSL: Тъй като първоначално и A, и AAAA записите минаваха през проксито, валидирането на Let's Encrypt на моя сървър се провали.

Решението: „IPv6 хакът“

Решението беше изрично да насоча AAAA записа директно към WireGuard IP адреса на моя сървър, вместо да го прекарвам и него през проксито.

  • Домейн: blog.burningboard.org
  • A-запис (Прокси): 194.28.98.217
  • AAAA-запис (Сървър): 2a11:6c7:f05:a8::2 (WireGuard)

Чрез този директен AAAA запис към моя WireGuard IP адрес, Let’s Encrypt продължава да достига до сървъра ми директно чрез IPv6 (тъй като AAAA записът се приоритизира по подразбиране) и издава SSL сертификата. IPv4 трафикът се препраща към мен криптиран от проксито.

Финалната конфигурация

За да може комуникацията да работи гладко, трябваше да коригираме Caddy сървърите:

1. На моя сървър (NixOS, blog.nix)

За да пристигат правилно реалните IP адреси на посетителите и да не бъдат презаписани от IP адреса на проксито, то трябва да бъде маркирано като доверено:

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

2. На външното прокси (Caddy)

За да може проксито да се свързва правилно с моя сървър чрез HTTPS, то трябва да изпраща името на хоста (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
    }
}

Блогът вече е достъпен чрез IPv4 и IPv6, сигурно криптиран, а домашният ми IP адрес остава скрит! 🚀

MD-Blog