CGNAT पोर्ट्स ब्लॉक करत असताना VPS मार्फत घरचा सर्व्हर प्रकाशित करणे

मी बाहेरून सुरुवात केली, जसे एखादा वापरकर्ता करतो: नाव मोबाइल डेटावर फोनच्या ब्राउझरमध्ये टाइप केले आणि कनेक्शन वेळ संपेपर्यंत लटकत राहिल्याचे पाहिले. नाव सुटत होते, म्हणजे DNS ठीक होते. घरच्या राउटरचे पोर्ट-फॉरवर्डिंग पानही बंद गल्ली होते, कारण त्याचा WAN पत्ता 100.64.31.42 दाखवत होता, आणि हा असा पत्ता नाही जिथे कोणी प्रदाता मला इंटरनेटवरून पाठवेल. हा आकडा सगळी बिघाड समजावून सांगतो: लाइन carrier-grade NAT च्या मागे आहे, त्यामुळे बोगद्याच्या माझ्या बाजूचा सार्वजनिक पत्ता प्रदात्याचा आहे. पुढे तो मार्ग आहे जो मी त्या अडकलेल्या टॅबपासून उत्तर देणाऱ्या सेवेपर्यंत काढला.

क्लायंटपासून सुरुवात करा आणि आत जा

कोणताही नियम बदलण्यापूर्वी साखळी कुठे थांबते ते सिद्ध करा. लॅपटॉपवर मी dig +short files.example.net चालवले आणि VPS चा पत्ता परत मिळाला, ज्यामुळे माझ्या मशीनवरील जुना DNS बाद झाला. मग curl -v --connect-timeout 5 files.example.net:5022 नाकारले जाण्याऐवजी वेळ संपून अडकले. हा फरक महत्त्वाचा आहे: वेळ संपणे म्हणजे सहसा पॅकेट वाटेत टाकले जात आहेत, तर नकार म्हणजे काहीतरी उत्तर देऊन नाही म्हणाले.

आत जाण्याचे पुढचे पाऊल VPS स्वतः होते. ss -ltnp ने 5022 वर ऐकणारे काहीही दाखवले नाही, जे DNAT नियम येण्यापूर्वी अपेक्षित होते. त्याच मशीनवर wg show (किंवा OpenVPN साठी ip -br a show tun0) ने पुष्टी केली की घरचा peer सक्रिय आहे आणि त्याचा handshake ताजा आहे. peer काम करत नसेल तर कोणताही NAT नियम उपयोगी पडणार नाही, आणि घरच्या राउटरच्या VPN पानावरील हिरवा दिवा काहीही अर्थ देत नाही.

घरची लाइन खरोखर CGNAT च्या मागे आहे याची पुष्टी करा

राउटर आपल्या WAN इंटरफेसवर जो पत्ता सांगतो त्याची तुलना बाहेरील सेवा जे पाहते त्याशी करा. 100.64.0.0/10 मध्ये जे काही आहे, म्हणजे 100.64.x.x ते 100.127.x.x, तो RFC 6598 मधील सामायिक पत्ता-श्रेणी आहे आणि इंटरनेटवरून पोहोचण्यायोग्य नाही. राउटरने साधा खाजगी पत्ता असल्याचा दावा केला आणि सार्वजनिक शोधाने काहीतरी असंबद्ध परत दिले तरी तुम्ही त्याच निष्कर्षापर्यंत पोहोचता. CGNAT लाइनसोबत असा सार्वजनिक पत्ताही येऊ शकतो जो पुढच्या lease पर्यंतच टिकतो, त्यामुळे पोर्ट फॉरवर्डिंग एक तास चालल्यासारखी वाटते आणि मग शांतपणे मरते.

काही प्रदाते खरोखर खरा सार्वजनिक पत्ता देतात, पण निवासी खात्यांवर येणारे 80 आणि 443 पोर्ट ब्लॉक करतात. तुमची सेवा फक्त वेब असेल आणि WAN पत्ता खरोखर सार्वजनिक असेल, तर relay बांधण्यापूर्वी सहाय्यकांना विचारा. नसेल तर खालील रचना प्रत्येक पोर्टवर सारखीच लागू होते, आणि प्रयोग राउटरच्या बाजूला थांबवणे योग्य आहे: प्रदात्याच्या नेटवर्कमधील अनुवादक कनेक्शन संपवतो याआधी की ते कधी तुमच्या WAN इंटरफेसपर्यंत पोहोचेल.

नाव VPS च्या पत्त्याकडे निर्देश करा

DNS रहदारी पुढे पाठवत नाही, त्यामुळे सेवेच्या A रेकॉर्डमध्ये VPS चा सार्वजनिक पत्ता असला पाहिजे. 192.168.1.20 कडे A रेकॉर्ड फक्त त्या क्लायंटसाठी उपयुक्तपणे सुटतो जे आधीच VPN मध्ये आहेत; इंटरनेटवरून तो अशा पत्त्यावर सुटतो जो कोणीही राउट करू शकत नाही. स्वतः VPS च्या प्रशासकीय प्रवेशासाठी मी वेगळे नाव ठेवतो, जेणेकरून रेकॉर्ड कोणत्या होस्टशी संबंधित आहे याचा कधीही गोंधळ होणार नाही.

