ทำไม DNS ของเราเตอร์เองจึงข้ามอุโมงค์ VPN?

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

การดักจับแพ็กเก็ตเป็นของเส้นทางไหนกันแน่

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

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

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

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

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

ทำไมเส้นทางนโยบายจึงไม่เคยเห็นคำถามที่สอง

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

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

ตัวแก้ไขชื่อของ pfSense ตัดสินเส้นทางต้นทางของตัวเองที่ใด

pfSense ทำให้การแยกนี้มองเห็นได้ ทราฟฟิกของไคลเอนต์สามารถกำหนดเส้นทางตามนโยบายผ่านเกตเวย์ VPN ขณะที่ทราฟฟิกของไฟร์วอลล์เองทำตามการตั้งค่าทางออกของตัวแก้ไขชื่อแทนกฎของ LAN ในอินเทอร์เฟซเว็บ การตั้งค่านั้นอยู่ใต้ Services > DNS Resolver > Outgoing Network Interfaces และค่าของมันคือรายการอินเทอร์เฟซที่ตัวแก้ไขชื่อใช้สอบถามต้นทางได้

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

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

เลือกพฤติกรรมเมื่อล้มเหลวก่อนตั้งค่า

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

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

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

ทดสอบทั้งสองเส้นทางและแยกผลลัพธ์ไว้

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

จากไคลเอนต์ LAN ให้ขอชื่อสาธารณะจากเราเตอร์ แล้วขอชื่อภายในที่เฉพาะโซนภายในของคุณควรตอบ การล้มเหลวเฉพาะคำถามที่สองชี้ไปที่การส่งต่อชื่อไม่ใช่อุโมงค์

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

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

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