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

เริ่มจากถามเคอร์เนลว่าจะใช้อุปกรณ์ใด

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

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

ip route show default
ip route get 203.0.113.9

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

จากนั้นอ่านตัวแปลงชื่อตามลิงก์ ไม่ใช่ตามไฟล์

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

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

resolvectl status
resolvectl query app.internal.example

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

เส้นทางที่ล้าสมัยอยู่รอดจากการเปลี่ยนแปลงได้อย่างไร

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

โปรไฟล์ VPN ไม่ได้ยกตัวเองขึ้นมา ดังนั้นการจับคู่จึงสำคัญกว่าการตั้งค่าเชื่อมต่ออัตโนมัติของโปรไฟล์เองมาก

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

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

แยกแยะสถานะที่ล้าสมัยออกจากแม่ที่หายไป

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

การรีสตาร์ตซ่อนว่าคุณมีสถานะใดในสามสถานะ และนั่นคือเหตุผลที่มันรู้สึกเหมือนการซ่อม

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

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