ตรวจสอบเส้นทาง VPN บน macOS: route get โดยไม่เปลี่ยนอะไร

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

ถามโฮสต์ที่ล้มเหลว ไม่ใช่เส้นทางเริ่มต้น

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

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

อ่านอินเทอร์เฟซและเกตเวย์เป็นหลักฐาน

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

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

เส้นทางที่ถูกต้องไม่ใช่คำขอที่ทำงานได้

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

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

แยกปลายทางออกจากทรัพยากร

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

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

อ่านก่อน เปลี่ยนทีหลัง

เก็บ route add และ route delete ไว้นอกการทำงานรอบแรก บน Mac ที่คุณดูแลจากระยะไกล การแก้ไขตารางครั้งเดียวอย่างไม่ระวังอาจตัดเส้นทางกลับไปยังเครื่องนั้น และไม่มีใครเหลืออยู่ให้ทำการวินิจฉัยให้เสร็จ ตัดสินใจว่าเส้นทางที่ถูกต้องคืออะไร จดวิธีเลิกทำการเปลี่ยนแปลง แล้วจึงรันมัน การตรวจสอบไม่ทิ้งหางแบบนั้น

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