اصل میں میرا بلاگ سیٹ اپ وائر گارڈ (WireGuard) کے ذریعے خالص IPv6 پروجیکٹ کے طور پر ڈیزائن کیا گیا تھا، کیونکہ یہ سب ایک ہوم سرور پر چل رہا ہے (ویسے، آپ route64.org سے مفت IPv6 ایڈریس حاصل کر سکتے ہیں)۔ رسائی کو بہتر بنانے کے لیے، میں نے اب ایک بیرونی IPv4 پراکسی شامل کی ہے (شکریہ @Larvitz)۔

تاہم، اس دوران فوری طور پر SSL کے مسائل پیدا ہوئے: چونکہ اصل میں A اور AAAA دونوں ریکارڈز پراکسی کے ذریعے چل رہے تھے، اس لیے میرے سرور پر Let's Encrypt کی تصدیق (validation) ناکام ہو گئی۔

حل: "IPv6 ہیک"

اس کا حل یہ تھا کہ AAAA ریکارڈ کو پراکسی کے ذریعے گزارنے کے بجائے براہ راست اپنے سرور کے وائر گارڈ آئی پی (WireGuard IP) پر سیٹ کیا جائے۔

  • ڈومین: blog.burningboard.org
  • A-Record (پراکسی): 194.28.98.217
  • AAAA-Record (سرور): 2a11:6c7:f05:a8::2 (وائر گارڈ)

میری وائر گارڈ آئی پی پر اس براہ راست AAAA ریکارڈ کے ذریعے، Let’s Encrypt اب بھی IPv6 کے ذریعے براہ راست میرے سرور تک پہنچ جاتا ہے (کیونکہ AAAA ریکارڈ کو ڈیفالٹ کے طور پر ترجیح دی جاتی ہے) اور SSL سرٹیفکیٹ جاری کر دیتا ہے۔ IPv4 ٹریفک پراکسی کے ذریعے انکرپٹ ہو کر مجھ تک پہنچتی ہے۔

حتمی کنفیگریشن

اس بات کو یقینی بنانے کے لیے کہ مواصلت بغیر کسی رکاوٹ کے ہو، ہمیں کیڈی (Caddy) سرورز میں ترمیم کرنی پڑی:

1. میرے سرور پر (NixOS, blog.nix)

تاکہ آنے والے صارفین کے اصل آئی پی ایڈریس درست طریقے سے موصول ہوں اور پراکسی کے آئی پی سے تبدیل نہ ہوں، اسے قابلِ اعتماد (trusted) قرار دینا ضروری ہے:

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 دونوں پر دستیاب ہے، محفوظ طریقے سے انکرپٹڈ ہے اور میرا ہوم آئی پی اب بھی پرائیویٹ ہے! 🚀

MD-Blog