ทำไม route -interface จึงไปไม่ถึงโฮสต์นอกลิงก์
แฟล็กอินเทอร์เฟซบอก macOS ว่าปลายทางอยู่บนสาย อะไรก็ตามที่อยู่ไกลกว่าลิงก์ท้องถิ่นต้องมีเกตเวย์ที่เข้าถึงได้ และอุโมงค์ก็ยังอาจปฏิเสธได้
route ยอมรับชื่ออินเทอร์เฟซ Wi-Fi ออกโดยไม่มีข้อโต้แย้ง และโฮสต์ยังคงเข้าถึงไม่ได้ ไม่มีอะไรเสียหาย ความสัมพันธ์ในเส้นทางนั้นผิดไปเลย: แฟล็กอินเทอร์เฟซบอกว่าปลายทางอยู่บนลิงก์ใด ไม่ได้บอกว่าเราเตอร์ตัวใดควรรับทราฟฟิกสำหรับปลายทางที่อยู่ที่อื่น คำสั่งสำเร็จเพราะถูกต้องตามไวยากรณ์ ไม่ใช่เพราะอธิบายเส้นทางที่ใช้งานได้
ความแตกต่างนั้นเป็นตัวตัดสินว่าเส้นทางยกเว้นข้าง VPN จะทำงานได้จริงหรือเพียงแค่ดูสมเหตุสมผล
อินเทอร์เฟซคือทางออก ฮ็อปถัดไปคือการส่งต่อ
บน Mac ที่มีที่อยู่ 192.168.50.20 และมีเราเตอร์ที่ 192.168.50.1 เครื่องอื่นบนลิงก์เดียวกันเข้าถึงได้โดยตรง เฟรมถูกกำหนดที่อยู่ไปยังเครื่องนั้นและวางบนสาย ไม่มีเราเตอร์เกี่ยวข้อง และเส้นทางที่จำกัดเฉพาะอินเทอร์เฟซก็แสดงออกมาเช่นนั้น เปลี่ยนปลายทางไกลเป็นโฮสต์ในอาคารอื่น แล้วคำสั่งเดิมก็ไม่มีความหมาย Mac ไม่มีที่อยู่ชั้นที่สองที่จะวางบนสาย จึงไม่มีอะไรให้แฟล็กอินเทอร์เฟซอธิบาย
ปลายทางนอกลิงก์นั้นต่างออกไป Mac ไม่สามารถวางเฟรมบนสายที่กำหนดที่อยู่ไปยังโฮสต์ซึ่งเข้าถึงไม่ได้ในชั้นที่สองได้ มันส่งแพ็กเก็ตต่อให้เราเตอร์ที่ทำได้ ดังนั้นเส้นทางจึงต้องมีเกตเวย์ และเกตเวย์เองก็ต้องเข้าถึงได้บนลิงก์ที่เชื่อมต่อ
การแฟล็กอินเทอร์เฟซสำหรับปลายทางนอกลิงก์บอก macOS ให้ถือว่าปลายทางนั้นอยู่บนสาย เคอร์เนลจึงแก้ที่อยู่ชั้นที่สองให้ไม่ได้ และแพ็กเก็ตถูกทิ้งโดยไม่มีอะไรที่เป็นประโยชน์ในข้อผิดพลาด
แฟล็กอินเทอร์เฟซอ้างอะไรจริง ๆ
เอกสารอ้างอิงเส้นทางของ Apple กำหนดรูปแบบอินเทอร์เฟซสำหรับปลายทางที่เข้าถึงได้โดยตรงโดยไม่มีตัวกลาง เป็นข้อความเกี่ยวกับแบบจำลองลิงก์ ไม่ใช่การเลือกว่าจะใช้อะแดปเตอร์ตัวใด การเข้าถึงโฮสต์อินเทอร์เน็ตผ่าน Wi-Fi ยังต้องมีเราเตอร์บนลิงก์ Wi-Fi นั้น และเส้นทางต้องระบุชื่อมัน
ขอบเขตอินเทอร์เฟซเป็นแอตทริบิวต์แยก มันเชื่อมเส้นทางกับอินเทอร์เฟซเฉพาะสำหรับการตัดสินใจเรื่องขอบเขต เช่น ที่อยู่ต้นทางใดใช้บังคับ แต่ไม่ได้สร้างการเข้าถึงสำหรับปลายทางที่อินเทอร์เฟซเองเข้าถึงไม่ได้ แอตทริบิวต์ทั้งสองตอบคำถามต่างกัน
นี่คือเหตุผลที่คำสั่งอาจถูกยอมรับ ปรากฏในตาราง และยังล้มเหลว เคอร์เนลไม่ได้ตรวจสอบเจตนาของคุณ มันบันทึกสิ่งที่คุณอ้าง และข้ออ้างคือปลายทางอยู่บนลิงก์ ความสำเร็จอย่างเงียบ ๆ ตามด้วยการทิ้งอย่างเงียบ ๆ คือผลลัพธ์ที่คาดไว้ ไม่ใช่บั๊ก อ่านข้ออ้างนั้นซ้ำให้ตัวเองฟังก่อนจะโทษเครือข่าย
เส้นทางที่ปลายทางนอกลิงก์ต้องการ
สำหรับเส้นทางที่อนุมัติไปยังที่อยู่เอกสารเช่น 198.51.100.25 ผ่านเราเตอร์ LAN ความสัมพันธ์ที่ตั้งใจคือปลายทาง ฮ็อปถัดไป 192.168.50.1 และอินเทอร์เฟซ LAN ที่ไปถึงฮ็อปถัดไปนั้น อินเทอร์เฟซถูกบอกเป็นนัยจากการค้นหาฮ็อปถัดไป ไม่ใช่ถูกบังคับโดยคำสั่งเส้นทาง
บน macOS การตรวจสอบแบบอ่านอย่างเดียวคือ route -n get 198.51.100.25 อ่านบรรทัดเกตเวย์และอินเทอร์เฟซร่วมกันและตรวจว่าเกตเวย์เป็นที่อยู่ที่ Mac เข้าถึงได้จริง เกตเวย์ในซับเน็ตอื่น หรือเกตเวย์ที่หายไปตั้งแต่การเปลี่ยนแปลงเครือข่ายครั้งล่าสุด จะสร้างเส้นทางที่ดูถูกต้องและไม่ส่งต่ออะไรเลย
อย่าฮาร์ดโค้ด en0 ในคำแนะนำถาวร ชื่ออินเทอร์เฟซเปลี่ยนไปตามอะแดปเตอร์ ด็อก และไคลเอนต์ VPN และเส้นทางที่ระบุชื่อผิดจะล้มเหลวในแบบที่อ่านผิดเป็นความผิดปกติของเครือข่ายที่กว้างกว่าได้ง่าย
อ่านตัวเลือกปัจจุบันก่อนจะแทนที่
ก่อนจะเพิ่มอะไร ให้ตรวจสอบว่าระบบเลือกอะไรไว้แล้วและเพราะอะไร เอาต์พุตนั้นบอกว่าทราฟฟิกผ่านอุโมงค์ ผ่านเราเตอร์ LAN หรือไปไหนไม่ได้ และให้เส้นฐานสำหรับเปรียบเทียบหลังการเปลี่ยนแปลง หากไม่มีคุณจะบอกไม่ได้ว่าเส้นทางใหม่มีผลหรือไม่
จากนั้นตรวจสอบตระกูลที่อยู่ เส้นทางที่เพิ่มสำหรับ IPv4 ไม่มีผลกับปลายทาง IPv6 และบริการที่แก้ได้ทั้งสองตระกูลอาจดูเข้าถึงได้เป็นช่วง ๆ ตารางเส้นทางและตัวแก้ชื่อตอบคำถามต่างกัน และทั้งสองต้องสอดคล้องกับเส้นทางที่ตั้งใจ
สุดท้าย จำไว้ว่าเส้นทางคือการเลือก ไม่ใช่การอนุญาต โปรไฟล์ VPN ที่จัดการหรือตัวกรองไคลเอนต์ยังห้ามเส้นทางตรงได้แม้ตารางชี้ไปที่มัน ดังนั้นทดสอบกับแอปพลิเคชันจริงแทนที่จะถือว่ารายการตารางที่สำเร็จคือจุดจบของการสอบสวน
อุโมงค์และนโยบายเปลี่ยนรูปทรง
อินเทอร์เฟซแบบจุดต่อจุดเป็นกรณีของตัวเอง อุโมงค์สามารถพาเส้นทางได้โดยไม่มีที่อยู่เกตเวย์แบบอีเทอร์เน็ต และนั่นไม่ผิดโดยอัตโนมัติ ใช้แบบจำลองลิงก์จริงของอินเทอร์เฟซ แทนที่จะขยายตัวอย่าง Wi-Fi ไปยังทุกรายการตารางที่คุณเห็น
สำหรับคำขอเปลี่ยนแปลง ให้เขียนปลายทาง เส้นทางเครือข่ายที่อนุมัติ เกตเวย์และอินเทอร์เฟซปัจจุบัน และใครที่คาดว่าจะดูแลข้อยกเว้น เจ้าของสำคัญเพราะเส้นทางครั้งเดียวที่พิมพ์ที่พรอมป์ไม่ใช่นโยบาย และการเชื่อมต่อใหม่ครั้งถัดไปจะลบมัน
หากข้อกำหนดคือเข้าถึงโฮสต์นี้ขณะ VPN เปิดอยู่ คำตอบที่ซื่อสัตย์มักเป็นเส้นทางโฮสต์เฉพาะผ่านเราเตอร์ท้องถิ่น ซึ่งติดตั้งโดยผู้จัดการเครือข่ายที่เป็นเจ้าของอินเทอร์เฟซ หากข้อกำหนดคือเข้าถึงอะไรก็ได้โดยตรง ข้อกำหนดเองต้องทบทวนนโยบายก่อนที่จะต้องใช้คำสั่งเส้นทาง