รักษาอุโมงค์ vpnc หลายเส้นให้ทำงานด้วยการตรวจสอบแยกตามโปรไฟล์

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

ให้พอร์ตโลคอลของตัวเองแก่ทุกโปรไฟล์

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

Local Port 0

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

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

ตรวจสอบบริการหนึ่งอย่างต่อโปรไฟล์ ไม่ใช่ที่อยู่อุโมงค์

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

ตรวจสอบบริการหนึ่งอย่างต่อโปรไฟล์ด้วยเวลาหมดอายุ TCP สั้น ๆ และเชื่อมต่อใหม่เฉพาะโปรไฟล์ที่การตรวจสอบล้มเหลว สองวินาทีแยกเส้นทางที่ตายออกจากเส้นทางที่ช้า และการตรวจสอบ TCP ไม่ขึ้นกับว่า ICMP ได้รับอนุญาตที่ใดที่หนึ่งตลอดเส้นทางหรือไม่ เปลี่ยนเฉพาะเป้าหมายและชื่อคอนฟิกระหว่างโปรไฟล์:

#!/bin/bash
set -eu
if ! nc -z -w 2 10.63.7.20 8443; then
  /usr/sbin/vpnc-connect ops.conf
fi

บันทึกสิ่งนั้นเป็น /usr/local/bin/ensure-vpn-ops.sh ทำให้เรียกใช้ได้ และทำซ้ำกับทุกโปรไฟล์โดยเปลี่ยนเฉพาะเป้าหมายการตรวจสอบและชื่อคอนฟิก การตรวจสอบที่ตอบคำถามเชิงโปรโตคอลอยู่รอดผ่านเกตเวย์ที่ทิ้งเอคโค่แต่ยังส่งต่อบริการที่ผู้ใช้ให้ความสำคัญ

เชื่อมการตรวจสอบเป็นสายโซ่เพื่อไม่ให้แย่งกัน

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

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

#!/bin/bash
sleep 20
/usr/local/bin/ensure-vpn-ops.sh
/usr/local/bin/ensure-vpn-lab.sh

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

เฝ้าดูล็อก แล้วจงใจทำพังหนึ่งตัว

บันทึกหนึ่งบรรทัดต่อการทำงาน พร้อมโปรไฟล์ เป้าหมายการตรวจสอบ ผลลัพธ์ และการดำเนินการที่ทำ หากไม่มีสิ่งนี้ อุโมงค์ที่กระพริบทุกนาทีจะดูเหมือนกับอุโมงค์ที่ไม่เคยล่มเลย และบั๊กของการตรวจสอบก็แยกจากเกตเวย์ขัดข้องไม่ได้ ล็อกยังพิสูจน์ด้วยว่าสายโซ่แตะเฉพาะโปรไฟล์ที่ล้มเหลว เขียนไว้ที่ที่อยู่รอดหลังรีบูต ไม่อย่างนั้นหลักฐานจะจากไปพร้อมโปรเซส

จากนั้นจงใจทำอุโมงค์หนึ่งพังและดูว่าเกิดอะไรขึ้น หยุดโปรไฟล์เดียวและยืนยันว่ามีโปรเซสและเส้นทางใดเหลืออยู่:

pgrep -a vpnc
ip -4 route show | grep -E '10[.]63|10[.]90'
tail -n 5 /var/log/ensure-vpn.log

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

สิ่งที่ตัวเฝ้าระวังต้องไม่ทำ

ตัวเฝ้าระวังที่รีสตาร์ตทุกอย่างเมื่อมีอะไรล้มเหลวดูแข็งแรงระหว่างการทดสอบ และก่อให้เกิดการหยุดให้บริการในหน้าต่างบำรุงรักษา ให้รีสตาร์ตแยกตามโปรไฟล์ ไม่ใช่ทั้งระบบ

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