Azure OpenVPN बोगदा सुमारे दर साठ सेकंदांनी तुटतो का

बोगदा त्याची हातमिळवणी पूर्ण करतो, सुमारे एक मिनिट रहदारी वाहून नेतो आणि नंतर पुन्हा जोडतो। हा क्रम नेहमीच्या संशयिताला वगळतो, कारण पोर्ट अडवणारा फायरवॉल सत्र नव्हे, हातमिळवणी थांबवला असता। तुमच्याकडे जे आहे ते जिवंतपणाबद्दलचे मतभेद आहे: एका बाजूने दुसरी बाजू गप्प झाली असे ठरवले आणि चालत्या बोगद्याचा नाश केला। लॉगची ओळ कोणती बाजू ते सांगते, आणि तीच उपाय निवडते।

कोणत्याही टाइमरला स्पर्श करण्यापूर्वी ती ओळ वाचा।

समजूत: मार्गात काहीतरी बोगदा अडवत आहे

पोर्ट अडवलेला असता, तर कनेक्शन सुरुवातीलाच अयशस्वी झाले असते आणि अयशस्वीच राहिले असते। पुनरावृत्ती होणाऱ्या चक्राचा अर्थ नियंत्रण संदेश वाहत आहेत, सत्रे स्थापित होत आहेत, आणि संभाषणाच्या नंतरच्या भागात काहीतरी सतत कालबाह्य होत आहे। अडवणूक शांतता निर्माण करते, आणि हे लय निर्माण करते।

लय हाच उपयुक्त सुगावा आहे। टाइमर ती निर्माण करतात; पॅकेट हानी क्वचितच।

टाइमरपूर्वी डिस्कनेक्टचे कारण वाचा

OpenVPN त्याच्या कारणाला नाव देतो, आणि प्रत्येक नाव वेगळ्या उपप्रणालीकडे निर्देश करते। Session invalidated: KEEPALIVE_TIMEOUT हा संपणारा टाइमर आहे, म्हणून दोन्ही टोकांवर ping आणि ping-restart मूल्यांची तुलना करा। AUTH_FAILED ओळखपत्रे किंवा प्रमाणपत्राची स्थिती आहे, आणि कोणताही टाइमर बदल मदत करणार नाही। TLS त्रुटीचा अर्थ दोन्ही पक्ष keepalive टप्प्यापर्यंत पोहोचलेच नाहीत।

कनेक्टची वेळ, डिस्कनेक्टची वेळ आणि मध्यांतर सेकंदापर्यंत स्थिर आहे का ते नोंदवा। ते एकच मापन नियोजित वेळापत्रकाला योगायोगापासून वेगळे करते।

स्थिर मध्यांतर टाइमर आहे। सरकणारे मध्यांतर बहुधा मार्गाची समस्या किंवा स्थलांतरित सत्र आहे।

कधीही एकमत न झालेले दोन keepalive टाइमर

पोर्टलवरून निर्यात केलेल्या प्रोफाइल्स कधीकधी समुदाय सर्व्हर टेम्पलेटवरून कॉपी केलेल्या keepalive किंवा ping-restart ओळी अजूनही ठेवतात। गेटवे स्वतःची मृत-सोबत्याची ओळख चालवतो आणि स्वतःच्या अपेक्षा लादतो, आणि दोन्ही वेळापत्रके जुळणे आवश्यक नाही। ती वेगळी पडल्यास, क्लायंट गेटवेने कधीही मान्य न केलेल्या वेळापत्रकानुसार पुन्हा सुरू होतो।

दोन्ही मूल्ये एकच नियंत्रण नाहीत। ping म्हणजे क्लायंट किती वेळा प्रतिध्वनी पाठवतो, आणि ping-restart म्हणजे बोगदा कोसळण्यापूर्वी तो काहीही न ऐकता किती काळ थांबतो। कमी ping-restart असलेले प्रोफाइल आणि हळू उत्तर देणारा गेटवे प्रत्येक शांत कालावधीत पुन्हा सुरू होतील, जो एका मिनिटाच्या चक्राचा आकार बरोबर आहे।

क्लायंटच्या बाजूने सर्वात लहान बदल म्हणजे प्रोफाइलच्या सर्वोच्च स्तरावर, प्रत्येक इनलाइन ब्लॉकच्या बाहेर टाइमर निष्क्रिय करणे:

keepalive 0 0

जतन करा, प्रोफाइल पुन्हा लोड करा, पुन्हा कनेक्ट करा। मेमरीत आधीच असलेले सत्र जुनी मूल्ये ठेवते, म्हणून संपादन कधीकधी काहीच केले नसल्यासारखे वाटते।

प्रमाणपत्राचे नाव तुमच्या पायाखालून सरकू शकते

Azure प्रमाणपत्र प्रमाणीकरण आज गेटवे जे नाव सादर करतो त्यावर क्लायंटचा विश्वास असण्यावर अवलंबून आहे। जुन्या डाउनलोडमधील verify-x509-name ओळ असे नाव पिन करू शकते जे गेटवेच्या पुनर्बांधणीने किंवा प्रमाणपत्र नूतनीकरणाने तेव्हापासून बदलले आहे, आणि विसंगती स्पष्ट त्रुटीऐवजी पुनःकनेक्शन लूप म्हणून दिसते। ओळ हटवल्याने कनेक्टिव्हिटी परत येते, ज्यामुळे ते चांगले निदान आणि वाईट कायमचा उपाय बनते, कारण ते पडताळणीही काढून टाकते। बोगदा टिकून राहिल्यावर, गेटवे प्रत्यक्षात जे नाव सादर करतो त्यासह ओळ पुनर्संचयित करा।

गेटवे संपादित करण्यापूर्वी त्याच मशीनवर दुसरी पिढीचा क्लायंट तपासा। जर एक क्लायंट लूपमध्ये असेल आणि दुसरा टिकून असेल, तर प्रोफाइल समस्या नाही।

काय बदलावे, आणि कोणत्या क्रमाने

पुढे स्थलांतरित सत्र तपासा। एक प्रमाणपत्र सामायिक करणारी दोन उपकरणे एकमेकांना बाहेर ढकलू शकतात, आणि निकाल नियतकालिक दिसतो कारण दोन्ही बाजू पुन्हा जोडत राहतात। त्याच ओळखीसाठी वारंवार दिसणाऱ्या पॉइंट-टू-साइट सत्र नोंदींची तुलना करा।

नंतर काही मिनिटे सतत रहदारी चालवून निष्क्रिय मार्ग तपासा। रहदारी वाहत असताना तुटणे थांबल्यास, महत्त्वाचा टाइमर OpenVPN चा नसून मार्गावरील NAT उपकरणाचा किंवा लोड बॅलन्सरचा आहे।

या चार चाचण्यांनंतरच गेटवे सेटिंग्ज बदलल्या पाहिजेत।