ทำไมการตอบกลับ DNS จึงล้มเหลวที่ไฟร์วอลล์ขอบ VPN แบบไร้สถานะ

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

การแลกเปลี่ยนทั้งสองไม่ใช่การแลกเปลี่ยนเดียวกัน

เขียนทูเพิลออกมาแล้วข้อผิดพลาดก็ชัดเจน พอร์ตปลายทางของคำขอจะกลายเป็นพอร์ตต้นทางของการตอบกลับ ซึ่งตรงข้ามกับสิ่งที่คนส่วนใหญ่จินตนาการเมื่อเพิ่มกฎขาเข้าสำหรับพอร์ต 53:

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

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

ขอบไร้สถานะเทียบกับไฟร์วอลล์โฮสต์แบบมีสถานะ

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

การเปรียบเทียบมีความสำคัญเพราะอุปกรณ์ทั้งสองล้มเหลวต่างกัน ไฟร์วอลล์แบบมีสถานะที่ปฏิเสธการตอบกลับจะบันทึกการทิ้ง ส่วนขอบไร้สถานะปฏิเสธอย่างเงียบ ๆ ดังนั้นโฮสต์จึงหมดเวลาไปเฉย ๆ

สร้างการอนุญาตรอบโปรโตคอล ไม่ใช่รอบหมายเลขพอร์ต

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

จากนั้นยืนยันว่าผลิตภัณฑ์ใดในเส้นทางกรองทราฟฟิกจริง ขอบเขตขอบ IPv4 ที่มีเอกสารไม่ได้กำหนดนโยบาย IPv6 และทราฟฟิกภายในของผู้ให้บริการอาจไม่เคยผ่านตัวกรองเดียวกันเลย

ทำไมการอนุญาตพอร์ตต้นทาง 53 ใด ๆ ไม่ใช่การแก้ไข

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

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

ตรวจสอบที่ขอบที่ถูกต้อง ในทิศทางที่ถูกต้อง

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

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