गलत VPN प्रयास: कौन-सा क्रेडेंशियल वर्ग सीमा पार कर गया?
विफल प्रयास ने कदाचित कुछ भी नहीं भेजा, या जिसने उत्तर दिया उसे पासवर्ड सौंप दिया। क्या रद्द करना है यह तय करने से पहले कलाकृति को वर्गीकृत करें।
आप गलत VPN से जुड़े और क्लाइंट ने विफलता बताई। उसका महत्व था या नहीं, यह इस पर निर्भर करता है कि विफलता से पहले तार पर क्या गया, और शब्द स्वयं यह नहीं बताता। कुछ हैंडशेक कोई रहस्य ही नहीं ले जाते, जबकि अन्य उस पते का उत्तर देने वाले हर व्यक्ति को पासवर्ड सौंप देते हैं। कुछ भी रद्द करने से पहले निश्चित करें कि इन दोनों में से क्या हुआ।
रुकें और साक्ष्य सुरक्षित रखें
क्लाइंट लॉग, चुनी गई प्रोफ़ाइल, आपके द्वारा लिखा गया पता और अनुमानित समय सुरक्षित रखें। इन्हें क्लाइंट के बाहर कहीं लिख लें, क्योंकि प्रोफ़ाइल संपादन या पुनःस्थापन उस रिकॉर्ड को नष्ट कर देता है जिसकी आपको आवश्यकता होगी। जब तक आपके नियंत्रण वाले मार्ग से एंडपॉइंट की पुष्टि न हो जाए, हर आगे के प्रयास को रोक रखें।
यह पूछते समय कि प्रयास सुरक्षित था या नहीं, कभी भी बिना संपादित प्रोफ़ाइल या लॉग सार्वजनिक फ़ोरम पर न डालें। इन दस्तावेज़ों में अक्सर निजी कुंजी का पथ, आंतरिक होस्टनाम या टोकन होता है, इसलिए पहले संपादित करें और एंडपॉइंट के स्वामी प्रशासक के साथ साझा करें।
सीमा पार क्या जा सकता है
अधिकांश भ्रम इससे आता है कि हर विफलता को एक ही प्रकार की घटना माना जाता है। चार अलग-अलग चीज़ें दूसरी ओर पहुँच सकती हैं: सार्वजनिक प्रमाणपत्र, कुंजी के उपयोग को सिद्ध करने वाला हस्ताक्षर, पासवर्ड या एकबारगी कोड, और ऐसी फ़ाइल जो आपने स्वयं चुनी हो। हर एक का अपना परिणाम और अपना उपचार है। कलाकृति को वर्गीकृत करना वह कदम है जो उसके बाद का सब कुछ तय करता है।
प्रमाणपत्र का मामला सबसे हल्का है, क्योंकि जो यात्रा करता है वह रचना से ही सार्वजनिक है और उसके पहचान-क्षेत्र पहले से ही जुड़ने वाले हर व्यक्ति को दिखाई देते हैं। चुनौती पर हस्ताक्षर यह कहता है कि कुंजी का उपयोग हुआ, यह नहीं कि वह भेजी गई। पासवर्ड उलटा मामला है: जिसे वह मिले वह उसे कहीं और आज़मा सकता है, और पासवर्ड सत्यापित करने के लिए बनी सेवा ठीक उसी मान की इच्छित प्राप्तकर्ता है।
कुंजी का प्रमाण कुंजी का अपलोड नहीं है
आधुनिक TLS इन दो विचारों को जानबूझकर अलग रखता है। RFC 8446 CertificateVerify संदेश का वर्णन करता है, जिसमें क्लाइंट अपने प्रमाणपत्र से मेल खाने वाली निजी कुंजी से एक चुनौती पर हस्ताक्षर करता है। हस्ताक्षर कुंजी को ले जाए बिना स्वामित्व प्रदर्शित करता है, इसलिए प्रमाणपत्र से प्रमाणित प्रयास स्वतः कुंजी का समझौता नहीं है।
इस आश्वासन की एक सीमा है जिसे बताना उचित है। प्रमाण दिखाता है कि कुंजी उस आदान-प्रदान में शामिल थी, और यह नहीं बताता कि मशीन पर कोई स्थानीय प्रोग्राम पहले से क्या पढ़ चुका हो सकता है। यह यह भी नहीं बताता कि किसी अज्ञात प्रयास ने वास्तव में कितनी दूर तक पहुँचा, इसलिए लॉग अब भी सिद्धांत से अधिक महत्वपूर्ण है।
पासवर्ड पूरी तरह भिन्न विश्वास मॉडल का पालन करते हैं। बाहरी सत्यापनकर्ता के साथ कॉन्फ़िगर किया गया केंद्रीकरण प्रस्तुत मान को आगे भेज सकता है, इसलिए उसे प्राप्त करना ही इच्छित कार्य है और गलत गंतव्य सैद्धांतिक नहीं बल्कि वास्तविक अनावरण है।
लॉग से प्रयास का पुनर्निर्माण करें
चार तथ्य प्रयास का पुनर्निर्माण करते हैं: वह पता जिससे वास्तव में संपर्क हुआ, सर्वर की पहचान सत्यापित हुई या नहीं, कौन-सी प्रमाणीकरण विधि चुनी गई, और प्रक्रिया कहाँ रुकी। हर एक क्लाइंट लॉग में दिखता है, और हर एक भिन्न कहानी को बाहर करता है। मार्गों या आवंटित पते के बारे में त्रुटि यह नहीं बताती कि तार पर पहले से क्या था, क्योंकि सुरंग सेटअप विफल होने से पहले प्रमाणीकरण पूरा हो सकता था।
इन तथ्यों को स्मृति से नहीं, क्लाइंट के अपने लॉग से निकालें। एक संकीर्ण फ़िल्टर आउटपुट को संपादित करने और साझा करने लायक छोटा रखता है:
grep -n -i -E 'verify|authentication|certificate|error|timeout' client.log | tail -30इनमें से किसी के लिए होस्टनाम न बदलें। परिचित नाम, वर्तमान DNS उत्तर और सॉफ़्टवेयर द्वारा दिखाई गई प्रमाणपत्र चेतावनी वर्तमान का वर्णन करते हैं, पिछले कनेक्शन का नहीं। पासवर्ड संकेत भी इस बात का प्रमाण नहीं है कि कुछ भेजा गया, क्योंकि क्लाइंट उसे प्रस्तुत करने से पहले विफल हो सकता था।
निर्णय लें, फिर कार्य करें
निर्णय कलाकृति से आता है, इससे नहीं कि विफलता कितनी भयावह दिखी। चारों पंक्तियाँ उन तथ्यों के सामने पढ़ें जिनका आपने पुनर्निर्माण किया:
| Decision | Evidence that puts you here | Evidence that rules it out |
|---|---|---|
| Change the password now | A password was submitted and a server reply arrived | The log stops before any submission |
| Review active sessions | A one-time code was accepted by the wrong endpoint | The code was never sent, or was rejected before use |
| Revoke and reissue | The file you selected contained key material, not just settings | The upload was a profile with no embedded key |
| No further action | The attempt ended before any authentication value was offered | You later find an earlier attempt you had forgotten |
यदि कोई पासवर्ड किसी अनिच्छित सेवा तक पहुँचा, तो खाता प्रबंधन चैनल से उसे बदलें और जाँचें कि कहाँ और उसका पुनःउपयोग हुआ। समाप्त एकबारगी कोड उस मार्ग को बंद करता है, पर उससे बना सत्र नहीं, इसलिए पहचान प्रशासक से सत्रों की समीक्षा करने को कहें। यदि कोई कुंजी फ़ाइल वास्तव में अपलोड हुई, तो दुरुपयोग के प्रमाण की प्रतीक्षा करने के बजाय जारीकर्ता संगठन की निरसन प्रक्रिया अपनाएँ।
फिर सीमित परिणाम लिखें: क्या भेजा गया, क्या अज्ञात रहता है, और किस क्रेडेंशियल पर कार्रवाई चाहिए। वही रिकॉर्ड बाद की समीक्षा में माँगा जाएगा, और वह दोनों सुविधाजनक निष्कर्षों में से किसी से भी अधिक उपयोगी है।