در ابتدا، تنظیمات وبلاگ من به عنوان یک پروژه صرفاً IPv6 از طریق WireGuard برنامه‌ریزی شده بود، زیرا کل سیستم روی یک سرور خانگی اجرا می‌شود (ضمناً می‌توانید آدرس‌های IPv6 رایگان را از route64.org دریافت کنید). برای افزایش دسترسی‌پذیری، اکنون یک پروکسی IPv4 خارجی اضافه کرده‌ام (با تشکر از @Larvitz).

با این حال، بلافاصله مشکلات SSL به وجود آمد: از آنجایی که در ابتدا هر دو رکورد A و AAAA از طریق پروکسی عبور می‌کردند، اعتبارسنجی Let's Encrypt روی سرور من با شکست مواجه شد.

راه حل: «هک IPv6»

راه حل این بود که رکورد AAAA را به طور صریح مستقیماً به IP وایرگارد (WireGuard) سرورم هدایت کنم، به جای اینکه آن را هم از طریق پروکسی بفرستم.

• دامنه: blog.burningboard.org
• رکورد A (پروکسی): 194.28.98.217
• رکورد AAAA (سرور): 2a11:6c7:f05:a8::2 (WireGuard)

از طریق این رکورد مستقیم AAAA به IP وایرگارد من، Let’s Encrypt همچنان مستقیماً از طریق IPv6 به سرور من دسترسی پیدا می‌کند (زیرا رکورد AAAA به طور پیش‌فرض اولویت دارد) و گواهی SSL را صادر می‌کند. ترافیک IPv4 توسط پروکسی به صورت رمزگذاری شده به من منتقل می‌شود.

پیکربندی نهایی

برای اینکه ارتباط بدون مشکل برقرار شود، مجبور شدیم سرورهای Caddy را تنظیم کنیم:

۱. روی سرور من (NixOS، blog.nix)

برای اینکه IPهای واقعی بازدیدکنندگان به درستی دریافت شوند و توسط IP پروکسی جایگزین نشوند، باید پروکسی به عنوان قابل اعتماد (trusted) علامت‌گذاری شود:

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

۲. روی پروکسی خارجی (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 خانگی من خصوصی باقی می‌ماند! 🚀