मान्य वन-टाइम कोड भी VPN लॉगिन में क्यों विफल होता है

आप VPN क्लाइंट खोलते हैं, पासवर्ड लिखते हैं, और आपके ऑथेंटिकेटर के छह अंक अमान्य लौटते हैं — दो बार, फिर तीसरी बार। खाते में कल से कुछ नहीं बदला है, इसलिए सहज इच्छा ऑथेंटिकेटर की एंट्री हटाकर दोबारा स्कैन करने की होती है — आमतौर पर यही गलत मरम्मत है। वन-टाइम कोड दूसरा पासवर्ड नहीं है: गेटवे को इसे किसी विशेष चरण में, किसी विशेष नामांकित एंट्री से, किसी विशेष विंडो के भीतर माँगना होता है, और अधिकांश अस्वीकृतियाँ अंकों की तुलना से पहले ही होती हैं। नामांकन को छूने से पहले तय करें कि आप किस चरण में हैं।

प्रॉम्प्ट का क्रम बताता है कि आप किस प्रवाह में हैं

लगभग हर कोड-सहित VPN लॉगिन तीन आकारों में आता है। दो-चरणीय आकार में क्लाइंट पासवर्ड भेजता है, सर्वर चुनौती जारी करता है, और क्लाइंट फिर पूछता है। संयुक्त आकार में गेटवे पासवर्ड और कोड एक ही सबमिशन में चाहता है — कभी जोड़कर, कभी ऐसे विभाजक के बाद जिसे केवल ऑपरेटर दस्तावेज़ित करता है। ब्राउज़र आकार में क्लाइंट के पास कोई फ़ील्ड ही नहीं होता: कोड किसी वेब पेज में जाता है, या पुश स्वीकृति उसकी जगह लेती है, और डेस्कटॉप क्लाइंट परिणाम की प्रतीक्षा करता है।

गलत आकार खराब कोड जैसा दिखता है। केवल पासवर्ड वाले फ़ील्ड में ताज़ा कोड चिपकाएँ, और सर्वर उसे पासवर्ड का हिस्सा समझकर पढ़ेगा। क्लाइंट की ओर, OpenVPN 2.4 और बाद के संस्करण अंतर दिखाते हैं: जो सर्वर AUTH_FAILED,CRV1: के साथ उत्तर देता है वह चुनौती-प्रतिक्रिया की अपेक्षा करता है, इसलिए प्रोफ़ाइल को static-challenge या SCRV1: रूप में पासवर्ड फ़ाइल चाहिए। केवल auth-user-pass वाली पुरानी प्रोफ़ाइल पासवर्ड सत्यापित करके रुक जाती है, जो लॉग में OTP विफलता जैसा दिखता है, जबकि कोई कोड भेजा ही नहीं गया।

WireGuard को अपवाद के रूप में गिनना चाहिए: यह लोगों के बजाय कुंजी-जोड़ों को प्रमाणित करता है, इसलिए कोड के लिए कोई फ़ील्ड नहीं है। यदि कोई प्रदाता ऐसा विज्ञापित करता है, तो सुरंग के बाहर कोई चीज़ उसे स्वीकार कर रही है।

सर्वर छह अंकों के साथ क्या करता है

समय-आधारित कोड RFC 6238 का पालन करते हैं, जो RFC 4226 की पुरानी काउंटर-आधारित रचना को लपेटता है: गतिशील कारक पर HMAC, डिफ़ॉल्ट रूप से छह अंकों तक काटा गया। TOTP में गतिशील कारक वर्तमान Unix समय को एक चरण से विभाजित करके होता है, 30 सेकंड, जब तक ऑपरेटर ने इसे न बदला हो। सत्यापनकर्ता कभी भी आपके अंकों की तुलना संग्रहीत मान से नहीं करता; वह साझा बीज से अपेक्षित कोड की पुनर्गणना करता है और आमतौर पर पड़ोसी चरणों को भी स्वीकार करता है, इसलिए धीमा राउंड-ट्रिप लॉगिन को विफल नहीं करता।

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

काउंटर-आधारित टोकन हर दबाव पर अपना काउंटर आगे बढ़ाते हैं, इसलिए कोड बनने के बाद कभी भेजे न जाने पर वे तालमेल से बाहर हो जाते हैं; सामान्य उपाय पुनःसमन्वय विंडो है जो आगे के कुछ मान स्वीकार करती है। यदि ऑपरेटर ने HOTP नामांकित किया है और आपका ऐप TOTP दिखाता है, तो हर मान गलत है ऐसे ढंग से जो घड़ी की समस्या जैसा लगता है। QR कोड के पीछे का प्रोविज़निंग URI प्रकार, अंक, अवधि और हैश बताता है।

