keepalive पुन्हा कनेक्ट नाही: तुमच्याकडे असलेल्या बिघाडानुसार निवडा

keepalive आणि पुन्हा कनेक्ट एकाच श्वासात संरचित होतात पण वेगवेगळ्या समस्या सोडवतात, म्हणून एकाचे ट्यूनिंग दुसरे क्वचितच दुरुस्त करते। keepalive थोड्या रहदारीने स्टेट नोंद जिवंत ठेवते किंवा सहकारीाने उत्तर देणे थांबवले हे लक्षात घेते। पुन्हा कनेक्ट तुटलेले पाडून संबंध पुन्हा बांधते, ज्यात किल्ली, पत्ते आणि मार्ग यांचा समावेश आहे। बिघाडाशी जुळणारी यंत्रणा निवडा, जिचा नॉब तुम्हाला आधीच माहीत आहे ती नाही। दोन प्रश्न हे ठरवतात: मार्ग मेला आहे का, की सहकाऱ्यांमधले काही तो विसरत आहे?

जेव्हा मॅपिंग हीच समस्या असते

काही मिनिटांच्या शांततेनंतरच मरणारा टनेल सहसा सहकाऱ्याला नाही तर भाषांतर नोंद गमावतो। WireGuard चा PersistentKeepalive NAT आणि फायरवॉल स्टेटसाठी आहे, आणि प्रकल्पाच्या स्वतःच्या नोंदी त्याचे नेमके असेच वर्णन करतात, आरोग्य तपासणी म्हणून नाही। काही दहा सेकंदांचा अंतराल नोंद उबदार ठेवतो, तर दर सेकंदाला एक पॅकेट बॅटरीचा निर्णय आहे, विश्वासार्हतेचा नाही। OpenVPN त्याच ठिकाणी पोहोचतो ping आणि ping-restart मार्गे, जे आधी शांतता लक्षात घेतात आणि नंतर त्यावर कृती करतात।

हे सेटिंग्ज प्रोटोकॉलमध्येही बदलता येत नाहीत। IKEv2 चे मृत सहकारी धोरण, OpenVPN चा ping टाइमर आणि WireGuard चा keepalive एकाच प्रश्नाचे उत्तर तीन वेगळ्या सिंटॅक्स आणि तीन वेगळ्या डीफॉल्टसह देतात, म्हणून त्यांच्यात संख्या कॉपी करणे म्हणजे ट्यूनिंगच्या वेशातील अंदाज।

जेव्हा संबंध गेला असतो

सहकारी पत्ता बदलला, क्रेडेन्शियलची मुदत संपली किंवा दूरचे टोक रीस्टार्ट झाले, तर छोटे पॅकेट दुरुस्ती नाहीत। पुन्हा कनेक्टने स्टेट पुन्हा बांधले पाहिजे : पत्ता घ्या, मार्ग पुन्हा इन्स्टॉल करा, किल्ल्या पुन्हा वाटाघाटी करा आणि काही डिप्लॉयमेंटमध्ये वापरकर्त्याचे पुन्हा प्रमाणीकरण करा।

देखरेखीशिवाय पुन्हा कनेक्ट होणारे क्लायंट प्रमाणपत्र किंवा साठवलेले रहस्य ठेवतात। माणसाला विचारणारा क्लायंट कोणीही नसतानाच अयशस्वी होतो, आणि हीच ती परिस्थिती जिथे पुन्हा कनेक्ट महत्त्वाचे होते। हा महिन्यांपूर्वी घेतलेला डिझाइन निर्णय आहे, आउटेजमध्ये बदलता येणारे सेटिंग नाही।

दोन्हीपैकी काहीही सिद्ध होत नाही

टनेल पुन्हा कनेक्ट, किल्ली आणि मार्गांसह असू शकतो पण त्यामागील सेवा बंद असते, आणि keepalive सेशनसाठी मॅपिंग उघडे ठेवू शकतो ज्याचा सर्व्हर तासांपूर्वी गेला आहे। तुम्हाला खरोखर महत्त्वाची गोष्ट उपलब्ध नसताना दोन्ही यंत्रणा यश नोंदवू शकतात।

म्हणून चाचणी खऱ्या विनंतीवर संपते। तुम्हाला महत्त्वाच्या अंतरालानंतर टनेलमधून काही पाठवा, नंतर तुम्ही रचलेला बिघाड वेगळा घडवा: मॅपिंगच्या बाबतीत निष्क्रिय कालावधी, पुन्हा कनेक्टच्या बाबतीत रीस्टार्ट किंवा पत्ता बदल।

थेट रहदारी अडवणे वेगळा निर्णय आहे

पुन्हा कनेक्टचा लूप पूर्णपणे निरोगी असू शकतो पण एखादे ॲप गुपचूप सामान्य मार्ग वापरत असते, आणि ही बिघाड नसून गळती आहे। टनेलबाहेर काहीही जाऊ नये ही अट असेल, तर क्लायंट कॉन्फिगरेशनमध्ये ते स्पष्ट सांगा आणि टनेल खाली उतरवून काय अजून कनेक्ट होते हे पाहून सिद्ध करा। दोन्हीपैकी कोणतीही यंत्रणा हे वर्तन सूचित करत नाही, आणि पुनर्प्रयत्नाचे कोणतेही शिस्त ते प्रस्थापित करत नाही।

कोणती यंत्रणा चालली आणि नंतर नवीन विनंती यशस्वी झाली का ते नोंदवा। पुढील अभियंत्याला याच दोन तथ्यांची गरज असते, आणि दोन्हीपैकी एकही स्टेटस चिन्हात दिसत नाही। क्लायंट पुन्हा कनेक्ट झाला अशी लॉग ओळ आणि काम केलेली विनंती सारखी नाही।

धोरण लिहा, फक्त संख्या नाही

जोडी एका वाक्यात ठेवा: निष्क्रिय अंतराल, जिवंतपणाची मर्यादा, काय पुनर्बांधणी घडवते , आणि पुनर्प्रयत्न करताना क्लायंट काय करतो। त्या वाक्याशिवाय प्रत्येक भविष्यातील घटना keepalive खूप लहान आहे की पुन्हा कनेक्ट खूप संथ आहे हा तोच वाद पुन्हा उघडते।

मर्यादांबद्दल WireGuard च्या नोंदी keepalive हा मध्यवर्ती पेट्यांसाठीचा पर्यायी मार्ग आहे, सामान्य जिवंतपणाची रचना नाही याची उपयुक्त आठवण करून देतात। तो सोडवू शकत नाही अशा समस्येला प्रतिसाद म्हणून वारंवारता वाढवण्यापूर्वी ती मर्यादा वाचा।