वैध एक-पटक कोड पनि 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 प्रम्प्टले वैध कोड संकलन गरी त्यही अवधिभित्र फेरि बजाउँछ, र तपाईं कहाँ लेख्नुहुन्छ भन्ने अझै प्रमाणपत्रले नै बताउँछ।

क्रमले चुनौतीको जवाफ दिन नसक्ने प्रोफाइलमा पुग्यो भने, प्रोफाइल सुधार्नुहोस् र एउटा नयाँ कोडले फेरि परीक्षण गर्नुहोस्। यो नमिल्ने दर्ता प्यारामिटरमा पुग्यो भने, कसैले केही स्क्यान गर्नु अघि अपरेटरलाई टोकन रेकर्ड पढ्न भन्नुहोस्। यो लकआउटमा पुग्यो भने, क्लाइन्ट बदल्नुको सट्टा सकिने प्रतीक्षा गर्नुहोस् — अवरोध खाताको स्थिति हो, एप होइन।