วอตช์ด็อกแบบ ping แยกไม่ออกระหว่างอุโมงค์ที่เสียกับอุโมงค์ที่ดี

เงื่อนไขสามข้อตัดสินว่าวอตช์ด็อกช่วยหรือทำร้าย: การตรวจแยกแยะอะไรได้บ้าง มีความล้มเหลวกี่ครั้งติดกันที่ทำให้การลงมือชอบธรรม และการลงมือนั้นคือการเชื่อมต่อใหม่หรือการสลับ บรรทัด cron ที่ ping ไปยังที่อยู่สาธารณะไม่ตอบข้อใดได้ดีเลย มันเชื่อมต่ออุโมงค์ที่ดีซ้ำและปล่อยอุโมงค์ที่เสียไว้อย่างนั้น และทำทั้งสองอย่างโดยไม่มีบันทึก การออกแบบที่ควรค่าแก่การเก็บไว้ทำให้ทางเลือกทั้งสามนี้ชัดเจน

การตรวจคือส่วนที่กำหนดทุกอย่างที่เหลือ

การ ping ไปยังอินเทอร์เน็ตพิสูจน์อะไรได้จริง

การ ping ไปยังรีโซลเวอร์สาธารณะแสดงว่าเส้นทางอินเทอร์เน็ตภายในยังมีชีวิต มันไม่ได้พิสูจน์ว่าอุโมงค์กำลังขนส่งข้อมูล และในโปรไฟล์อุโมงค์เต็มรูป ตัว ping เองก็เดินทางผ่านอุโมงค์ ดังนั้นคำตอบที่ดีกับอุโมงค์ที่เสียสามารถอยู่ร่วมกันได้ขณะที่ไคลเอนต์ยังส่งแพ็กเก็ตต่อ หากโปรไฟล์ส่งการค้นหาชื่อผ่านอุโมงค์ ความล้มเหลวของ DNS จะถูกอ่านว่าเป็นลิงก์ที่ตายแล้วและเริ่มการเชื่อมต่อใหม่ที่ไม่สามารถแก้ไขอะไรได้

ไม่มีทิศทางใดของข้อผิดพลาดปรากฏในรหัสออก วอตช์ด็อกที่สร้างบนสัญญาณนั้นคือการโยนเหรียญพร้อมตาราง cron.

ตรวจสิ่งที่อาศัยอยู่หลังอุโมงค์

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

ตรวจจากด้านใน การตรวจที่ถูกที่สุดก่อน หากมีอินเทอร์เฟซก็หมายความว่าอุโมงค์ขึ้นแล้ว การค้นหาเส้นทางไปยังที่อยู่ภายในที่รู้จักบอกว่าข้อมูลจะเข้าไปในนั้น การตรวจ TCP ไปยังโฮสต์อีกฝั่งบอกว่ามีบางอย่างตอบจริง คำขอ echo อย่างเดียวทำให้เข้าใจผิด โฮสต์ภายในจำนวนมากตอบ TCP ได้อย่างสบายใจแต่ทิ้ง ICMP ดังนั้นวอตช์ด็อกที่อิง ping จึงเชื่อมต่ออุโมงค์ที่ไม่เคยหยุดทำงานซ้ำแล้วซ้ำอีก

จำกัดเวลาการตรวจและให้สถานะออกแยกต่างหาก การตรวจที่ค้างสามสิบวินาทีเปลี่ยนวอตช์ด็อกให้เป็นตัวตรวจจับการขาดสัญญาณที่มีความล่าช้าในตัว

เลือกระหว่างบรรทัดเดียวกับลูป

* * * * * 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 เองจากภายในอุโมงค์เต็มรูป การตรวจนั้นขึ้นอยู่กับสิ่งที่มันกำลังทดสอบ และรายงานความสำเร็จขณะที่เส้นทางที่ควรตรวจสอบได้หายไปแล้ว

บันทึกว่าการตรวจใดทำงาน อะไรที่ถูกส่งคืน และการลงมือใดตามมา บันทึกนั้นเปลี่ยนการเชื่อมต่อใหม่ที่ลึกลับให้เป็นเหตุการณ์ที่วินิจฉัยได้