Ban đầu, thiết lập blog của tôi được lên kế hoạch như một dự án thuần IPv6 thông qua WireGuard, vì toàn bộ hệ thống được vận hành trên một máy chủ tại gia (nhân tiện, bạn có thể nhận địa chỉ IPv6 miễn phí tại route64.org). Để tăng khả năng truy cập, hiện tại tôi đã bổ sung thêm một proxy IPv4 bên ngoài (Cảm ơn @Larvitz).

Tuy nhiên, ngay lập tức đã nảy sinh các vấn đề về SSL: Vì ban đầu cả bản ghi A và AAAA đều chạy qua proxy, nên việc xác thực Let's Encrypt trên máy chủ của tôi đã thất bại.

Giải pháp: „IPv6-Hack“

Giải pháp là trỏ trực tiếp bản ghi AAAA vào IP WireGuard của máy chủ thay vì dẫn nó qua proxy.

  • Tên miền: blog.burningboard.org
  • Bản ghi A (Proxy): 194.28.98.217
  • Bản ghi AAAA (Máy chủ): 2a11:6c7:f05:a8::2 (WireGuard)

Thông qua bản ghi AAAA trực tiếp này tới IP WireGuard, Let’s Encrypt vẫn có thể kết nối trực tiếp với máy chủ của tôi qua IPv6 (vì bản ghi AAAA được ưu tiên theo mặc định) và cấp chứng chỉ SSL. Lưu lượng IPv4 sẽ được proxy mã hóa và chuyển tiếp đến tôi.

Cấu hình cuối cùng

Để quá trình giao tiếp diễn ra suôn sẻ, chúng tôi đã phải điều chỉnh máy chủ Caddy:

1. Trên máy chủ của tôi (NixOS, blog.nix)

Để IP thực của khách truy cập được gửi đến chính xác và không bị ghi đè bởi IP của proxy, proxy này cần được đánh dấu là đáng tin cậy:

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

2. Trên proxy bên ngoài (Caddy)

Để proxy có thể kết nối chính xác với máy chủ của tôi qua HTTPS, nó phải gửi kèm tên máy chủ (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
    }
}

Giờ đây blog đã có thể truy cập qua cả IPv4 và IPv6, được mã hóa an toàn và IP nhà riêng của tôi vẫn được giữ kín! 🚀

MD-Blog