कॅप्टिव्ह पोर्टल तुमचे VPN का अडवते आणि पुन्हा साइन इन कसे करावे
सार्वजनिक Wi-Fi तुमच्या डिव्हाइसला त्यातून एकही पॅकेट बाहेर पडण्यापूर्वी मंजुरी देते। पोर्टल काय टाकून देते, तुमचे VPN ते चुकीचे का नोंदवते आणि कोणत्या क्रमाने तुम्हाला पुन्हा जोडते।
खुल्या नेटवर्कवर तुमचा ॲक्सेस पॉइंट पॅकेट्स फक्त इंटरनेटला देत नाही। वरचा धोरण बिंदू तुमच्या डिव्हाइसला अद्याप मंजुरी मिळाली आहे का ते तपासतो, आणि मिळेपर्यंत जवळपास सर्व टाकून दिले जाते। तुमचा VPN क्लायंट त्या शांततेला मृत सर्व्हर म्हणून वाचतो। तो हे क्वचितच सांगतो: WireGuard हँडशेक रिकाम्यात पुन्हा पाठवतो, OpenVPN कनेक्शन कालबाह्य झाल्याची नोंद करतो, आणि IKEv2 प्रतिसाद न देणाऱ्या दूरच्या सर्व्हरबद्दल त्रुटी 809 घेऊन परत येते।
पोर्टल प्रत्यक्षात काय नियंत्रित करते
कॅप्टिव्ह पोर्टल ही एकमेकांना चिकटवलेल्या दोन गोष्टी आहेत: धोरण निर्णय बिंदू आणि पुनर्निर्देशक। तुमचे डिव्हाइस जोडले जाऊन DHCP भाडेपट्टा घेते तेव्हा नेटवर्क तुम्हाला मंजुरीपूर्व अवस्थेत ठेवते।
ती अवस्था फायरवॉल नियमांचा संच आहे। ती सहसा DNS ला परवानगी देते आणि पोर्टल होस्टच्या छोट्या यादीपर्यंत HTTP किंवा HTTPS ला परवानगी देते, आणि बाकी सर्व टाकून देते। परवानगी दिलेली यादी म्हणजे भिंतींनी वेढलेली बाग, आणि त्यात जवळपास कधीही VPN एंडपॉइंट नसतो।
यापैकी कोणतेही टाकून देणे नम्र नाही। VPN सर्व्हरकडे पाठवलेली पॅकेट्स नाकारण्याऐवजी टाकून दिली जातात, त्यामुळे क्लायंटला ICMP unreachable किंवा TCP reset मिळत नाही, फक्त उत्तराची अनुपस्थिती मिळते। विक्रेत्यानुसार पुनर्निर्देशक पोर्ट 80 वर साइन-इन पृष्ठाकडे पुनर्निर्देशनासह उत्तर देऊ शकतो, तर पोर्ट 443 टाकून दिला जातो किंवा अडवला जातो। पुनर्निर्देशने ओळखणे सोपे आहे कारण ती साधे HTTP उत्तर वाहतात; 443 वरील अडवणुकीसाठी असे प्रमाणपत्र लागते ज्यावर तुमचा ब्राउझर विश्वास ठेवण्यास नकार देईल।
मंजुरी स्वतः सहसा डिव्हाइसच्या MAC पत्त्याशी जोडलेली असते, कधीकधी भाडेपट्ट्याने घेतलेल्या IP शी, आणि ती टाइमरसह सत्र सारणीत राहते। साइन इन केल्याने एक नोंद तयार होते। तुमचा रहदारी जाण्यास परवानगी देणारा फायरवॉल नियम ती नोंद असेपर्यंतच असतो, आणि म्हणूनच तुमच्या बाजूने काहीही न बदलता संपूर्ण समस्या नंतर परत येते।
VPN हँडशेक सुरू होण्यापूर्वीच का मरतो
प्रत्येक प्रोटोकॉलचे स्वतःचे वाहतूक माध्यम असते, आणि मंजुरीपूर्वीचा फायरवॉल प्रत्येकाला वेगळ्या पद्धतीने तोडतो। Windows आणि iOS वरील IKEv2 UDP 500 आणि UDP 4500 वर चालते; त्या पोर्टवरील टाकून देणे 809 म्हणून, किंवा टप्पे वेगळे नोंदवणाऱ्या क्लायंटवर नाव-निराकरणासारखे अपयश म्हणून दिसते। UDP 1194 वरील OpenVPN त्याची मुदत संपेपर्यंत जोडणी अवस्थेत राहते। TCP 443 वरील OpenVPN हे मनोरंजक प्रकरण आहे, कारण पोर्टल TCP हँडशेक पूर्ण करून नंतर त्याच्या पुनर्निर्देशन पृष्ठासह उत्तर देऊ शकते, त्यामुळे तुम्हाला कालबाह्यतेऐवजी TLS त्रुटी दिसते।
WireGuard ही यंत्रणा सर्वात स्पष्टपणे दाखवते। ते रचनेनुसार फक्त UDP आहे, TCP पर्याय नाही, त्यामुळे अज्ञात UDP टाकून देणारा फायरवॉल वाहतूक पूर्णपणे काढून टाकतो। क्लायंट वाढत्या अंतराने हँडशेक सुरुवाती पाठवत राहतो आणि कधीही पूर्ण न होणाऱ्या हँडशेकची नोंद करतो। त्या संदेशात कुठेही Wi-Fi चा उल्लेख नाही, आणि त्यात ब्राउझर उघडावा असे काहीही सुचवलेले नाही।
प्लॅटफॉर्म तुमच्या VPN पूर्वीच अवस्था हेरू पाहतात। Windows साइन-इन सूचना दाखवायची का हे ठरवण्यासाठी ज्ञात URL आणते, Android 204 No Content उत्तर द्यायला हवे असे एंडपॉइंट मागते, आणि Apple उपकरणे छोटी कॅप्टिव्ह-नेटवर्क विंडो उघडतात। ते प्रोब काम करतात कारण पोर्टल अपेक्षित मुख्य भागाऐवजी पुनर्निर्देशनासह उत्तर देते। हेच वर्तन स्पष्ट करते की पोर्टल पूर्णपणे निरोगी कसे दिसू शकते तर तुमचा बोगदा मृत आहे: प्रोब आणि बोगदा वेगळ्या नियमांनी तपासले जातात।
सत्राची कालबाह्यता प्रत्यक्षात काय रीसेट करते
ठिकाणे तुमच्या VPN खात्याशी असंबंधित कारणांनी सत्रे कालबाह्य करतात: निष्क्रियतेची मुदत, सत्राची कमाल लांबी, नवीन DHCP भाडेपट्टा, किंवा दुसऱ्या ॲक्सेस पॉइंटवर पुन्हा जोडणे। टाइमर वाजतो तेव्हा सत्र सारणीतील नोंद नाहीशी होते आणि मंजुरीपूर्वीचा नियम संच चेक-इनच्या वेळी होता तसाच परत येतो।
प्रस्थापित बोगदा निरोगी दिसावा इतका काळ टिकतो। जिवंत-ठेव संदेश बाहेर जात राहतात, आणि क्लायंटला ते जाणवते का हे त्याने प्रतिसाद न मिळालेल्या रहदारीला कसे हाताळले यावर अवलंबून असते, त्यामुळे मार्ग गेल्यानंतरही स्थिती दिवा काही काळ हिरवाच राहू शकतो। नंतर बोगदा पडतो आणि पुन्हा जोडण्याचा प्रत्येक प्रयत्न त्याच अडवलेल्या पोर्टवर अपयशी ठरतो।
त्या क्षणी क्लायंटची त्रुटी तुम्ही कोणत्या टप्प्यावर आहात ते सांगते, जर तुम्ही ती काळजीपूर्वक वाचली तर:
| Symptom | What it means | Next check |
|---|---|---|
| Handshake times out with no reply | Pre-authorization drop on UDP | Load any HTTP page and see whether the portal appears |
| Immediate TLS error on 443 | The portal answered your TCP connection | Authorize, then retry the same profile |
| Authentication rejected | Your credentials reached the server | The network is fine, so treat this as an account problem |
| Connects, then drops repeatedly | Session or lease churn | Watch the portal timer and the lease time |
एक तपशील लोकांना गोंधळात टाकतो: सत्र MAC पत्त्याशी जोडलेले असताना साइन-इन पृष्ठ पुन्हा लोड केल्याने उपयोग होईलच असे नाही। तुम्हाला जोडणी सोडून पुन्हा जोडावे लागते, म्हणजे पोर्टलला कालबाह्य प्रयत्नाऐवजी नवीन मंजुरी प्रयत्न दिसेल।
आधी साइन इन करा, नंतर बोगदा उभारा
जो क्रम चालतो तो असा: डिव्हाइसला मंजुरी द्या, मार्ग सिद्ध करा, VPN सुरू करा, बोगदा सिद्ध करा, आणि नंतर तुमचे नेहमीचे अडवणूक पुनर्संचयित करा। तो शेवटचा टप्पा महत्त्वाचा आहे कारण पोर्टलपर्यंत पोहोचण्यासाठी लागणारी तात्पुरती अवस्था हीच ती अवस्था आहे जी आपत्कालीन स्विच टाळण्यासाठी अस्तित्वात आहे।
बोगद्याबाहेर अडवण्याचा पर्याय असलेल्या डेस्कटॉप क्लायंटला पोर्टल पृष्ठ लोड व्हायला थांबवावे लागते, आणि त्या बोगद्याबाहेरच्या कालावधीत संवेदनशील ॲप्स बंद ठेवावीत; स्थानिक रहदारी संरक्षणाशिवाय बाहेर पडणारा हा एकमेव कालावधी आहे। व्यवस्थापित नेहमी-सुरू डिव्हाइसने तुम्ही धोरण काढण्याऐवजी त्याच्या मालकाने प्रकाशित केलेली प्रक्रिया वापरावी। पोर्टलने प्रमाणपत्र इशारा दाखवला तर थांबा: तो स्वीकारल्यास तुमचे सत्र ठिकाणाच्या अडवणूक प्रॉक्सीतून जाते, आणि ती प्रॉक्सी तुम्ही पाठवता ते सर्व वाचू शकते। Android वर नेहमी-सुरू VPN अंतर्गत लॉकडाउन बोगदा उभारण्यापूर्वीच रहदारी अडवते, आणि काही बिल्ड पोर्टल प्रवाह वगळू शकत नाहीत; तुमचे शक्य नसेल तर लॉकडाउन बंद ठेवण्याऐवजी ठिकाणाचा पर्यायी प्रवेश किंवा दुसरे डिव्हाइस वापरा। Apple चे ऑन-डिमांड नियम प्रोब यशस्वी होईपर्यंत बोगदा नाकारण्यासाठी लिहिता येतात, आणि हॉटेल नेटवर्कवर तुम्हाला हवे असलेले वर्तन तेच आहे।
तुमच्याकडे आधीच असलेल्या साधनांनी क्रमाने पडताळा। बोगद्यापूर्वी प्रोब हेडर आणि मुख्य भाग दोन्ही दिसतील अशा पद्धतीने चालवा, आणि तुमची VPN वाहतूक काही उत्तर मिळवते का ते पहा:
curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'मंजुरीपूर्वी सामान्य पोर्टल दोनपैकी एक उत्तर देते: Location साइन-इन पृष्ठाकडे निर्देश करणारे 302, किंवा पोर्टल पृष्ठ असलेला HTML मुख्य भाग असलेले 200। तुम्हाला कोणते मिळाले ते लिहून ठेवा। साइन इनपूर्वीचे पुनर्निर्देशन अपयश नाही; पोर्टल तुम्हाला कुठे जायचे ते सांगत आहे। पोर्टलने यशाची नोंद केल्यानंतर आदेश पुन्हा चालवा आणि मुख्य भाग शब्दशः Success हा शब्द असलेल्या 200 ची अपेक्षा करा। तीच मालिका प्रोबला अर्थपूर्ण बनवते। तुम्ही कधीही साइन इन करण्यापूर्वी होस्टने सामान्य उत्तर दिले तर या नेटवर्कवर अडवणारे पोर्टल नाही। कॅप्चरमध्ये मंजुरीपूर्वीचे टाकून देणे म्हणजे काहीही परत न येणारी बाहेर जाणारी पॅकेट्स, तर चालणारा मार्ग त्याच प्रवाहाला सुमारे एका सेकंदात उत्तर दाखवतो। जोडा, आणि नंतर कॅप्चर पुन्हा करा।
पोर्टलने होय म्हटल्यानंतरही बोगदा अपयशी ठरला तर
साइन इनचे यश म्हणजे परवानगी दिलेली वाहतूक नाही। अनेक ठिकाणे पोर्टल आणि सामान्य ब्राउझिंगला परवानगी देतात पण UDP पूर्णपणे अडवतात, ज्यामुळे WireGuard आणि UDP OpenVPN तुटलेले राहतात आणि TCP 443 चालते। TCP 443 जाते पण UDP जात नाही, तर ते तुम्ही चुकीचे संरचित केलेला क्लायंट नसून ठिकाणाचे धोरण आहे, म्हणून वाहतूक बदला किंवा मर्यादा स्वीकारून पुढे जा। त्यानंतरही पुन्हा जोडणी अपयशी ठरली तर नेमकी त्रुटी ठेवा; तुम्ही कुठे अडकलात ते ती सांगते।
इतर अपयशे डिव्हाइसवर राहतात। जुन्या MAC शी अजूनही जोडलेले सत्र, स्वतःच्या भाडेपट्ट्यासह दुसरा Wi-Fi अडॅप्टर, किंवा पोर्टलची प्रमाणपत्र सूट कॅशे केलेला क्लायंट — यापैकी प्रत्येक स्वच्छ पुनर्मंजुरीनंतरही अपयशी होत राहू शकतो। जोडणी सोडा, पुन्हा मंजुरी द्या, आणि क्लायंट सेटिंग्जना हात लावण्यापूर्वी एकदा प्रयत्न करा। तुम्ही निरीक्षण करत असलेल्या घटकांमागील स्थापत्य जाणून घ्यायचे असेल तर RFC 8952 वाचण्यासारखे आहे।
पोर्टलने स्वतः मंजुरी देण्यास नकार दिला तर समस्या खात्यात किंवा डिव्हाइस वाटपात आहे आणि कोणतेही VPN सेटिंग ती सोडवणार नाही। VPN चा निर्गम देश बदलल्याने ठिकाणाची स्थानिक प्रवेश अवस्था रीसेट होत नाही; ती सारणी तुमच्या डिव्हाइसशी जोडलेली आहे, तुम्ही निवडलेल्या सर्व्हरशी नाही। ठिकाणाच्या ऑपरेटरला विचारा आणि वेळ द्या, कारण तो सत्र सारणीकडेच पाहील।
पुढील प्रवासापूर्वी तीन गोष्टी लिहून ठेवा: शून्य टप्पा म्हणून पोर्टल पृष्ठ, तुम्ही सोबत नेता त्या प्रत्येक डिव्हाइससाठी अडवणूक थांबवण्याचा टप्पा, आणि तुम्ही खरोखर चाचणी केलेले एक पर्यायी वाहतूक माध्यम। दहा मिनिटांपूर्वी चालणारा बोगदा पुन्हा थांबला तर तो कालबाह्य मंजुरी समजा आणि VPN प्रोफाइलला हात लावण्यापूर्वी पोर्टल पुन्हा तपासा।