होम VPN सर्वर पहुँच से बाहर: NAT श्रृंखला पर चलें

सर्वर LAN पर उत्तर देता है, पोर्ट-फ़ॉरवर्ड नियम सही दिखता है, और फिर भी बाहरी क्लाइंट जुड़ नहीं पाता। एक बार में एक सीमा पार करके बाहर जाना नियम को चौथी बार संपादित करने से तेज़ है, क्योंकि हर सीमा अपना सबूत छोड़ती है: राउटर का WAN पृष्ठ, ISP का अनुवाद और होस्ट पर श्रोता। उस व्यवस्थापन पृष्ठ से शुरू करें जो पहले से खुला है और ऐसे नेटवर्क से परीक्षण पर समाप्त करें जिसे आप नियंत्रित नहीं करते। हर परिणाम चलते-चलते लिखें, क्योंकि क्रम ही निदान है और याद रखी गई संख्या सबूत नहीं है। यदि आपको केवल बाहर जाने वाली सुरंग चाहिए, तो अनुवाद आपकी समस्या नहीं है: केवल बिना माँगा गया भीतर आने वाला ट्रैफ़िक अवरुद्ध होता है।

राउटर के WAN पृष्ठ से शुरू करें

राउटर में लॉग इन करें और पोर्ट-फ़ॉरवर्ड सूची के बजाय स्थिति पृष्ठ पढ़ें। WAN पता, वह इंटरफ़ेस जिससे वह जुड़ा है, और यह कि कनेक्शन प्रकार DHCP, PPPoE या ISP की दी हुई कोई और चीज़ है, नोट करें। फिर उस पते की तुलना उससे करें जो कोई बाहरी सेवा बताती है, मोबाइल डेटा पर फ़ोन का उपयोग करके ताकि अवलोकन उसी राउटर से वापस न जाए। दोनों संख्याएँ अलग-अलग प्रश्नों का उत्तर देती हैं, और उनकी तुलना ही इस चरण का पूरा उद्देश्य है।

देखे गए सार्वजनिक पते से भिन्न WAN पता का अर्थ है कि राउटर के ऊपर कम से कम एक अनुवादक बैठा है। यह अभी खराबी नहीं है, क्योंकि बहुत से प्रदाता डिज़ाइन के अनुसार अनुवाद करते हैं और सेवा फिर भी काम करती है। यदि दोनों मेल खाते हैं, तो संभवतः पता राउटर का है और समस्या आपके नेटवर्क के भीतर चली गई है। किसी भी स्थिति में जोड़ी को तारीख के साथ लिखें, क्योंकि प्रदाता पते फिर से आवंटित करते हैं और पिछले महीने के नोट्स से तुलना बेकार है।

एक हॉप ऊपर जाएँ

राउटर से ही traceroute चलाएँ और पहले कुछ हॉप पढ़ें। बार-बार आते सार्वजनिक पते, निजी पते से उत्तर देने वाला पहला हॉप, या साझा 100.64.0.0/10 श्रेणी के भीतर का पता सभी ऊपर के अनुवादक की ओर संकेत करते हैं। RFC 6598 उस श्रेणी को ठीक इसी तरह की तैनाती के लिए परिभाषित करता है, इसीलिए WAN क्षेत्र में उसे देखना जिज्ञासा नहीं बल्कि प्रबल संकेत है। मार्ग में दो अनुवादक होने पर निशान कम स्पष्ट हो जाता है, इसलिए एक पंक्ति नहीं, पैटर्न पढ़ें।

कुछ प्रदाता आवंटित पता केवल ग्राहक पोर्टल में दिखाते हैं, इसलिए यह निष्कर्ष निकालने से पहले कि राउटर झूठ बोल रहा है, वहाँ देखें। पोर्टल का पता आपके बाहरी अवलोकन से मेल खाए जबकि राउटर कुछ और बताए, यह ऊपर के अनुवादक का सबसे स्पष्ट सबूत है। दोनों पृष्ठ परिवर्तन रिकॉर्ड में रखें, क्योंकि कौन किस सीमा का स्वामी है इस बहस में दो तारीख वाली तस्वीरों से बहुत तेज़ी आती है।

