VPN घरमा जोडिन्छ तर होटलको Wi-Fi मा समय सकिन्छ
उही ल्यापटप, उही खाता, फरक नेटवर्क। त्रुटि कोडलाई एउटा चरणका रूपमा पढ्नुहोस्, नाम जाँच गर्नुहोस्, त्यसपछि कुनै पनि सेटिङ बदल्नु अघि बाहिरी प्याकेट कैद गर्नुहोस्।
ल्यापटप घरको Wi-Fi मा जोडिन्छ, क्लाइन्ट तीन सेकेन्डमा जोडिन्छ, र उही प्रोफाइल एक घण्टापछि होटलमा असफल हुन्छ। बीचमा केही पनि अद्यावधिक भएको छैन। अगाडि क्लाइन्ट राखेर यो हेर्नु मुख्यतः कुन त्रुटि कुन चरणको हो भन्ने जान्नुसँग सम्बन्धित छ, किनकि उपयोगी जानकारी क्लाइन्टले छाप्ने कोडमा छ, त्यो असफल भयो भन्ने तथ्यमा होइन। तलका चार चरण क्रममा गर्नुहोस् र नाम, प्याकेट, पोर्ट वा नीतिले तपाईंलाई अस्वीकार गरेको थाहा पाउनुहुनेछ।
त्रुटि कोडलाई फैसला नभई चरणका रूपमा पढ्नुहोस्
सुरुङ अस्तित्वमा आउनु अघि क्लाइन्ट तीन अलग पडावमा पुग्छ। यसले सर्भरको नाम समाधान गर्छ, नेटवर्कमा केहीबाट जवाफ पाउँछ, र सुरक्षा संगठनमा वार्ता गर्छ। प्रत्येक पडावको आफ्नै असफलता सन्देश हुन्छ, र विशेष गरी Windows कुन चरणको हो थाहा भएपछि फरक कोडहरू उदारतापूर्वक दिन्छ।
| What the client says | Stage that failed | First thing to run |
|---|---|---|
| 868, name did not resolve | DNS, before any packet leaves for the server | Resolve-DnsName vpn.example.net |
| 721 or 806, remote computer did not respond | Outer protocol filtered, typically GRE or UDP | A capture on the local interface |
| 809, server not responding | A device in the path is dropping the outer flow | The same capture, from a second network |
| 789, security layer error | The security exchange started and was rejected | Certificate 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 4IPsec क्लाइन्टसँग तिनका आफ्नै सेटिङ प्यानलमा समान स्विच हुन्छ, सामान्यतया TCP माथि IPsec वा NAT पार गर्ने भनेर वर्णन गरिन्छ। यसलाई बदल्नु पनि एक निदान हो: सुरुङ TCP माथि उठेर UDP मा मर्यो भने तपाईंले नेटवर्कले UDP फिल्टर गर्छ भनी प्रमाणित गर्नुभयो, र त्यो स्थानमा प्रत्येक भ्रमणमा चाहिने सेटिङ पनि भेट्टाउनुभयो।
पहिलो प्रयासमै राउटरका सुविधा बन्द गर्ने लोभको प्रतिरोध गर्नुहोस्। होटल नेटवर्कमा स्टेटफुल निरीक्षण वा बाढी सुरक्षा बन्द गर्नु तपाईंका लागि जसरी पनि उपलब्ध छैन, र आफ्नै उपकरणमा यसले एउटा ल्यापटपका लागि वास्तविक सुरक्षा साट्छ। कुन सेटिङले नतिजा बदल्यो टिपोट गर्नुहोस्, त्यसपछि त्यसलाई फर्काएर राख्नुहोस् र नेटवर्कले पहिले नै अनुमति दिने ट्रान्सपोर्ट खोज्नुहोस्।
दोस्रो नेटवर्कमा उही प्रोफाइल जाँच गर्नुहोस्
टिकट बन्द गर्नु अघि परिवर्तन भवन छोडेपछि पनि टिकिरहेको प्रमाणित गर्नुहोस्। मूल नेटवर्कमा मूल सेटिङसहित फेरि जोडिनुहोस्, पहिलो तीस सेकेन्ड कैद गर्नुहोस्, र क्लाइन्ट हटस्पटमा पुगेकै अवस्थामा पुग्छ भनी पुष्टि गर्नुहोस्:
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 अस्थिर छ" त्यस्तो होइन, र यसले अर्को महिना उही एक घण्टा फेरि बर्बाद हुने ग्यारेन्टी गर्छ।