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 उपकरण वा लोड ब्यालेन्सरको हो।

यी चार परीक्षणपछि मात्र गेटवे सेटिङ परिवर्तन गर्नुपर्छ।