लैपटॉप घर के Wi-Fi से जुड़ता है, क्लाइंट तीन सेकंड में जुड़ जाता है, और वही प्रोफ़ाइल एक घंटे बाद होटल में विफल हो जाती है। बीच में कुछ भी अपडेट नहीं हुआ। सामने क्लाइंट के साथ इसे देखना मुख्यतः यह जानने की बात है कि कौन-सी त्रुटि किस चरण की है, क्योंकि उपयोगी जानकारी उस कोड में है जो क्लाइंट छापता है, इस बात में नहीं कि वह विफल हुआ। नीचे दिए चार चरण क्रम से करें और आप जान जाएँगे कि किसी नाम, पैकेट, पोर्ट या नीति ने आपको अस्वीकार किया।

त्रुटि कोड को चरण के रूप में पढ़ें, फैसले के रूप में नहीं

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

What the client saysStage that failedFirst thing to run
868, name did not resolveDNS, before any packet leaves for the serverResolve-DnsName vpn.example.net
721 or 806, remote computer did not respondOuter protocol filtered, typically GRE or UDPA capture on the local interface
809, server not respondingA device in the path is dropping the outer flowThe same capture, from a second network
789, security layer errorThe security exchange started and was rejectedCertificate and proposal settings on both ends

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

यदि क्लाइंट Windows नहीं है तो उचित सावधानी बरतें। तृतीय-पक्ष क्लाइंट इनमें से अधिकांश को "कनेक्शन विफल" में समेट देते हैं, इसीलिए अगले दो चरण संदेश पर बिलकुल निर्भर नहीं हैं।

टनल को दोष देने से पहले नाम जाँचें

होटल और हवाई अड्डे के नेटवर्क लगातार DNS को रोकते हैं, और पोर्टल पते के साथ उत्तर देने वाला रिज़ॉल्वर ऐसी विफलता पैदा करता है जो मृत सर्वर जैसी ही दिखती है। स्थानीय रिज़ॉल्वर जो कहता है उसकी तुलना किसी सार्वजनिक रिज़ॉल्वर से करें:

Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"

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

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

पता लगाएँ कौन-सा बाहरी पैकेट गायब होता है

टनल में एक बाहरी प्रवाह है जो पूरी तरह आपके और सर्वर के बीच के रास्ते का है, और उसी प्रवाह को बीच के बक्से वर्गीकृत करके गिरा देते हैं। इसे क्लाइंट पर कैप्चर करें, फिर काम करने वाले नेटवर्क की तुलना विफल होने वाले से करें। Windows पर पहली नज़र के लिए अंतर्निहित कैप्चर पर्याप्त है:

pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etl

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

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

एक ट्रांसपोर्ट बदलें और दोबारा जाँचें

एक बार जान लेने पर कि बाहरी प्रवाह गिराया जा रहा है, व्यावहारिक सवाल यह है कि नेटवर्क किस प्रवाह की अनुमति देता है। अधिकांश प्रतिबंधित नेटवर्क बाहर जाते TCP 443 की अनुमति देते हैं क्योंकि अन्यथा वे चल ही नहीं सकते, इसलिए श्रोता को वहाँ ले जाना सामान्य उत्तर है। OpenVPN पर यह सर्वर बदले जाने तक क्लाइंट-पक्ष का स्विच है:

openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4

IPsec क्लाइंट के अपने सेटिंग पैनल में बराबर का स्विच होता है, जिसे आम तौर पर IPsec over TCP या NAT traversal कहा जाता है। इसे बदलना भी एक निदान है: अगर टनल TCP पर ऊपर आता है और UDP पर मर जाता है, तो आपने सिद्ध कर दिया कि नेटवर्क UDP को फ़िल्टर करता है, और वह सेटिंग भी ढूँढ ली जो उस साइट पर हर यात्रा में चाहिए होगी।

पहले प्रयास में राउटर की सुविधाएँ बंद करने के लोभ का विरोध करें। होटल नेटवर्क पर stateful inspection या flood protection बंद करना आपके लिए वैसे भी उपलब्ध नहीं है, और अपने उपकरण पर यह एक लैपटॉप के बदले असली सुरक्षा बदल देता है। नोट करें कि किस सेटिंग ने नतीजा बदला, फिर उसे वापस लगाएँ और ऐसा ट्रांसपोर्ट खोजें जिसकी नेटवर्क पहले से अनुमति देता है।

दूसरे नेटवर्क पर वही प्रोफ़ाइल सत्यापित करें

टिकट बंद करने से पहले सिद्ध करें कि बदलाव इमारत छोड़ने के बाद भी टिका रहा। मूल नेटवर्क पर मूल सेटिंग के साथ दोबारा जुड़ें, पहले तीस सेकंड कैप्चर करें, और पुष्टि करें कि क्लाइंट वही स्थिति पाता है जो हॉटस्पॉट पर पाई थी:

pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddress

अंतिम कमांड जो अंतर सामने लाता है वह रखने योग्य है: प्रोफ़ाइल जुड़ी हुई टनल बता सकती है जबकि उसके अंदर का रूटिंग गलत है, और इससे "VPN चालू है पर कुछ काम नहीं करता" बनता है, जो दूसरा लेख है। अगर आपके संपादन के बाद टनल का प्रकार बदल गया है, तो प्रोफ़ाइल वह नहीं है जो आपने जाँची थी।

फिर वह निष्कर्ष वहाँ लिखें जहाँ अगला व्यक्ति देखेगा। "इस साइट पर कॉर्पोरेट प्रोफ़ाइल को TCP 443 चाहिए; UDP 500 को होटल फ़िल्टर करता है" ऐसा वाक्य है जिस पर सहकर्मी कार्य कर सकता है। "होटलों में VPN अस्थिर है" ऐसा नहीं है, और यह गारंटी देता है कि अगले महीने वही घंटा फिर बर्बाद होगा।

संबंधित लेख