ที่อยู่ peer ของ PPP หรือปลายทาง VPN: อันไหนใส่ใน via

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

การอ่านหนึ่งบรรทัดของอินเทอร์เฟซสองแบบ

ลองใช้เซสชันที่อินเทอร์เฟซรายงาน inet 10.64.3.9 peer 10.64.3.1/32 การอ่านแบบซับเน็ตถือว่า 10.64.3.9 เป็นโฮสต์เดี่ยวบนเกาะ /32 แล้วมองหาเราเตอร์เพื่อไปถึงสิ่งใดก็ตามที่อยู่ถัดออกไป เนื่องจากที่อยู่อีกแห่งเดียวบนลิงก์คือ peer การอ่านนั้นจึงลงเอยด้วยการเสนอ 10.64.3.9 เองเป็นประตู ซึ่งเป็นเหตุผลแบบวงกลม

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

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

สิ่งที่เซสชันติดตั้งไว้แล้ว

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

ip -4 addr show dev ppp0
ip route show dev ppp0
ip route show table main | head -n 5

เส้นทางอุปกรณ์เช่น 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 ไม่มีประตูเพราะอินเทอร์เฟซเองคือเส้นทาง เส้นทางที่ระบุ peer ด้วย via เป็นวัตถุอื่นที่มีอายุต่างกัน และจะหายไปเมื่อเซสชันล่ม การคัดลอกแบบใดแบบหนึ่งลงตารางถาวรโดยไม่ตรวจสอบวิธีติดตั้งใหม่ คือสาเหตุปกติที่อุโมงค์ที่ทำงานอยู่สูญเสียเส้นทางหลังเชื่อมต่อใหม่

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

กฎและตารางเป็นการตัดสินใจคนละเรื่อง

การเลือกตารางกับการเติมข้อมูลเป็นขั้นตอนอิสระ และการเปรียบเทียบสำคัญตรงนี้เพราะสองอย่างนี้มักสับสนเวลาดีบัก กฎที่ส่งทราฟฟิกที่ทำเครื่องหมายไปยังตาราง 100 ไม่ทำอะไรเลยถ้าตาราง 100 ไม่มีเส้นทางที่ตรงกัน และตารางที่เติมครบดีก็เอื้อมไม่ถึงถ้าไม่มีกฎชี้ไปที่มัน

ครึ่งหนึ่งของเส้นทางเริ่มต้นไม่ใช่เส้นทางเริ่มต้น 0.0.0.0/1 เดียวครอบคลุมครึ่งล่างของพื้นที่ IPv4 ดังนั้นนโยบายที่ตั้งใจจับทุกอย่างจึงต้องมี 128.0.0.0/1 ที่เข้าคู่กันด้วย หรือ default จริง ๆ การอ่านคอนฟิกที่ทำงานได้แล้วคัดลอกครึ่งใดครึ่งหนึ่งคือวิธีที่ผู้คนลงเอยด้วยลูปเส้นทางที่พังเฉพาะปลายทางบางแห่ง

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

ถามการค้นหาด้วยคำถามที่แอปของคุณถาม

ip route get แปลงเส้นทาง ส่วน ip route show แสดงรายการที่เก็บไว้ และทั้งสองอย่างอาจไม่ตรงกันโดยไม่มีอันใดผิด รวมบริบทต้นทางไว้ด้วย เพราะกฎที่อิงต้นทางจะตรงกันก็ต่อเมื่อการค้นหามีต้นทางติดมาด้วย

ip route get 198.51.100.23 from 10.64.3.9
ip route get 198.51.100.23 from 10.64.3.9 iif ppp0
ip -4 rule show

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

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

จุดที่การเปรียบเทียบพลิก

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

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

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark

เลือกหว่างสองดีไซน์จากหลักฐาน: ถ้าแอปผูกกับที่อยู่ PPP กฎต้นทางบวกตารางที่เก็บเส้นทาง peer ก็เพียงพอ ถ้ากล่องส่งต่อให้ LAN ที่อยู่ข้างหลัง ต้องให้บริบทขาเข้าและเส้นทางขากลับตรงกันด้วย เมื่อไม่ตรงกัน ให้แก้ความเป็นเจ้าของเส้นทางแทนที่จะผ่อนการตรวจสอบทั้งเครื่อง