OpenWrt policy routing: ห่วงโซ่ที่ดัก DNS ภายในเครื่อง

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

สองโฟลว์ หนึ่งที่อยู่ของตัวแก้ไข

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

โฟลว์ที่สองไม่เคยมาถึงจากที่ใดเลย เราเตอร์สร้างมันขึ้นมา จึงไม่มีแพ็กเก็ตขาเข้าและไม่มีขั้นตอนการส่งต่อให้จับคู่

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

แพ็กเก็ตที่ถูกส่งต่อและที่สร้างขึ้นภายในเครื่องเข้าต่างกัน

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

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

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

เลือกห่วงโซ่ขาออก แล้วค่อยจำกัดการจับคู่

การแก้ไขคือผูกเจตนาเดียวกันกับห่วงโซ่ขาออกด้วย หรือย้ายกฎไปที่นั่นเมื่อสิ่งที่คุณสนใจคือคำค้นของเราเตอร์เอง ในการติดตั้ง OpenWrt ที่สร้างบนแพ็กเกจ policy routing นั่นหมายถึงการเลือก output แทน prerouting ในการตั้งค่าห่วงโซ่ของกฎ เก็บกฎทั้งสองไว้ถ้าทั้งสองกลุ่มต้องการความครอบคลุม

แล้วจำกัดสิ่งที่กฎจับคู่ ที่อยู่ตัวแก้ไขปลายทางบนพอร์ตที่ตัวแก้ไขใช้จริงเป็นการตัดสินใจที่เล็กกว่าการส่งทุกสิ่งที่เราเตอร์สร้างเข้าไปในอุโมงค์มาก

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

เก็บการขนส่งของอุโมงค์เองออกจากกฎ

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

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

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

ทดสอบทั้งสองกลุ่ม ไม่ใช่กลุ่มเดียว

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

ถือว่าผลลัพธ์เป็นสองการค้นพบ ไคลเอนต์ที่แก้ไขผ่านอุโมงค์ไม่ได้บอกอะไรเกี่ยวกับเราเตอร์ และเราเตอร์ที่แก้ไขถูกต้องก็ไม่ได้บอกอะไรเกี่ยวกับไคลเอนต์บนตัวรับฟังอื่น เขียนเป็นบรรทัดแยกกันในบันทึกการเปลี่ยนแปลง

ตรวจพอร์ตด้วย: กฎที่จับคู่พอร์ตปลายทาง 53 พลาดตัวแก้ไขที่เข้าถึงผ่าน DNS over TLS บน 853 หรือปลายทาง HTTPS จับคู่การขนส่งที่ upstream ที่กำหนดค่าไว้ใช้จริง และการรั่วไหลจะปิดลงด้วยเหตุผลที่ถูกต้อง