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