في الأصل، كان إعداد مدونتي مخططاً له كمشروع IPv6 خالص عبر WireGuard، حيث يتم تشغيل النظام بالكامل على خادم منزلي (بالمناسبة، يمكنك الحصول على عناوين IPv6 مجانية من route64.org). ولزيادة إمكانية الوصول، قمت الآن بإضافة بروكسي IPv4 خارجي (شكراً لـ @Larvitz).

ومع ذلك، ظهرت مشاكل في SSL على الفور: نظرًا لأن كلا السجلين A و AAAA كانا يمران عبر البروكسي في البداية، فقد فشل التحقق من Let's Encrypt على خادمي.

الحل: «خدعة IPv6»

كان الحل هو توجيه سجل AAAA صراحةً وبشكل مباشر إلى عنوان IP الخاص بـ WireGuard على خادمي، بدلاً من تمريره عبر البروكسي أيضاً.

• النطاق (Domain): blog.burningboard.org
• سجل A (البروكسي): 194.28.98.217
• سجل AAAA (الخادم): 2a11:6c7:f05:a8::2 (WireGuard)

من خلال سجل AAAA المباشر هذا إلى عنوان IP الخاص بـ WireGuard، لا يزال بإمكان 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 المنزلي الخاص بي خاصاً! 🚀