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 मॅन्युअलमध्ये दस्तऐवजीकृत आहेत, जेव्हा मूल्याचा नेमका अर्थ हवा असतो।