ทำไมเส้นทาง VPN จึงไม่แสดงเกตเวย์ในผลลัพธ์ของ ip route
บรรทัดที่มีอุปกรณ์แต่ไม่มีเกตเวย์เป็นเส้นทางตรง ไม่ใช่เส้นทางที่เสีย อ่านปลายทาง dev และ scope แล้วยืนยันด้วย ip route get
ตารางเส้นทางมักถูกอ่านว่าพังทุกครั้งที่คอลัมน์เกตเวย์ว่างเปล่า ทั้งที่บรรทัดนั้นมักสมบูรณ์ในตัวเอง ฟิลด์ via ปรากฏเฉพาะเมื่อเคอร์เนลส่งแพ็กเก็ตไปยังที่อยู่ของฮ็อปถัดไป ส่วนเส้นทางที่ผูกกับอินเทอร์เฟซจะไปถึงปลายทางผ่านการแปลงที่อยู่ชั้นลิงก์หรือผ่านคู่ปลายทางแบบจุดต่อจุดแทน การอ่านคอลัมน์จากซ้ายไปขวาจะบอกว่าคุณอยู่ในกรณีใด และการอ่านนั้นควรเกิดขึ้นก่อนที่ใครจะแก้ไขเส้นทางเริ่มต้น ตั๋วส่วนใหญ่เกี่ยวกับเกตเวย์ที่หายไปจบลงที่ความแตกต่างนี้
อ่านบรรทัดเส้นทางทีละคอลัมน์
แต่ละรายการเริ่มด้วยปลายทางและความยาวพรีฟิกซ์ จากนั้นเพิ่มตัวปรับในคำศัพท์คงที่ ได้แก่ via, dev, proto, scope, src และ metric บรรทัดอย่าง 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 หนาแน่นแต่ระบุครบถ้วน ไม่มีอะไรขาดหายและไม่มีการสื่อถึงที่อยู่เราเตอร์ใด ๆ
ส่วนที่น่าสนใจคือการไม่มี via เมื่อไม่มีฮ็อปถัดไป เคอร์เนลจะแก้ปลายทางโดยตรงบนอินเทอร์เฟซที่ระบุ ซึ่งสำหรับอุโมงค์หมายถึงการส่งเฟรมให้อุปกรณ์อุโมงค์และปล่อยให้การห่อหุ้มจัดการต่อจากนั้น proto kernel บันทึกว่ารายการถูกติดตั้งโดยอัตโนมัติเมื่อมีการกำหนดที่อยู่ ไม่ใช่พิมพ์โดยผู้ดูแลระบบ scope link บอกว่าปลายทางเข้าถึงได้บนลิงก์นั้นโดยไม่ผ่านเราเตอร์ และ src ระบุที่อยู่ที่เคอร์เนลจะให้ความสำคัญในฐานะต้นทางสำหรับทราฟฟิกที่ตรงกัน
ตอนนี้อ่านเส้นทางเริ่มต้นด้วยวิธีเดียวกัน: default via 192.0.2.254 dev eth0 proto static metric 100 ที่นี่ via ปรากฏอยู่เพราะแพ็กเก็ตต้องการฮ็อปถัดไปจริง และฮ็อปนั้นเองก็ต้องเข้าถึงได้บน eth0 ทั้งสองบรรทัดไม่ใช่รูปแบบย่อยของกันและกัน แต่ตอบคำถามต่างกันเกี่ยวกับทราฟฟิกที่จะไปที่ใด
เส้นทางสองรูปแบบที่มักถูกสับสน
เส้นทางซับเน็ตของอุโมงค์และเส้นทางเริ่มต้นดูคล้ายกันในภาพหน้าจอแต่ทำงานต่างกันอย่างสิ้นเชิง ใช้ตารางด้านล่างเป็นตัวช่วยอ่านฟิลด์ แล้วยืนยันตัวเลขจริงบนเครื่องที่คุณกำลังดีบักแทนที่จะเชื่อตัวอย่างจากคู่มือ
| Piece of the line | What it settles | What it says nothing about |
|---|---|---|
| The destination and mask | Which packets are eligible to match | Where those packets leave the host |
via plus its address | Which next hop receives them, and therefore that a router is involved | Whether that router is reachable or sane |
dev | Which interface carries the encapsulated or raw packet | Whether the interface is up or has a carrier |
proto and scope | Who installed the entry and how far the destination is considered to be | Whether a firewall later drops the traffic |
สิ่งที่ตารางบอกคุณไม่ได้คือเจตนา เส้นทางตรงไปยังช่วงส่วนตัวผ่านอุโมงค์เป็นการออกแบบอุโมงค์แยกโดยเจตนา รูปแบบเดียวกันที่ปรากฏบนโฮสต์ซึ่งควรส่งทุกอย่างผ่าน VPN คืออาการ เจตนาอาศัยอยู่ในคอนฟิกูเรชันที่สร้างรายการนั้น ดังนั้นดูกเครื่องมือที่ติดตั้งมันก่อนสรุปว่าเคอร์เนลทำอะไรผิด
เช่นเดียวกัน เกตเวย์ที่หายไปไม่ใช่การอนุญาตให้คิดค้นขึ้นมา ถ้าเส้นทางต้องการฮ็อปถัดไปจริง ๆ ฮ็อปนั้นต้องเข้าถึงได้บนอินเทอร์เฟซที่พามันไป และสำหรับอุโมงค์แบบจุดต่อจุด ที่อยู่ของคู่ปลายทางไม่ใช่วัตถุเดียวกับที่อยู่ภายใน เคารพที่อยู่ภายในของอุโมงค์เป็นเราเตอร์อีเทอร์เน็ตเป็นวิธีทั่วไปที่ทำให้ได้เส้นทางที่ดูถูกต้องแต่ไม่ส่งอะไรเลย
ถามเคอร์เนลว่าจะใช้บรรทัดใดจริง ๆ
การอ่านตารางไม่เหมือนกับการค้นหาจริง เพราะเคอร์เนลตรวจสอบกฎนโยบาย ตารางหลายตาราง และรายการที่แคชไว้ก่อนจะตอบ คำกริยาที่ทำการค้นหาจริงคือ ip route get และมันพิมพ์เส้นทางที่แพ็กเก็ตที่มีคุณสมบัติเหล่านั้นจะใช้
ip route get 203.0.113.37 from 198.51.100.2 iif tun0แทนที่ด้วยปลายทางที่คุณสนใจจริง ๆ จากนั้นเพิ่ม from หรือ iif เมื่อทราฟฟิกถูกเลือกตามต้นทางหรือถูกส่งต่อ เพราะการค้นหาโลคอลทั่วไปอาจเลือกเส้นทางที่ต่างจากไคลเอนต์ที่ถูกส่งต่อ คำตอบระบุอินเทอร์เฟซ ที่อยู่ต้นทางที่เลือก และฮ็อปถัดไปใด ๆ ซึ่งเป็นข้อมูลเดียวกับที่แพ็กเก็ตจะถูกกำหนดเส้นทางในขณะนั้น
ถ้าคำตอบทำให้คุณประหลาดใจ ให้พิมพ์กฎก่อนเปลี่ยนแปลงสิ่งใด: ip -4 rule show แสดงรายการตามลำดับความสำคัญ และไคลเอนต์ VPN ที่ติดตั้งตารางของตัวเองหรือกฎสำหรับแพ็กเก็ตที่ทำเครื่องหมายจะไม่ปรากฏในตารางหลักเลย การแสดงรายการทุกตารางจะปิดช่องว่างนั้น
ip -4 route show table all | grep -E 'tun|default'ตรวจสอบชั้นล่างก่อนแทนที่เส้นทางเริ่มต้น
แพ็กเก็ตของอุโมงค์เองต้องไปถึงปลายทางระยะไกล และทำเช่นนั้นผ่านอินเทอร์เฟซทางกายภาพโดยใช้เส้นทางที่มีอยู่ก่อนที่ VPN จะขึ้น การแทนที่เส้นทางเริ่มต้นทั้งหมดโดยไม่ปักหมุดปลายทางนั้นจะส่งแพ็กเก็ตที่ห่อหุ้มแล้วเข้าไปในอุโมงค์ที่มันควรสร้าง และการเชื่อมต่อจะพังทลาย ยืนยันเส้นทางไปยังปลายทางก่อนด้วยการค้นหาเฉพาะที่อยู่ปลายทาง
แยกสามสิ่งออกจากกันเมื่อทำการเปลี่ยนแปลง: เส้นทางไปยังปลายทางที่ต้องอยู่บนอินเทอร์เฟซทางกายภาพ ช่วงส่วนตัวที่ควรเข้าไปในอุโมงค์ และค่าเริ่มต้นที่ตัดสินใจทุกอย่างอื่น แยกมันตามลำดับนั้น ใช้ทีละอย่าง และรันการค้นหาอีกครั้งหลังจากแต่ละขั้นตอน ping ที่ล้มเหลวหลังจากนั้นพิสูจน์ได้น้อยมากด้วยตัวเอง เพราะสิทธิ์ การกำหนดเส้นทางตอบกลับ DNS และบริการเองล้วนอยู่ปลายน้ำของเส้นทางที่ถูกต้อง
จดค่าสี่ค่าที่บรรทัดให้คุณก่อนแก้ไข: ปลายทาง ฮ็อปถัดไปหรือการไม่มีอยู่ อุปกรณ์ และต้นทางที่เลือก หากการเปลี่ยนแปลงในภายหลังย้ายค่าใดค่าหนึ่ง คุณจะรู้ว่าการตัดสินใจใดถูกเปลี่ยนจริง และสามารถกู้คืนรายการเดียวแทนการเดาทั้งตาราง