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

อุโมงค์หายไปแล้ว แต่นโยบายยังอยู่

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

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

อ่านออบเจกต์ที่แพ็กเกจไม่เคยเป็นเจ้าของ

อ่านสถานะก่อนจะเปลี่ยนมัน แสดงรายการอุปกรณ์ การเชื่อมต่อที่ใช้งาน และตารางเส้นทางทั้งสองตาราง จากนั้นมองหาอุปกรณ์หลอกที่รายงานว่าต่ออยู่ หรือเส้นทางเริ่มต้นที่ชี้ไปที่มัน IPv4 และ IPv6 ล้มเหลวแยกกัน ดังนั้น ping ที่ได้ผลไปยังที่อยู่ซึ่งการแปลงชื่อเสียชี้ไปยังออบเจกต์อื่นที่ไม่ใช่เส้นทางที่ตายแล้ว อุปกรณ์หลอกที่ยึดเส้นทางเริ่มต้นอธิบายการล่มทั้งหมดได้ด้วยตัวเอง

nmcli device status
nmcli connection show --active
ip -4 route
ip -6 route

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

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

ลบโปรไฟล์ ไม่ใช่ไฟล์คีย์

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

sudo nmcli connection delete pvpn-killswitch
sudo systemctl restart NetworkManager

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

ตรวจฮุกตอนบูตก่อนที่มันจะเกิดซ้ำ

เศษบางอย่างติดตั้งตัวเองใหม่ทุกครั้งที่บูต ยูนิตที่เขียนด้วยมือหรือสคริปต์ if-up ที่เพิ่มกฎไฟร์วอลล์ยังทำเช่นนั้นต่อไปแม้แพ็กเกจจะหายไป การล่มจึงกลับมา และการซ่อมครั้งก่อนดูเหมือนโชค ค้นหาในไฟล์ยูนิตและฮุกเครือข่ายก่อนบูตอีกครั้ง ชื่อยูนิตมักเป็นตัวบอก

systemctl list-unit-files | grep -i vpn
grep -rl -i vpn /etc/systemd/system /etc/network/if-up.d

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

บทความที่เกี่ยวข้อง