মূলত আমার ব্লগ সেটআপটি WireGuard-এর মাধ্যমে একটি বিশুদ্ধ IPv6-প্রকল্প হিসেবে পরিকল্পনা করা হয়েছিল, কারণ এটি একটি হোম সার্ভারে চালানো হয় (যাইহোক, আপনি route64.org থেকে বিনামূল্যে IPv6 অ্যাড্রেস পেতে পারেন)। অ্যাক্সেসযোগ্যতা বাড়ানোর জন্য, আমি এখন একটি এক্সটার্নাল 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)

আমার WireGuard IP-তে এই সরাসরি AAAA-এন্ট্রির মাধ্যমে 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 গোপন থাকছে! 🚀