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

वॉचडॉग मदत करतो की हानी करतो हे तीन अटी ठरवतात: तपासणी काय वेगळे करू शकते, किती सलग अपयश कृतीला न्याय देते, आणि कृती पुन्हा जोडणे आहे की बदल। सार्वजनिक पत्त्यावर पिंग करणारी 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 सर्व्हरचा स्वतःचा सार्वजनिक पत्ता तपासू नका। ती तपासणी ज्याची चाचणी करत आहे त्यावरच अवलंबून आहे, आणि जो मार्ग सत्यापित करायचा होता तो गेल्यावरही यश नोंदवते।

कोणती तपासणी चालली, काय परत आले आणि कोणती कृती आली ते नोंदवा। ती नोंद रहस्यमय पुन्हा जोडणीचे निदान करण्यायोग्य घटनेत रूपांतर करते।