जब 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 काम न करे, कुछ पंक्तियों की लागत है और एक घंटे का अनुमान बचाती है। उसके बाद नियम संपादित करना छोड़ दें और उस पर भरोसा करने से पहले एक दिन देखें।