किल स्विच परीक्षण: केवल फिर से कनेक्ट नहीं, अंतराल नापें

एक सेकंड में पूरा होने वाला पुनःकनेक्शन कहता है कि क्लाइंट तेज़ है। यह नहीं कहता कि टनल बंद रहने के दौरान कुछ भाग गया या नहीं। एक मिनट लेने वाला पुनःकनेक्शन कहता है कि क्लाइंट धीमा है, और फिर भी नहीं कहता कि अंतराल में सीधा ट्रैफ़िक अनुमत था या नहीं। ये दो माप हैं, और जो किल स्विच परीक्षण केवल पहले की रिपोर्ट करता है उसने स्विच का परीक्षण नहीं किया।

दो अवलोकन, दो अलग निर्णय

उपलब्धता का प्रश्न सरल है: टनल फिर कब उपयोग योग्य हुई, और क्या संरक्षित अनुप्रयोग को वहाँ पहुँचने के लिए नया कनेक्शन चाहिए था। प्रवर्तन का प्रश्न भिन्न है: सुरक्षा गिरने के क्षण से लौटने के क्षण तक कौन से पैकेट मशीन से बाहर गए।

इनका उत्तर अलग रिकॉर्ड से दें। एक पंक्ति कहती है कि अंतराल निश्चित संख्या में सेकंड रहा। दूसरी पंक्ति कहती है कि उस अंतराल में कोई असुरक्षित अनुरोध सफल हुआ या नहीं। इन्हें एक ही पास या फ़ेल में मिला देना सबसे महत्वपूर्ण स्थिति छिपा देता है: रिसाव के साथ तेज़ पुनःकनेक्शन।

ऐसी प्रोब बनाएँ जिसका समय मापा जा सके

ऐसा अनुरोध इस्तेमाल करें जो हानिरहित, सस्ता और टनल के अपने नियंत्रण चैनल से स्वतंत्र है। नीचे का लूप हर सेकंड एक बार टाइमस्टैम्प, HTTP स्थिति और बीता समय छापता है, और अटकने के बजाय ज़ोर से विफल होता है:

while true; do
  printf '%s ' "$(date +%H:%M:%S)"
  curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 2 https://example.com || echo "curl-exit-$?"
  sleep 1
done

केवल स्थिति नहीं, curl के एग्ज़िट कोड पढ़ें। 28 का अर्थ है अनुरोध का समय समाप्त हो गया, अवरुद्ध मार्ग ऐसा ही दिखता है। 6 का अर्थ है नाम विश्लेषण विफल रहा, जो अलग निष्कर्ष है और अक्सर अधिक दिलचस्प। अंतराल के दौरान कम बीते समय के साथ 200 का अर्थ है ट्रैफ़िक को बाहर जाने दिया गया।

आउटपुट को फ़ाइल में लिखें और रखें। टर्मिनल का स्क्रॉलबैक प्रमाण नहीं है, और दिलचस्प हिस्सा आमतौर पर बीच की तीन पंक्तियाँ होती हैं।

असली विफलता पैदा करें, सुव्यवस्थित नहीं

क्लाइंट के अपने मेनू से डिस्कनेक्ट करना सहयोगी मार्ग का परीक्षण करता है, जहाँ क्लाइंट के पास अपने अवरोधन नियम स्थापित करने का समय होता है। इसके बजाय प्रक्रिया को मारें, या नीचे का लिंक तोड़ें, तब आप उस मार्ग का परीक्षण करते हैं जो असली विफलता लेती है।

हर ट्रिगर अलग कोड मार्ग का अभ्यास कराता है। सर्वर पक्ष की गड़बड़ी, स्थानीय लिंक का नुकसान और क्लाइंट क्रैश में से हर एक अलग स्थिति छोड़ सकता है, और उनमें से एक संभवतः वही स्थिति है जिससे आप अंततः मिलेंगे। प्रोब को कम से कम दो ट्रिगर पर चलाएँ और परिणामों को ट्रिगर के अनुसार लेबल करें।

अनुमत ट्रैफ़िक कैसा दिखता है, यह जानने के लिए लॉग पढ़ें

अंतराल के दौरान 200 या तेज़ कनेक्शन विफलता रिसाव है, चाहे वह किसी भी दिशा में हो। पूरे अंतराल में समय समाप्त होना अवरोधन नीति का अपेक्षित रूप है। कनेक्शन विफल होते समय नाम विश्लेषण का सफल होना बताता है कि रिज़ॉल्वर अभी भी पहुँच योग्य है, जो दूसरे प्रकार का रिसाव है।

मौजूदा सॉकेट को सावधानी चाहिए। कोई प्रोग्राम डिस्कनेक्ट से पहले खोला गया कनेक्शन इस्तेमाल करता रह सकता है, इसलिए दिखने में जीवित ट्रैफ़िक यह साबित नहीं कर सकता कि नया मार्ग अनुमत था। सॉकेट सूची दिखाती है कि कनेक्शन घटना से पुराना है या नहीं:

ss -tunp | grep -E 'ESTAB|SYN-SENT'
ip route get 198.51.100.7
resolvectl status | sed -n '1,20p'

सॉकेट के शुरू होने का समय डिस्कनेक्ट के टाइमस्टैम्प से तुलना करें। गड़बड़ी से पुराना कनेक्शन सॉकेट के पुनःउपयोग का प्रमाण है, रिसाव का नहीं, और इसे विफलता बताना अगले व्यक्ति को ऐसी बग खोजने भेजता है जो मौजूद ही नहीं है।

परिणाम को ऐसे रूप में दर्ज करें जो अपडेट के बाद भी टिके

ट्रिगर, सेकंड में अंतराल, क्या कोई अनवरुद्ध अनुरोध सफल हुआ, क्या नाम विश्लेषण सफल हुआ, और क्लाइंट तथा ऑपरेटिंग सिस्टम के संस्करण लिखें। पाँच तथ्यों का यह समूह संस्करणों के बीच तुलना योग्य है, जो एक गद्य अनुच्छेद नहीं कर सकता।

क्लाइंट अपडेट या प्रोफ़ाइल बदलाव के बाद वही परीक्षण दोबारा चलाएँ, क्योंकि अवरोधन व्यवहार कार्यान्वयन का विवरण है और वह बदलता रहता है। रिकॉर्ड का उद्देश्य बदलाव को घटना बनने से पहले नोटिस करना है, क्लाइंट को एक बार प्रमाणित करना नहीं।