CGNAT पछाडिको VPN सर्भरले किन कहिल्यै जडान स्वीकार गर्दैन

100.64 ठेगाना, अन्तै समाधान हुने गतिशील DNS नाम र कुनै आगमन ह्यान्डसेक नहुनु एउटै समस्या हो: वाहक NAT। यसलाई पुष्टि गर्नुहोस्, त्यसपछि बाहिरी ट्राफिक रिले गर्नुहोस्।

राउटरले 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 ठेगाना छान्नुहोस्।

सम्बन्धित लेखहरू