keepalive पुनः जडान होइन: तपाईंसँग भएको विफलताअनुसार छान्नुहोस्
एउटा प्याकेटले म्यापिङ जीवित राख्छ; पुनः जडानले सम्बन्ध पुनः निर्माण गर्छ। मेकानिज्मलाई विफलतासँग मिलाउनुहोस्, त्यसपछि वास्तविक अनुरोधले प्रमाणित गर्नुहोस्।
keepalive र पुनः जडान एउटै सासमा कन्फिगर गरिन्छ तर फरक समस्या समाधान गर्छन्, त्यसैले एउटा ट्युन गर्दा अर्को विरलै सुधार्छ। keepalive ले स्टेट प्रविष्टि जीवित राख्न वा साथीले जवाफ दिन छोडेको थाहा पाउन थोरै ट्राफिक पठाउँछ। पुनः जडानले भाँचिएको भत्काएर सम्बन्ध पुनः बनाउँछ, जसमा कुञ्जी, ठेगाना र मार्ग समावेश छन्। विफलतासँग मिल्ने मेकानिज्म छान्नुहोस्, जसको नब तपाईंलाई पहिले नै थाहा छ त्यो होइन। दुई प्रश्नले यो निर्णय गर्छन्: मार्ग मरेको हो, वा साथीहरूबीच केहीले यसलाई बिर्सिरहेको छ?
जब म्यापिङ नै समस्या हो
केही मिनेटको मौनतापछि मात्र मर्ने टनेलले सामान्यतया साथीलाई होइन, अनुवाद प्रविष्टि गुमाउँछ। WireGuard को PersistentKeepalive NAT र फायरवाल स्टेटका लागि अवस्थित छ, र परियोजनाका आफ्नै टिप्पणीहरूले यसलाई ठ्याक्कै त्यसै गरी वर्णन गर्छन्, स्वास्थ्य जाँचका रूपमा होइन। केही दशक सेकेन्डको अन्तरालले प्रविष्टि तातो राख्छ, जबकि प्रत्येक सेकेन्डमा एउटा प्याकेट ब्याट्रीको निर्णय हो, विश्वसनीयताको होइन। OpenVPN उही ठाउँमा पुग्छ ping र ping-restart मार्फत, जसले पहिले मौनता महसुस गर्छन् र त्यसपछि त्यसमा कार्य गर्छन्।
यी सेटिङहरू प्रोटोकलहरूबीच पनि साटासाट गर्न मिल्दैन। IKEv2 को मृत साथी नीति, OpenVPN को ping टाइमर र WireGuard को keepalive एउटै प्रश्नको उत्तर तीन फरक सिन्ट्याक्स र तीन फरक पूर्वनिर्धारित मानसहित दिन्छन्, त्यसैले तिनीहरूबीच संख्या प्रतिलिपि गर्नु ट्युनिङको भेषमा गरिएको अनुमान हो।
जब सम्बन्ध गइसक्यो
यदि साथीले ठेगाना बदल्यो, प्रमाणपत्रको म्याद सकियो वा टाढाको छेउ पुनः सुरु भयो भने, साना प्याकेट मर्मत होइनन्। पुनः जडानले स्टेट पुनः निर्माण गर्नुपर्छ : ठेगाना लिनुहोस्, मार्गहरू पुनः स्थापना गर्नुहोस्, कुञ्जीहरू पुनः वार्ता गर्नुहोस् र केही तैनाथीहरूमा प्रयोगकर्तालाई पुनः प्रमाणित गर्नुहोस्।
निगरानीबिना पुनः जडान गर्ने क्लाइन्टहरूले प्रमाणपत्र वा भण्डारण गरिएको गोप्य राख्छन्। मानिसलाई सोध्ने क्लाइन्ट ठ्याक्कै कोही उपस्थित नहुँदा असफल हुन्छ, र यही त्यो परिदृश्य हो जहाँ पुनः जडानको महत्त्व थियो। यो महिनौं अघि गरिएको डिजाइन निर्णय हो, आउटेजका बेला बदल्न सकिने सेटिङ होइन।
दुवैले के प्रमाणित गर्दैनन्
टनेल पुनः जडान भएको, कुञ्जी र मार्गसहितको हुन सक्छ तर त्यसपछाडिको सेवा बन्द हुन सक्छ, र keepalive ले सर्भर घण्टौं अघि गएको सत्रका लागि म्यापिङ खुला राख्न सक्छ। तपाईंलाई साँच्चै महत्त्वपूर्ण कुरा उपलब्ध नहुँदा दुवै मेकानिज्मले सफलता रिपोर्ट गर्न सक्छन्।
त्यसैले परीक्षण वास्तविक अनुरोधमा टुंगिन्छ। तपाईंलाई महत्त्वपूर्ण अन्तरालपछि टनेलबाट केही पठाउनुहोस्, त्यसपछि तपाईंले डिजाइन गरेको विफलता छुट्टै उत्पन्न गर्नुहोस्: म्यापिङको हकमा निष्क्रिय अवधि, पुनः जडानको हकमा पुनः सुरु वा ठेगाना परिवर्तन।
सिधा ट्राफिक रोक्नु छुट्टै निर्णय हो
पुनः जडान लुप पूर्ण स्वस्थ हुन सक्छ तर कुनै एपले चुपचाप सामान्य मार्ग प्रयोग गरिरहेको हुन्छ, र त्यो विफलता होइन, चुहावट हो। यदि टनेलबाहिर केही नजाओस् भन्ने शर्त हो भने, क्लाइन्ट कन्फिगरेसनमा स्पष्ट भन्नुहोस् र टनेल तल झारेर अझै के जोडिन्छ हेरेर प्रमाणित गर्नुहोस्। कुनै पनि मेकानिज्मले यो व्यवहार संकेत गर्दैन, र पुनः प्रयासको कुनै अनुशासनले यसलाई स्थापित गर्दैन।
कुन मेकानिज्म चल्यो र पछि नयाँ अनुरोध सफल भयो कि भएन लेख्नुहोस्। अर्को इन्जिनियरलाई यही दुई तथ्य चाहिन्छ, र दुवैमध्ये कुनै पनि स्टेटस आइकनमा देखिँदैन। क्लाइन्ट पुनः जडान भयो भन्ने लग लाइन र काम गरेको अनुरोध एउटै होइन।
नीति लेख्नुहोस्, केवल संख्या होइन
जोडीलाई एउटै वाक्यमा राख्नुहोस्: निष्क्रिय अन्तराल, जीवन्तताको सीमा, केले पुनर्निर्माण उत्पन्न गर्छ , र पुनः प्रयास गर्दा क्लाइन्टले के गर्छ। त्यो वाक्यबिना, हरेक भविष्यको घटनाले keepalive धेरै छोटो छ कि पुनः जडान धेरै ढिलो छ भन्ने उही बहस फेरि खोल्छ।
सीमाहरूबारे WireGuard का टिप्पणीहरू keepalive मध्यस्थ बाकसहरूका लागि वैकल्पिक मार्ग हो, सामान्य जीवन्तता डिजाइन होइन भन्ने उपयोगी सम्झना दिन्छन्। यसले समाधान गर्न नसक्ने समस्याको जवाफमा आवृत्ति बढाउनुअघि त्यो सीमा पढ्नुहोस्।