VPN บอกว่าเชื่อมต่อแล้ว แต่เส้นทางเริ่มต้นตายแล้ว

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

ชิ้นส่วนที่เก่าอยู่แล้วผิดตั้งแต่ก่อนคุณสังเกตเห็น การถอดสายเคเบิลเพียงทำให้มันมองเห็นได้

ถามเคอร์เนลว่าแพ็กเก็ตจะไปที่ไหน

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

เรียกการค้นหาสองครั้ง ครั้งหนึ่งสำหรับที่อยู่สาธารณะ และอีกครั้งสำหรับที่อยู่ภายใน เพราะนโยบายอุโมงค์แยกอาจส่งต่ออันหนึ่งอย่างซื่อสัตย์และทิ้งอีกอัน

ip route show default
ip route get 1.1.1.1
ip route get 10.20.30.40

ตัวแปลงชื่อก็เก็บลิงก์ที่ตายไว้เช่นกัน

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

resolvectl status
resolvectl query intranet.example.com

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

ซ่อมการลงทะเบียน ไม่ใช่ /etc/resolv.conf ในระบบ Ubuntu และ Fedora ปัจจุบัน เส้นทางนั้นเป็นลิงก์สัญลักษณ์ไปยังสถานะรันไทม์ของตัวแปลงชื่อ การแก้ไขจึงถูกเพิกเฉยหรือถูกเขียนทับในเหตุการณ์เครือข่ายครั้งถัดไป

VPN ไม่เคยเริ่มเอง

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

nmcli device status
nmcli connection show --active
nmcli connection up office-vpn

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

การอัปเกรดอาจทิ้งการตั้งค่าโดยไม่มีข้อความ

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

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

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

สามสถานะ สามวิธีซ่อมที่ต่างกัน

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

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