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 म्यानुअलमा अभिलेखित छन्, जब कुनै मानको ठ्याक्कै अर्थ चाहिन्छ।