पिंग वॉचडॉग टूटी सुरंग को स्वस्थ सुरंग से नहीं पहचान सकता

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

जाँच वह हिस्सा है जो बाकी सब तय करती है।

इंटरनेट पर पिंग वास्तव में क्या साबित करता है

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

त्रुटि की दोनों दिशाओं में से कोई भी निकास कोड में नहीं दिखती। उस संकेत पर बना वॉचडॉग cron समय-सारणी के साथ सिक्का उछालना है।

सुरंग के पीछे रहने वाली किसी चीज़ को जाँचें

ip -brief addr show tun0
ip route get 10.100.20.10
nc -z -w3 10.100.20.10 443

अंदर से जाँचें, सबसे सस्ती जाँच पहले। इंटरफ़ेस का होना बताता है कि सुरंग ऊपर है; किसी ज्ञात आंतरिक पते के लिए मार्ग खोज बताती है कि ट्रैफ़िक उसमें जाएगा; दूसरी ओर के होस्ट के लिए TCP जाँच बताती है कि वास्तव में कुछ उत्तर दे रहा है। केवल इको अनुरोध भ्रमित करते हैं: कई आंतरिक होस्ट खुशी से TCP का उत्तर देते हैं पर ICMP गिरा देते हैं, इसलिए पिंग पर बना वॉचडॉग ऐसी सुरंग को बार-बार फिर से जोड़ता है जिसने कभी काम करना बंद नहीं किया।

जाँच को समय में सीमित रखें और उसे अलग निकास स्थिति दें। जो जाँच तीस सेकंड लटकती है वह वॉचडॉग को अंतर्निहित देरी वाला कटौती-संसूचक बना देती है।

एक पंक्ति और लूप के बीच चुनें

* * * * * nc -z -w5 10.100.20.10 443 || myvpn reconnect

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

failures=0
while sleep 30; do
  if nc -z -w5 10.100.20.10 443; then failures=0
  else failures=$((failures+1)); fi
  if [ $failures -ge 3 ]; then myvpn reconnect; failures=0; fi
done

वह लूप किसी खिड़की पर अनुपात के बजाय लगातार विफलताएँ गिनता है। खिड़की को घड़ी और नमूनों की स्मृति चाहिए, और हाथ से बने वॉचडॉग की अधिकांश गलतियाँ उसी गणित में रहती हैं।

सर्वर बदलना एक अलग निर्णय है

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

पूर्ण सुरंग के अंदर से VPN सर्वर के अपने सार्वजनिक पते को न जाँचें। वह जाँच उसी चीज़ पर निर्भर है जिसका वह परीक्षण कर रही है, और सफलता बताती है जबकि जिस मार्ग को सत्यापित करना था वह जा चुका है।

नोट करें कौन सी जाँच चली, क्या लौटाया और कौन सा कदम उसके बाद आया। वह रिकॉर्ड रहस्यमय पुनः कनेक्शन को निदान-योग्य घटना बना देता है।