श्रोता और फ़ॉरवर्ड की पुष्टि करें

LAN पर परीक्षण सिद्ध करता है कि सेवा स्थानीय रूप से काम करती है और बाहर से पहुँच के बारे में कुछ सिद्ध नहीं करता। बहुत से राउटर अपने ही फ़ॉरवर्ड नियम का उत्तर भीतर से देते हैं, इसलिए हेयरपिन परीक्षण सफल होता है जबकि बाहरी मार्ग अभी बंद है। पुष्टि करें कि डेमन उसी पते और पोर्ट से बँधा है जो आप मानते हैं, फिर बाहर से परीक्षण करें। नीचे सब कुछ केवल पढ़ने के लिए है।

ss -lunp | grep -E '1194|51820'
ip -4 addr show | grep -E 'inet '
curl -s --max-time 5 ifconfig.me
traceroute -n -m 5 1.1.1.1

यदि बाहरी परीक्षण दिखाता है कि राउटर तक कोई पैकेट नहीं पहुँचा, तो गिरावट ऊपर हुई है और कोई स्थानीय नियम उसे ठीक नहीं करेगा। यदि पैकेट पहुँचते हैं और कुछ उत्तर नहीं देता, तो अगली सीमा श्रोता या होस्ट का फ़ायरवॉल है। होस्ट पर पैकेट कैप्चर तय करता है कि आप दोनों में से किसे देख रहे हैं, और यह नियमों के एक और दौर के अनुमान से कम समय लेता है। तुलना के दौरान श्रोता और उसके परिवहन को अपरिवर्तित रखें, वरना अगला परीक्षण किसी और प्रश्न का उत्तर देगा।

टोपोलॉजी बदलें, वही नियम नहीं

जब अनुवादक ISP का हो, तो समाधान दूसरा मार्ग है, दूसरा फ़ॉरवर्ड नहीं। सार्वजनिक पते वाला छोटा VPS, घर की ओर से बाहर जाने वाली सुरंग से जुड़ा हुआ, सेवा के सामने पहुँचने योग्य अंतिम बिंदु रखता है। प्रदाता द्वारा दिया गया सार्वजनिक पता जहाँ मौजूद है वहाँ सरल है और आमतौर पर मशीन चलाने से सस्ता है। IPv6 अनुवाद को पूरी तरह हटा देता है, बशर्ते क्लाइंट नेटवर्क, DNS रिकॉर्ड और फ़ायरवॉल नीति सभी इसका समर्थन करें।

गतिशील DNS केवल नाम अद्यतन करता है; यह पहुँच नहीं बनाता, और साझा पते की ओर इंगित करने पर क्लाइंट उस प्रदाता गेटवे पर चले जाते हैं जिसका अन्य ग्राहक भी उपयोग करते हैं। वह विफलता ठीक मृत सर्वर जैसी दिखती है, इसीलिए पहले के चरणों का रिकॉर्ड महत्वपूर्ण है। परीक्षण विफल होने पर नाम किस पते पर हल हुआ, यह नोट करें और उत्तर को परीक्षण परिणाम के साथ रखें।

योजना को उस सीमा के इर्द-गिर्द फिर से लिखें जिसे आप नियंत्रित करते हैं: श्रोता, सुरंग और मार्ग। पुराना फ़ॉरवर्ड केवल तब तक रखें जब तक वह कुछ सच बताता है, क्योंकि टोपोलॉजी से मेल न खाने वाला नियम नियम न होने से बुरा है। लिखें कि वास्तव में कौन-सी परत अवरुद्ध कर रही थी और किस सबूत ने यह दिखाया। वरना व्यवस्थापन पृष्ठ खोलने वाला अगला व्यक्ति इस यात्रा का हर चरण शुरू से दोहराएगा।