आउटेज के बाद राउटर VPN ठीक दिख रहा है? इन चार परतों की जाँच करें

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

यहाँ सब कुछ मानता है कि आप साइट पर हैं या आपके पास अंदर आने का ऐसा रास्ता है जो उस टनल पर निर्भर नहीं है जिसे आप जाँच रहे हैं। अगर नहीं, तो अगले आउटेज से पहले वह व्यवस्था कर लें।

पहली परत: क्या WAN सचमुच लौट आया है

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

कुछ एक्सेस नेटवर्क आउटेज के बाद नया प्रवेश चरण भी माँगते हैं। अनुमान लगाने के बजाय पहले विफलता चरण के लिए क्लाइंट लॉग पढ़ें: पहली त्रुटि परत का नाम बताती है, और उसके बाद सब कुछ परिणाम है। टिकट में पता और प्रवेश का परिणाम लिखें, क्योंकि दोनों तय करते हैं कि वही प्रोफ़ाइल कल काम करेगी या नहीं। बदला हुआ पता पाँच मिनट का सुधार और दो घंटे का रहस्य है।

दूसरी परत: प्रमाणपत्र से पहले घड़ी जाँचें

गलत घड़ी प्रमाणपत्र की वैधता और समय-आधारित हर चीज़ में बाधा डालती है, और बिना चालू समय-स्रोत के बूट होने वाला एम्बेडेड डिवाइस कुछ समय पुरानी तारीख पर रह सकता है। तब प्रमाणपत्र सत्यापन ऐसे कारण से विफल होता है जिसका क्रेडेंशियल से कोई संबंध नहीं है। जिसकी तारीखें सालों दूर हों वह वैधता त्रुटि घड़ी की ओर इशारा करती है; वर्तमान तारीखों वाली वही त्रुटि प्रमाणपत्र की ओर इशारा करती है।

date -u
chronyc tracking

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

तीसरी परत: पढ़ें कि टनल क्या कहती है

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

आखिरी ज्ञात अच्छा कॉन्फ़िगरेशन हाथ में रखें ताकि फ़ील्ड फिर से बनाने के बजाय तुलना कर सकें। अगर कोई फ़ील्ड बदला है, तो वही बदलाव निष्कर्ष है। केवल बहाल किया गया पढ़ने के बजाय उसे बहाल किए गए से फ़ील्ड-दर-फ़ील्ड तुलना करें। आउटेज के बाद के ज़्यादातर आश्चर्य वह फ़ील्ड होते हैं जो चुपचाप टेम्पलेट डिफ़ॉल्ट पर लौट गया।

चौथी परत: नीचे के डिवाइस से जाँचें

राउटर के पीछे के क्लाइंट से कोई हानिरहित अनुमति-प्राप्त संसाधन खोलें, फिर पुष्टि करें कि ट्रैफ़िक ने वास्तव में कौन-सा निकास या निजी मार्ग इस्तेमाल किया। DNS और हर उस पता-परिवार की जाँच करें जिसे आप कवर करने का दावा करते हैं, क्योंकि राउटर की अपनी जाँच सफल हो सकती है जबकि क्लाइंट नीति अभी गलत हो — जाँच अक्सर अलग स्रोत, अलग तालिका या अलग रिज़ॉल्वर मार्ग इस्तेमाल करती है।

curl -s https://ifconfig.me
nslookup example.com

अगर टनल डाउन है और सिर्फ़ गलत कॉन्फ़िगर नहीं, तो तय करें कि प्रभावित क्लाइंट को अवरुद्ध करना है या वे अनुमोदित विकल्प इस्तेमाल कर सकते हैं। यह चुनाव आउटेज से पहले की फ़ेलओवर योजना का हिस्सा है, आउटेज के दौरान की चैट थ्रेड का नहीं। देखा गया निकास और रिज़ॉल्वर आउटेज टिकट में लिखें। अब की दो पंक्तियाँ अगले व्यक्ति को विंडो के दौरान कौन-सा रास्ता सक्रिय था, यह अनुमान लगाने का एक घंटा बचाती हैं।

अगला आउटेज छोटा करने के लिए क्या ठीक करें

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

फिर बदलाव के बाद सामान्य रीस्टार्ट परीक्षण दोहराएँ, क्लाइंट-पक्ष की जाँच सहित। जो रीस्टार्ट परीक्षण केवल राउटर का डैशबोर्ड देखता है, वह चारों में सबसे कम जानकारी देने वाली परत जाँचता है।