CGNAT के पीछे मौजूद VPN सर्वर कभी कनेक्शन स्वीकार क्यों नहीं करता

राउटर 100.72 से शुरू होने वाला WAN पता बताता है, डायनामिक DNS नाम किसी दूसरे सार्वजनिक पते पर रिज़ॉल्व होता है, और उस राउटर का VPN सर्वर बाहर से कभी हैंडशेक पूरा नहीं करता। पोर्ट फ़ॉरवर्डिंग कॉन्फ़िगर है, सेवा चल रही है, और LAN से परीक्षण अब भी काम करता है। राउटर लॉग में कुछ भी त्रुटि जैसा नहीं दिखता। वह संयोजन कैरियर-ग्रेड NAT है, और कोई फ़ायरवॉल नियम ऐसे पते पर पोर्ट नहीं खोल सकता जो ISP के पास है।

साझा पते की पुष्टि करने में दो मिनट लगते हैं और एक सप्ताह के कॉन्फ़िगरेशन बदलाव बचते हैं।

कैरियर NAT की ओर इशारा करने वाले संकेत

राउटर के स्टेटस पेज पर मौजूद WAN पते की तुलना बाहरी लुकअप के बताए पते से करें। 100.64.0.0/10 के भीतर WAN पता सामान्य संकेत है, और निजी रेंज 10/8, 172.16/12 तथा 192.168/16 का वही अर्थ है। अगर traceroute एक ही सार्वजनिक हॉप बार-बार दिखाए, या कोई शुरुआती हॉप निजी पते से जवाब दे, तो राउटर और इंटरनेट के बीच एक और अनुवादक बैठा है। कुछ ISP आवंटित पता केवल ग्राहक पोर्टल में दिखाते हैं, इसलिए उस मान को traceroute के साथ निर्यात करें।

प्रोटोकॉल या पोर्ट बदलने से मदद नहीं मिलती, क्योंकि समस्या बंद पोर्ट नहीं, इनबाउंड पहुँच है।

फ़ॉरवर्डिंग और डायनामिक DNS इसे क्यों ठीक नहीं कर सकते

पोर्ट-फ़ॉरवर्ड नियम राउटर के WAN इंटरफ़ेस पर एक पोर्ट मैप करता है, लेकिन इनबाउंड ट्रैफ़िक कभी उस इंटरफ़ेस तक नहीं पहुँचता: ISP पहले उसका अनुवाद करता है और केवल वही फ़ॉरवर्ड करता है जो उसकी अपनी तालिका अनुमति देती है। साझा पता डायनामिक DNS में प्रकाशित करने से ग्राहक कई सब्सक्राइबरों द्वारा उपयोग किए जाने वाले ISP गेटवे की ओर जाते हैं, इसलिए नाम रिज़ॉल्व होता है और हैंडशेक फिर भी विफल रहता है। हेयरपिन परीक्षण सफल होते हैं क्योंकि राउटर अंदर से अपने ही नियम का जवाब देता है, और UPnP में बिल्कुल वही अंधा धब्बा है।

ग्राहक को फिर से कॉन्फ़िगर करने से भी मदद नहीं मिलेगी, क्योंकि विफलता किसी भी ग्राहक सेटिंग के पढ़े जाने से पहले होती है।

स्पष्ट रूट के साथ VPS के ज़रिए रिले

सामने एक सार्वजनिक पता रखें ट्रैफ़िक उठा सकने वाला सबसे छोटा VPS किराए पर लेकर, फिर घरेलू राउटर को उसकी ओर आउटबाउंड डायल करने दें। घरेलू नेटवर्क से आउटबाउंड UDP कैरियर NAT पार करता है, इसलिए टनल अंदर से बनता है और VPS पहुँचने योग्य एंडपॉइंट बन जाता है। घरेलू पक्ष स्थिर टनल पते वाला ग्राहक बनता है, सर्वर नहीं।

VPS पर ग्राहक-विशिष्ट डायरेक्टरी प्रविष्टि जोड़ें ताकि सर्वर को पता हो कि घरेलू सबनेट किस पीयर का है, और मेल खाता कर्नेल रूट जोड़ें।

# /etc/openvpn/server/ccd/home-site.conf
ifconfig-push 10.8.0.10 255.255.255.0
iroute 192.168.50.0 255.255.255.0

# server.conf
client-config-dir /etc/openvpn/server/ccd
route 192.168.50.0 255.255.255.0
push "route 10.8.0.0 255.255.255.0"

iroute पंक्ति OpenVPN को बताती है कि घरेलू सबनेट का ट्रैफ़िक कौन-सा ग्राहक प्राप्त करता है; route पंक्ति उस सबनेट को VPS की कर्नेल तालिका में डालती है ताकि पैकेट टनल में प्रवेश ही कर सकें। प्रकाशित सेवा के लिए, सार्वजनिक पोर्ट को 10.8.0.10 पर फ़ॉर्वर्ड करने वाला डेस्टिनेशन NAT नियम जोड़ें और net.ipv4.ip_forward सक्षम करें।

बाहर से मार्ग का परीक्षण करें

सार्वजनिक पक्ष पर हर हॉप सत्यापित करें, क्योंकि सफल टनल यह सिद्ध नहीं करता कि सेवा पहुँचने योग्य है। VPS पर लिसन-स्थिति और पैकेट कैप्चर 'कुछ नहीं आया' और 'आया और गिरा दिया गया' में अंतर करते हैं।

ss -lunp | grep 1194
tcpdump -ni any udp port 1194
nft list ruleset | grep -A4 dnat

# from a phone on mobile data, not the home Wi-Fi
nc -vz -u 203.0.113.10 1194

अगर कैप्चर फ़ोन से पैकेट दिखाए लेकिन कोई जवाब न हो, तो अगला पड़ाव सर्वर कॉन्फ़िगरेशन या फ़ायरवॉल है। अगर कैप्चर कुछ न दिखाए, तो ग्राहक अब भी रिज़ॉल्व कर रहा है या गलत पते पर भेज रहा है।

पहले कीमत तय करने योग्य विकल्प

ISP से समर्पित IPv4 पता सबसे छोटा समाधान है और आमतौर पर छोटा मासिक शुल्क है। नेटिव IPv6 दोनों सिरों पर अनुवाद हटा देता है जब VPN, ग्राहक नेटवर्क और DNS रिकॉर्ड सभी इसे ले जाते हैं। घरेलू नेटवर्क के भीतर सबनेट राउटर वाला मेश ओवरले VPS के बिना वही रिले देता है, पर समन्वय सेवा पर निर्भरता की कीमत पर।

रिले चुनें जब आवश्यकता स्थिर इनबाउंड पहुँच हो और हर नियम आपके नियंत्रण में रहना चाहिए। ISP पता चुनें जब बजट अनुमति दे और लक्ष्य बस इसके बारे में सोचना बंद करना हो।