Wi-Fi पोर्टल के लॉगिन को VPN लॉगिन से अलग रखें
दो अलग सिस्टम आपसे साइन इन माँगते हैं: जगह का Wi-Fi और आपका VPN गेटवे। स्क्रीन पर वे एक जैसे दिखते हैं और पूरी तरह अलग चीज़ों की अनुमति देते हैं। हर विंडो पर पूछें: इस रहस्य को वास्तव में कौन सत्यापित कर सकता है?
सार्वजनिक नेटवर्क पर कुछ उपयोगी तक पहुँचने से पहले दो अलग सिस्टम आपसे साइन इन करने को कहते हैं: जगह का Wi-Fi और आपका VPN गेटवे। स्क्रीन पर वे एक जैसे दिखते हैं और पूरी तरह अलग चीज़ों की अनुमति देते हैं। पोर्टल तय करता है कि यह उपकरण स्थानीय नेटवर्क का उपयोग कर सकता है या नहीं; VPN तय करता है कि आप कहीं और के निजी नेटवर्क तक पहुँच सकते हैं या नहीं। मैं हर विंडो पर एक सवाल पूछकर उन्हें अलग रखता हूँ: इस रहस्य को वास्तव में कौन सत्यापित कर सकता है? आगे वह चेकलिस्ट है जो मैं होटलों, हवाई अड्डों और सम्मेलन स्थलों पर दोहराता हूँ, जिनमें वे बिंदु भी हैं जहाँ मैं टाइप करना बंद कर देता हूँ।
हर लॉगिन को उस सेवा से जोड़ें जो उसे जाँचती है
एक होटल कनेक्शन में चार अलग जाँचें हो सकती हैं, और उनमें से केवल कुछ ही आपका इनपुट माँगती हैं। पहले उन्हें क्रम में रखें, क्योंकि स्क्रीन शायद ही बताती है कि वह किस चरण की है।
| Stage | Who checks it | What you give it | What it proves |
|---|---|---|---|
| Wi-Fi association | The access point | WPA2 passphrase or 802.1X credentials | That the device may join this SSID |
| Portal authorization | The venue or its portal provider | Room number, booking name, voucher, email or access code | That a guest may use local access |
| VPN authentication | Your gateway or identity provider | Client certificate, password, one-time code or SSO approval | That the user or device may enter the private network |
| Application login | Each internal service | That service's own account | That you may use that service |
कार्यालयों और विश्वविद्यालयों में आम 802.1X नेटवर्क पहली दो पंक्तियों को धुँधला कर देते हैं। वहाँ Wi-Fi साइन-इन स्वयं RADIUS सर्वर के सामने पहचान जाँच है, और क्लाइंट रूटिंग पहचान प्रस्तुत कर सकता है जबकि असली खाता एन्क्रिप्टेड आदान-प्रदान के भीतर यात्रा करता है। तब भी जाँच नेटवर्क से जुड़ने के बारे में है; वह सुरंग को अधिकृत नहीं करती, और VPN गेटवे उसे किसी बात का प्रमाण नहीं मानता।
क्रम लेबल से अधिक मायने रखता है। कैप्टिव पोर्टल इसलिए हैं क्योंकि जुड़ने के बाद पहुँच दी जा सकती है, इसीलिए कोई स्थान पृष्ठ किसी विशेषज्ञ प्रदाता को सौंप सकता है। IETF का RFC 8952 पोर्टल को उसका अपना घटक मानता है, इसलिए अपरिचित डोमेन जाँचने का कारण है, अपने आप में धोखे का प्रमाण नहीं। डोमेन की तुलना स्थान के लिखित निर्देशों से और फ़ील्ड की तालिका से करें।
जाँचें कि पोर्टल क्या माँग सकता है
पोर्टल के फ़ील्ड हक़ के बारे में हैं, पहचान के बारे में नहीं: कमरा संख्या, बुकिंग का उपनाम, वाउचर कोड, चाबी के आवरण पर छपा कोड, समय-सीमित पास के लिए ईमेल, शर्तों की स्वीकृति। स्थान पहले से जानता है कि कमरा किसने बुक किया, इसलिए वह उन तथ्यों को मिला सकता है बिना ऐसा कुछ जाने जो उसे कहीं और आपके रूप में कार्य करने दे।
उस सूची से आगे कुछ भी ठहराव के योग्य है। हॉटस्पॉट पृष्ठ आपका डोमेन पासवर्ड सत्यापित नहीं कर सकता, और वह आपके VPN के एकबारगी कोड, रिकवरी कोड या निजी कुंजी को भी सत्यापित नहीं कर सकता, और उसके पास उन्हें माँगने का कोई कारण नहीं है। एकमात्र वैध अपवाद किसी संगठन द्वारा संचालित नेटवर्क है: कार्यालय का अतिथि SSID या सम्मेलन का Wi-Fi आपको उस पहचान प्रदाता तक भेज सकता है जिसे आप पहले से काम के लिए उपयोग करते हैं। वह अब भी अलग पहचाना जा सकता है: साइन-इन होस्ट आपका रोज़मर्रा वाला है, सहमति स्क्रीन आपके टेनेंट का नाम लेती है, और प्रवाह दिखाई देने वाले ब्राउज़र टैब में खुलता है।
मार्केटिंग ईमेल अलग है: यात्रा उपनाम आपकी कार्य पहचान दिए बिना फ़ील्ड पूरा कर देता है।
जाँचें कि VPN क्लाइंट अपने ही क्रेडेंशियल चाहता है
क्लाइंट ठीक वही माँगता है जिसके लिए उसकी प्रोफ़ाइल कॉन्फ़िगर है, इसलिए अपेक्षित विंडो प्रोफ़ाइल का गुण है, उस नेटवर्क का नहीं जिस पर आप संयोगवश हैं। प्रमाणपत्र प्रोफ़ाइल आमतौर पर प्रोफ़ाइल चयन दिखाती हैं और फिर चुपचाप जुड़ जाती हैं। उपयोगकर्ता नाम और पासवर्ड प्रोफ़ाइल दोनों माँगती हैं, अक्सर एकबारगी कोड के साथ। SSO प्रोफ़ाइल आपका ब्राउज़र पहचान प्रदाता पर खोलती हैं और टोकन लेकर लौटती हैं। WireGuard फिर अलग है: यह उपकरणों को सार्वजनिक कुंजी से प्रमाणित करता है और इसमें उपयोगकर्ता लॉगिन नहीं है, इसलिए WireGuard का उपयोगकर्ता नाम और पासवर्ड माँगने वाली विंडो WireGuard का वर्णन नहीं करती।
यात्रा से पहले प्रोफ़ाइल पढ़ें। OpenVPN में auth-user-pass आपको बताता है कि पासवर्ड अनुरोध अपेक्षित है, जबकि cert, key या pkcs12 का अर्थ है कि प्रमाणपत्र को काम करना चाहिए। यदि सामान्यतः बिना अनुरोध जुड़ने वाली प्रोफ़ाइल अचानक पासवर्ड माँगे, तो उस प्रोफ़ाइल पर संदेह करें जो अपना प्रमाणपत्र लोड नहीं कर सकी या किसी अन्य विधि पर गिर गई। अनुरोध किसी भी दिखाई देने वाली विंडो में आपका कार्य पासवर्ड टाइप करने का निमंत्रण नहीं है।
कोई भी वैध VPN क्लाइंट कमरा संख्या, पोर्टल वाउचर या Wi-Fi पासफ़्रेज़ को प्रमाणीकरण इनपुट के रूप में नहीं माँगता। जब ऐसा होता है, तो या तो क्लाइंट वह नहीं है जो होने का दावा करता है, या कोई कैप्टिव पोर्टल सुरंग बनने से पहले ट्रैफ़िक को रोक रहा है और आप लॉगिन जैसा दिखने वाला HTML पृष्ठ पढ़ रहे हैं।
इन पाँच स्थितियों पर रुकें
ये वे बिंदु हैं जहाँ मैं किसी विश्वसनीय वैकल्पिक उपाय के साथ आगे बढ़ने के बजाय रुक जाता हूँ। हर एक को जाँचना सस्ता और गलत होना महँगा है।
- पोर्टल या SSO पृष्ठ पर प्रमाणपत्र या TLS चेतावनी दिखाई देती है। नेटवर्क तक पहुँचने के लिए उस पर क्लिक करके आगे न बढ़ें।
- पृष्ठ ऐसा रहस्य माँगता है जिसे केवल VPN गेटवे या पहचान प्रदाता सत्यापित कर सकता है: डोमेन पासवर्ड, एकबारगी कोड, रिकवरी कोड, निजी कुंजी।
- डोमेन स्थान के छपे निर्देशों या उस साइन-इन होस्ट से मेल नहीं खाता जिसे आपका संगठन अपनी सेवाओं के लिए प्रलेखित करता है।
- आपसे रूट प्रमाणपत्र, कॉन्फ़िगरेशन प्रोफ़ाइल या सहायक अनुप्रयोग स्थापित करने को कहा जाता है जो आपके उपकरण प्रबंधन से नहीं आता।
- ऐसी MFA स्वीकृति आती है जो आपने शुरू नहीं की, या VPN क्लाइंट होटल क्रेडेंशियल माँगता है।
विकल्प कोई दूसरा पासवर्ड नहीं है। फ़ोन हॉटस्पॉट उपयोग करें, रिसेप्शन से नेटवर्क का सटीक नाम और पहुँच विधि पूछें, और पृष्ठ की सूचना नेटवर्क चलाने वाले को या अपने IT डेस्क को दें। इनमें से कुछ भी ऐसे पृष्ठ के सामने क्रेडेंशियल जाँचने की माँग नहीं करता जिसे आप नहीं जोड़ सकते।
विफलता को सही चरण से जोड़ें
दोनों चरण पार होने के बाद भी विफलताएँ होती हैं, और त्रुटि सामान्यतः चरण का नाम लेती है यदि आप क्रम में पढ़ें: जुड़ाव, पता आवंटन, पोर्टल प्राधिकरण, सुरंग स्थापना, फिर आंतरिक संसाधन। पोर्टल कोड समाप्त होने के कारण VPN पासवर्ड बदलना समय बर्बाद करता है और असली समस्या अपनी जगह खड़ी रहती है।
कुछ परीक्षण चरणों को अलग करते हैं। पोर्टल साइन-इन के बाद सामान्य सार्वजनिक HTTPS पृष्ठ माँगें। यदि उसके बजाय पोर्टल लौटे, तो उस परत पर प्राधिकरण कभी पूरा नहीं हुआ। यदि VPN क्लाइंट बताए कि वह गेटवे तक नहीं पहुँच सकता, तो समस्या सुरंग के नीचे है: पोर्टल सत्र, नाम विभेदन, या ऐसा नेटवर्क जो पोर्ट अवरुद्ध करता है। यदि सुरंग ऊपर आती है और एक आंतरिक होस्टनाम विफल होता है, तो निजी नेटवर्क के भीतर नाम विभेदन या नीति बेहतर संदिग्ध है।
पोर्टल सत्र सुरंग से स्वतंत्र रूप से भी समाप्त होते हैं। जब स्थान पहुँच रद्द करता है, तो स्थापित VPN कनेक्शन गिर जाता है भले उसके क्रेडेंशियल कभी गलत नहीं थे। पोर्टल को फिर से अधिकृत करें, फिर VPN दोबारा जोड़ें और उसे फिर से बातचीत करने दें। तब VPN पासवर्ड घुमाना कुछ ठीक नहीं करता और आपको बाहर लॉक कर सकता है।
हर रहस्य केवल उसी सिस्टम को दें जो उसे सत्यापित कर सकता है, और तालिका से न मेल खाने वाले अनुरोध को बचने का कदम नहीं बल्कि रोक का संकेत मानें। यदि दोनों चरण पार हो जाएँ और सुरंग फिर भी इनकार करे, तो कोई भी क्रेडेंशियल बदलने से पहले क्लाइंट की सटीक त्रुटि कैप्चर करें।