เส้นทางถูกปฏิเสธเพราะบิตโฮสต์? หา prefix ที่ตั้งใจไว้

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

ตัวแยกวิเคราะห์กำลังบ่นเรื่องอะไรจริง ๆ

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

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

ทำตัวอย่างด้วยมือ

ลองอุโมงค์ที่ต้องไปถึง 172.20.130.0 ด้วยมาสก์ /20 มาสก์ /20 ยืมสี่บิตจากออกเต็ตที่สาม ดังนั้นออกเต็ตนั้นจึงนับเป็นขั้นละ 16 เท่านั้น: 0, 16, 32 และต่อไปจนถึง 240 ค่า 130 อยู่ระหว่าง 128 กับ 143 ซึ่งหมายความว่าเครือข่ายที่ล้อมรอบเริ่มที่ 172.20.128.0 ไม่ใช่ที่ 172.20.130.0 ที่ทำให้ออกเต็ตสุดท้ายเป็นศูนย์

เมื่อเขียนออกมา บล็อกวิ่งจาก 172.20.128.0 ถึง 172.20.143.255 และบรรจุที่อยู่ 4,096 รายการ การป้อนค่าเดียวกันให้ตัวแยกวิเคราะห์ที่ไม่เข้มงวดแสดงการแทนที่ที่มันจะทำให้ในนามของคุณ:

$ python3 -c "import ipaddress; n=ipaddress.ip_network('172.20.130.0/20', strict=False); print(n, n.num_addresses)"
172.20.128.0/20 4096

ตัดสินใจว่าคุณตั้งใจปลายทางใดจริง ๆ

บรรทัดที่ถูกปฏิเสธมักซ่อนหนึ่งในสามเจตนา และมีเพียงคุณเท่านั้นที่เลือกได้ หากอุโมงค์ต้องการทั้งบล็อก ให้เขียน 172.20.128.0/20 ซึ่งเป็นที่อยู่เครือข่ายตามแบบแผน หากอุโมงค์ต้องการเพียงส่วน 130 มาสก์ก็ผิด และ 172.20.130.0/24 คือรูปแบบที่ซื่อตรง หากเป้าหมายเป็นเครื่องเดียว เส้นทางโฮสต์ IPv4 คือ /32 และไม่มีการคำนวณมาสก์เข้ามาเกี่ยวข้อง

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

ทำไมการส่งต่อไม่เคยเป็นทางแก้

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

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

ตรวจสอบเส้นทางที่ติดตั้งและเส้นทางที่มันชนะ

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

ถามหาที่อยู่สมาชิกและอีกหนึ่งที่อยู่นอกบล็อก เพื่อให้การเปรียบเทียบมีความหมายไม่ใช่เพียงบรรทัดปลอบใจบรรทัดเดียว:

ip -4 route show 172.20.128.0/20
ip -4 route get 172.20.140.10
ip -4 route get 172.20.200.10

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