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 पत्ता सर्वात लहान उपाय आहे आणि साधारणपणे छोटे मासिक शुल्क असते। VPN, ग्राहक नेटवर्क आणि DNS नोंदी सर्वांनी समर्थन दिल्यास नेटिव्ह IPv6 दोन्ही टोकांवरील भाषांतर काढून टाकते। घरच्या नेटवर्कमध्ये सबनेट राउटर असलेले मेश ओव्हरले VPS शिवाय तोच रिले देते, पण समन्वय सेवेवरील अवलंबित्वाच्या किमतीत।

गरज स्थिर आत येणारी प्रवेश असेल आणि प्रत्येक नियम तुमच्या नियंत्रणात राहिला पाहिजे असेल तर रिले निवडा। बजेट परवानगी देत असेल आणि ध्येय फक्त याचा विचार करणे थांबवणे असेल तर ISP पत्ता निवडा।