VPN बार-बार डिस्कनेक्ट हो रहा है? इस क्रम में जाँचें

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

पहला चरण: अंतराल और त्रुटि का पाठ दर्ज करें

विक्रेता के डैशबोर्ड की जगह क्लाइंट के अपने लॉग से शुरू करें। Linux क्लाइंट पर सेवा लॉग और टनल की जीवंत स्थिति मिलकर इसका अधिकांश हिस्सा कवर करते हैं:

journalctl -u openvpn-client@client --since '3 hours ago' | tail -60
journalctl -u wg-quick@wg0 --since '3 hours ago' | tail -40
wg show
ip -s link show wg0

सिर्फ आइकन का रंग बदलने का पल नहीं, बल्कि अंतिम सफल हैंडशेक के समय-चिह्न और वह पल दर्ज करें जब ट्रैफ़िक रुका। बाद में डिस्कनेक्ट बताने वाला GUI क्लाइंट शायद कर्नल द्वारा कुछ सेकंड पहले पहुँची स्थिति की जानकारी दे रहा हो।

त्रुटि का शब्द-रूप बनाए रखें। टाइमआउट, प्रमाणीकरण का अस्वीकार और एडाप्टर या ड्राइवर की त्रुटि तीन अलग परतों की ओर इशारा करते हैं, और इस समस्या में बर्बाद होने वाला अधिकांश श्रम उन्हें एक मानकर देखने से आता है। पंक्ति को ज्यों का त्यों अपने नोट में कॉपी करें।

दूसरा चरण: प्रोफ़ाइल नहीं, एक चर बदलें

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

Ethernet पोर्ट वाला लैपटॉप दूसरी तुलना देता है जो Wi-Fi को तस्वीर से पूरी तरह हटा देता है। अगर टनल दोनों विकल्पों पर टिकी रहती है, तो मूल एक्सेस नेटवर्क ध्यान देने योग्य है: एक्सेस पॉइंट के बीच रोमिंग, अनुवाद तालिका की अवधि समाप्त होता घरेलू राउटर, या लंबे प्रवाह को रीसेट करती अपस्ट्रीम लिंक।

लिखें कि आपने कौन-सा चर बदला। तुलना तभी गिनी जाती है जब बाकी सब कुछ वैसा ही रहा हो, और इसमें सर्वर का अंतिम बिंदु और दिन का समय भी शामिल है।

तीसरा चरण: अंतराल को परत से जोड़ें

अच्छे सत्र की लंबाई आपके पास मौजूद सबसे सूचनाप्रद अकेली संख्या है। टाइमर छूने से पहले इसे इस सूची के सामने पढ़ें:

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

निष्क्रियता के मामले में सेटिंग प्रोटोकॉल-विशिष्ट हैं और दोनों सिरे मायने रखते हैं। सर्वर पर OpenVPN का keepalive 10 60 हर 10 सेकंड में पिंग भेजता है और एक भी न आने पर 60 सेकंड बाद लिंक फिर शुरू करता है; NAT के पीछे WireGuard क्लाइंट पीयर ब्लॉक में PersistentKeepalive = 25 इस्तेमाल करते हैं। OpenVPN टाइमर पर डेटा चैनल की फिर से बातचीत भी करता है, reneg-sec, जो 2.x में डिफ़ॉल्ट रूप से 3600 सेकंड है।

किसी दूसरे प्रदाता की मार्गदर्शिका से आक्रामक मान न कॉपी करें। हानि वाली मोबाइल लिंक पर छोटा टाइमआउट ठीक वही डिस्कनेक्ट पैदा करता है जिन्हें उसे रोकना था, और सर्वर से भेजे गए मान क्लाइंट प्रोफ़ाइल में आपके सेट किए मानों पर भारी पड़ते हैं।

चौथा चरण: एक समर्थित विकल्प की तुलना करें

अगर ऑपरेटर UDP और TCP दोनों प्रोफ़ाइल प्रकाशित करता है, तो वही डिवाइस और नेटवर्क दूसरे के सामने चलाएँ। कॉपी किए प्रोफ़ाइल में ट्रांसपोर्ट संपादित करने की जगह वास्तविक मेल खाती फ़ाइल इस्तेमाल करें। जहाँ UDP रीसेट होता है वहाँ स्थिर TCP प्रोफ़ाइल समस्या को उसी रास्ते तक सीमित करता है; यह सिद्ध नहीं करता कि TCP हर जगह बेहतर ट्रांसपोर्ट है।

वही तर्क अंतिम बिंदुओं पर लागू होता है। दूसरा सर्वर आज़माएँ और मूल परिणाम उसके बगल में रखें। अगर सिर्फ एक एग्ज़िट सत्र रीसेट करता है, तो यह उस अंतिम बिंदु के बारे में सबूत है, लैपटॉप के हर एडाप्टर को फिर से बनाने का कारण नहीं।

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

सुधार सत्यापित करें, और रोलबैक रखें

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

wg show wg0 latest-handshakes
curl -m 5 -sS https://ifconfig.me
cp client.ovpn client.ovpn.bak   # before editing timers

नया व्यवहार पूरा कार्यदिवस टिकने तक पिछला प्रोफ़ाइल और पिछले टाइमर मान रखें। डिस्कनेक्ट लौटते हैं तो बैकअप बहाल करें, फिर दूसरा प्रयास ज्ञात स्थिति से शुरू हो इसलिए एक बार में एक बदलाव फिर लागू करें।

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