मूल रूप से, मेरा ब्लॉग सेटअप वायरगार्ड (WireGuard) के माध्यम से एक शुद्ध IPv6-प्रोजेक्ट के रूप में नियोजित किया गया था, क्योंकि यह सब एक होम सर्वर पर चलता है (वैसे, आप route64.org पर मुफ्त IPv6 पते प्राप्त कर सकते हैं)। पहुंच बढ़ाने के लिए, मैंने अब एक बाहरी IPv4 प्रॉक्सी जोड़ा है (धन्यवाद @Larvitz)।

हालांकि, इसमें तुरंत SSL समस्याएं आईं: चूंकि मूल रूप से A और AAAA रिकॉर्ड दोनों प्रॉक्सी के माध्यम से चल रहे थे, इसलिए मेरे सर्वर पर Let's Encrypt सत्यापन (validation) विफल हो गया।

समाधान: "IPv6-हैक"

समाधान यह था कि AAAA-रिकॉर्ड को प्रॉक्सी के माध्यम से भेजने के बजाय स्पष्ट रूप से सीधे मेरे सर्वर के वायरगार्ड आईपी (WireGuard-IP) पर निर्देशित किया जाए।

• Domain: blog.burningboard.org
• A-Record (Proxy): 194.28.98.217
• AAAA-Record (Server): 2a11:6c7:f05:a8::2 (WireGuard)

मेरी वायरगार्ड आईपी पर इस सीधे 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 के माध्यम से उपलब्ध है, सुरक्षित रूप से एन्क्रिप्टेड है और मेरा होम आईपी अभी भी निजी रहता है! 🚀