VPS आणि घरचे मशीन दोन्ही HTTP देत असतील, तर प्रत्येकाला स्वतःचे नाव द्या आणि कोण उत्तर देईल हे VPS ला ठरवू द्या. दोन्हींना एका नावात एकत्र करून प्रॉक्सी योग्य backend निवडेल अशी आशा करणे, म्हणजे नक्की अर्धा दिवस चुकीच्या होस्टवर चुका शोधणे.

एक पोर्ट DNAT वर, SSH 22 वर राहू द्या

थेट पर्याय म्हणजे VPS वर गंतव्य NAT. चालू असलेल्या कर्नेलसाठी forwarding सुरू करा आणि नियमात घरच्या सर्व्हरचा बोगदा पत्ता ठेवा, त्याचा LAN पत्ता नाही:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -p tcp -d 198.51.100.10 --dport 5022 -j DNAT --to-destination 10.8.0.2

स्वतः VPS कडे SSH 22 वर ठेवा आणि दुसरा पोर्ट, उदाहरणार्थ 5022, घरच्या मशीनकडे पाठवा. 22 बंद मशीनकडे पाठवले तर ते दुरुस्त करू शकणारा एकमेव मार्ग गमावाल. हाच तर्क प्रॉक्सीला लागू होतो: VPS चा व्यवस्थापन पोर्ट relay नियमांबाहेर ठेवा.

नियम चालू लागल्यावर त्यांना कायमचे करा. Debian किंवा Ubuntu वर apt install iptables-persistent आणि नंतर netfilter-persistent save ते /etc/iptables/rules.v4 मध्ये लिहितात. firewalld असलेल्या होस्टवर समतुल्य म्हणजे झोनमधील कायमचे पोर्ट फॉरवर्डिंग, ज्याला लागू होण्यापूर्वी firewall-cmd --reload लागते. फक्त स्मृतीत राहणारे नियम प्रदात्याच्या पहिल्या देखभाल रीबूटवर नाहीसे होतात, सहसा वाईट वेळी.

परतीचा मार्ग दुरुस्त करा किंवा त्याची गरज टाळा

DNAT फक्त गंतव्य पुन्हा लिहितो. घरचा सर्व्हर कनेक्शन मूळ क्लायंट पत्त्यावरून पाहतो, आणि त्याचा डीफॉल्ट मार्ग घरच्या राउटरकडे असल्यास उत्तर घरच्या WAN मधून बाहेर पडते जिथे प्रदात्याचा अनुवादक ते टाकून देतो. ही विषमता मला आलेली दुसरी बिघाड होती, DNAT नियम पूर्णपणे बरोबर दिसल्यानंतर.

दोन दुरुस्त्या चालतात. घरच्या मशीनला धोरण-मार्ग द्या जेणेकरून बोगद्यातून येणारी रहदारी बोगद्यातून परत जाईल:

ip rule add from 10.8.0.2 table 100
ip route add default dev wg0 table 100

किंवा VPS ला स्रोत पुन्हा लिहू द्या जेणेकरून उत्तराला पोहोचता येईल असा पत्ता असेल, आणि conntrack ते बाहेर जाताना उलटवेल:

iptables -t nat -A POSTROUTING -d 10.8.0.2 -p tcp --dport 5022 -j SNAT --to-source 10.8.0.1

SNAT आवृत्ती खरा क्लायंट पत्ता घरच्या सर्व्हरपासून लपवते, त्यामुळे अनुप्रयोग लॉग peer म्हणून 10.8.0.1 दाखवतात. मूळ पत्ता अनुप्रयोग स्तरावर पुढे पाठवा, किंवा प्रति क्लायंट लॉगिंगचे नुकसान स्वीकारा, पण हा निर्णय जाणीवपूर्वक घ्या, एखाद्या घटनेदरम्यान ते शोधण्याऐवजी.

संपूर्ण मार्ग बाहेरून तपासा

अशा नेटवर्कवरून सत्यापित करा जे VPS नाही आणि घरही नाही: मोबाइल डेटावर फोन, किंवा दुसरीकडे स्वस्त shell. nc -vz files.example.net 5022 ने यशस्वी कनेक्शनची नोंद द्यावी, आणि openssl s_client -connect files.example.net:443 -servername files.example.net ने सार्वजनिक नावासाठी प्रमाणपत्र दाखवावे. मग प्रदात्याचा सुरक्षा गट किंवा क्लाउड फायरवॉल तपासा. कधीही पॅकेट न पाहणारा DNAT नियम सहसा होस्टच्या एक थर वर ब्लॉक होतो.

शेवटी, बोगदा पडल्यावर काय होईल ते ठरवा. DNAT नियम कनेक्शन घेत राहतो आणि ते शांतपणे मृत बोगद्यात टाकतो, जे अगदी बिघडलेल्या सेवेसारखे दिसते. VPS वर आरोग्य तपासणी जी peer काम करेपर्यंत पोर्ट नाकारते, त्याला काही ओळी लागतात आणि एक तासाचा अंदाज वाचवते. त्यानंतर नियम संपादित करणे थांबवा आणि त्यावर विश्वास ठेवण्यापूर्वी एक दिवस पाहा.