openconnect ถูกฆ่า: เส้นทางและ DNS ยังชี้ไปที่อุโมงค์

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

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

เริ่มจากโปรเซส ไม่ใช่การกำหนดค่า

เปิดเทอร์มินัลแล้วถามว่าอะไรยังทำงานอยู่ก่อนแตะเส้นทางpgrep -a openconnectแสดงรายการทุกอินสแตนซ์พร้อมอาร์กิวเมนต์ ซึ่งแสดงไฟล์ pid และสคริปต์ที่ได้รับ โปรเซสที่คุณไม่ได้คาดคิดจะอธิบายอุโมงค์ผีได้เร็วกว่าบันทึกใด ๆ

ถ้าไม่มีอะไรทำงาน ให้ดูลิงก์ip link show tun0บอกว่าอินเทอร์เฟซรอดชีวิตหรือไม่ และip route show dev tun0แสดงเส้นทางที่ยังผูกอยู่กับมัน จากนั้นตรวจสอบ resolver ด้วยresolvectl statusบันทึกผลลัพธ์ทั้งสามก่อนแก้ไข เพราะบันทึกนั้นคือวิธีที่คุณจะแยกรายการเก่าออกจากรายการใหม่ในภายหลัง

อินเทอร์เฟซที่หายไปมักพาเส้นทางของมันไปด้วย เส้นทางที่อยู่รอดหลังลิงก์มักหมายความว่าโปรเซสยังมีชีวิตหรือไคลเอนต์ตัวที่สองเป็นเจ้าของอุปกรณ์

สคริปต์ตัวช่วยคือสิ่งที่ย้อนการเปลี่ยนแปลง

openconnect ไม่ได้ลบอินเทอร์เฟซ เส้นทาง หรือรายการ resolver ด้วยตัวเอง มันเรียกตัวช่วยภายนอก,/etc/vpnc/vpnc-scriptในการบิลด์ upstream และ/usr/share/vpnc-scripts/vpnc-scriptในแพ็กเกจ Debian และ Ubuntu ซึ่งเลือกด้วย-sสคริปต์เดียวกับที่ตั้งอุโมงค์ขึ้นคือตัวที่รื้อมันลง

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

สัญญาณใดที่ไปถึงเส้นทางนั้นเปลี่ยนไประหว่างเวอร์ชัน คู่มือ 7.06 ถือว่า SIGTERM เป็นการออกทันทีที่ข้ามสคริปต์ บิลด์ปัจจุบันระบุ INT และ TERM ว่าเป็นการหยุดอย่างสะอาด ซึ่งเซสชันถูกออกจากระบบและตัวช่วยทำงาน อ่านส่วน SIGNALS ของไบนารีที่คุณมีจริงแทนที่จะสันนิษฐานพฤติกรรมใดพฤติกรรมหนึ่ง

man openconnect | sed -n '/^SIGNALS/,/^LIMITATIONS/p'

ส่งสัญญาณที่บิลด์ของคุณระบุไว้

เมื่อรู้สัญญาณแล้ว ให้หยุดโปรเซสด้วย pid ไม่ใช่ด้วยรูปแบบ

pgrep -a openconnect
sudo kill -INT "$(cat /var/run/openconnect.pid)"

จากนั้นทำการตรวจสอบทั้งสามจากส่วนแรกซ้ำแทนที่จะเชื่อสถานะการออกip link show tun0ควรล้มเหลว,ip route show dev tun0ไม่ควรพิมพ์อะไรเลย และresolvectl statusไม่ควรแสดงรายการลิงก์ VPN อีก

SIGHUP ไม่ใช่ปุ่มหยุด: มันตัดการเชื่อมต่อ รันสคริปต์ และปล่อยให้เซสชันกลับมาต่อได้ด้วย--cookieSIGUSR2 บังคับให้เชื่อมต่อใหม่ทันที SIGKILL ข้ามการทำความสะอาดทั้งหมด และนั่นคือสถานะที่บทความนี้พูดถึง

ซ่อม resolver โดยไม่แทนที่ resolv.conf

ในระบบ Ubuntu ส่วนใหญ่/etc/resolv.confเป็นลิงก์สัญลักษณ์ไปยัง systemd-resolved ไม่ใช่ไฟล์ที่คุณควรแก้ไข การแทนที่มันทำให้การแปลงชื่อเสียสำหรับทุกเครือข่าย ไม่ใช่แค่ VPN ให้ลบการลงทะเบียนของอุโมงค์แทน:

resolvectl revert tun0
resolvectl query example.com

ถ้าระบบใช้ resolvconf แทน systemd-resolved บันทึกต่ออินเทอร์เฟซจะคงอยู่จนกว่าจะสั่งให้ปล่อยลิงก์ และresolvconf -d tun0คือการกระทำที่เทียบเท่า ตรวจสอบว่าใช้ resolver ตัวใดก่อนเลือกคำสั่ง

การค้นหาที่ยังเล็งไปยังเซิร์ฟเวอร์หลังลิงก์ที่ตายแล้วจะค้างจนหมดเวลา และความล่าช้านั้นดูเหมือนเซิร์ฟเวอร์ DNS ที่เสียมากกว่าเส้นทางที่เหลืออยู่

ทำให้การตัดการเชื่อมต่อครั้งถัดไปน่าเบื่อ

รักษาเส้นทางของไฟล์ pid ให้เหมือนเดิมทั้งตอนเริ่มและตอนปิด โดยส่ง--pid-fileทุกครั้ง หรือรัน openconnect ภายใต้ unitซึ่งKillSignalตรงกับสัญญาณที่เวอร์ชันของคุณระบุ การทดสอบในเบื้องหน้าก่อนจะแสดงข้อความปิดที่ตัวช่วยพิมพ์

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