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 नचलेसम्म पोर्ट अस्वीकार गर्छ, केही हरफको लागत हो र एक घण्टाको अनुमान बचाउँछ। त्यसपछि नियम सम्पादन गर्न छोड्नु र त्यसमा भरोसा गर्नुअघि एक दिन हेर्नु।