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 traversal असे वर्णन केले जाते। तो बदलणेही एक निदान आहे: बोगदा 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 अस्थिर आहे" तसे नाही, आणि पुढच्या महिन्यात तोच एक तास पुन्हा वाया जाईल याची खात्री देते।