गलत कोड जैसी दिखने वाली विफलताएँ

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

दूसरा, बेमेल पैरामीटर सेट। आठ अंकों, 60 सेकंड की अवधि या SHA-256 के साथ नामांकित बीज ऐसे कोड देता है जिन्हें छह अंक, 30 सेकंड और SHA-1 की अपेक्षा करने वाला सत्यापनकर्ता अस्वीकार करता है, और क्लाइंट पर इसे गलत कोड से अलग नहीं पहचाना जा सकता। यह उन माइग्रेशन के बाद दिखता है जहाँ एंट्री QR कोड की तस्वीर से दोबारा जोड़ी गई हो, या जहाँ टोकन रिकॉर्ड डिफ़ॉल्ट मानों से फिर से बनाया गया हो।

तीसरा कोड के बारे में नहीं है। गेटवे आमतौर पर गलत पासवर्ड, समाप्त कोड और निष्क्रिय खाते के लिए एक ही सामान्य प्रमाणीकरण विफलता लौटाते हैं, जानबूझकर, ताकि कोई पता न लगा सके कि कौन-सा कारक विफल हुआ। क्लाइंट के बैनर की जगह गेटवे या RADIUS लॉग पढ़ें: कभी जारी न हुई चुनौती, OTP विशेषता के बिना एक्सेस-अस्वीकृति और नीति-अस्वीकृति स्क्रीन पर एक जैसे दिखते हैं और अलग-अलग अगले चरणों की ओर ले जाते हैं।

इसे सीमित करने वाला छोटा क्रम

सबसे सस्ती जाँच से शुरू करें और पहले ऐसे चरण पर रुकें जो सही न हो।

1. ताज़ा कोड की प्रतीक्षा करें, उसे एक बार भेजें, और देखें कि चुनौती पासवर्ड स्वीकार होने से पहले आती है या बाद में।
2. ऑथेंटिकेटर में लेबल को सर्वर द्वारा संग्रहीत उपयोगकर्ता नाम से मिलाएँ।
3. पुष्टि करें कि प्रोफ़ाइल चुनौती का उत्तर दे ही सकती है, जैसे ऊपर के CRV1 मामले में।
4. डिवाइस की घड़ी की तुलना किसी ज्ञात समय-स्रोत से करें; कुछ दर्जन सेकंड से अधिक का अंतर TOTP को अपने आप तोड़ देता है।
5. ऑपरेटर से पूछें कि टोकन TOTP है या HOTP, और कौन-से अंक, अवधि और हैश नामांकित किए गए।

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

बीज और रिकवरी कोड को चक्र से बाहर रखें

छह अंक और उनके पीछे का रहस्य विनिमेय नहीं हैं। प्रोविज़निंग QR कोड या Base32 बीज खाते का हर भावी कोड बनाता है, इसलिए यह पासवर्ड की ही श्रेणी में आता है: स्क्रीनशॉट में नहीं, टिकट की टिप्पणी में नहीं, और ऐसे किसी व्यक्ति के चैट में नहीं जिसने पहले आपसे संपर्क किया हो। रिकवरी कोड अलग तंत्र हैं — एकल-उपयोग, अक्सर कोड-प्रॉम्प्ट को पूरी तरह छोड़ देते हैं, और खाते को जाँचने के लिए एक खर्च करना ऐसा वैकल्पिक रास्ता हटा देता है जिसकी आपको बाद में ज़रूरत पड़ सकती है।

कोड लॉगिन पेज को भरोसेमंद भी नहीं बनाता: मिलते-जुलते डोमेन पर OTP प्रॉम्प्ट मान्य कोड इकट्ठा कर उसे विंडो के भीतर दोबारा चलाता है, और प्रमाणपत्र ही अब भी बताता है कि आप कहाँ लिख रहे हैं।

यदि क्रम किसी ऐसी प्रोफ़ाइल पर पहुँचे जो चुनौती का उत्तर नहीं दे सकती, तो प्रोफ़ाइल ठीक करें और एक ताज़ा कोड से फिर परखें। यदि वह बेमेल नामांकन पैरामीटर पर पहुँचे, तो किसी के कुछ स्कैन करने से पहले ऑपरेटर से टोकन रिकॉर्ड पढ़ने को कहें। यदि वह लॉकआउट पर पहुँचे, तो क्लाइंट बदलने के बजाय उसके खत्म होने की प्रतीक्षा करें — बाधा खाते की स्थिति है, ऐप नहीं।