ทำไม DNS จึงหยุดทำงานหลังจาก OpenVPN เชื่อมต่อบน Windows

ping ไปยังตัวแปลงของออฟฟิศยังได้รับคำตอบแม้หลังจาก "OpenVPN" เชื่อมต่อแล้ว แต่การค้นหาชื่อทุกครั้งก็ล้มเหลว ที่อยู่เข้าถึงได้แต่พอร์ตไม่ ซึ่งเป็นสิ่งที่เข้าใจได้เมื่อรู้ว่า Windows กรอง DNS ตามอะแดปเตอร์ได้ หากมี block-outside-dns ในโปรไฟล์ ตัวกรองนั้นคือผู้ต้องสงสัยอันดับแรก และตารางเส้นทางคือที่ผิดในการค้นหา การทดสอบสองอย่างด้านล่างแยกชั้นเหล่านี้ออกจากกันภายในไม่กี่วินาที

ที่อยู่ที่เข้าถึงได้ พอร์ตที่ตายแล้ว

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

ping <resolver-ip>
nslookup <name> <resolver-ip>

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

ตัวเลือกนี้คือกฎของแพลตฟอร์มการกรอง

เอกสาร OpenVPN อธิบาย block-outside-dns ว่าเป็นข้อจำกัดของ Windows Filtering Platform ที่กันไม่ให้แอปพลิเคชันเข้าถึง DNS บนอะแดปเตอร์นอกอุโมงค์ ครอบคลุม TCP และ UDP พอร์ต 53 เนื่องจากตัวกรองอยู่ใน WFP ไม่ใช่ในรายการกฎไฟร์วอลล์ปกติ การเพิ่มกฎอนุญาตที่อื่นจึงไม่จำเป็นต้องเปลี่ยนผลลัพธ์ นี่คือเหตุผลที่คำแนะนำทั่วไปให้อนุญาต DNS ยังคงล้มเหลว

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

มองหาองค์ประกอบฝั่งไคลเอนต์ที่เป็นเจ้าของข้อจำกัดนี้แทนการเพิ่มกฎมากขึ้น เจ้าของคือสิ่งที่ถอดมันออกได้จริง

ตัวกรองไม่ใช่ตัวแปลง

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

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

1. ตัวแปลงที่ใช้อยู่: เปรียบเทียบ Resolve-DnsName -Server <resolver-ip> <name> กับเซิร์ฟเวอร์ DNS ที่ ipconfig /all แสดง
2. DNS ของ VPN ถูกใช้: ตรวจรายการ DNS ของอะแดปเตอร์อุโมงค์ในเอาต์พุตเดียวกันของ ipconfig /all
3. อินเทอร์เฟซที่ใช้: Find-NetRoute -RemoteIPAddress <resolver-ip> ระบุอินเทอร์เฟซขาออกสำหรับปลายทางนั้น

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

สิ่งที่ตัวเลือกนี้ไม่ครอบคลุม

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

มองความต่างนั้นเป็นการวินิจฉัยไม่ใช่ข้อขัดแย้ง เปรียบเทียบทั้งสองก่อนตัดสินว่าตัวแปลงของระบบเสีย

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

ตรวจสถานะก่อนและหลังตัดการเชื่อมต่อ

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

ipconfig /displaydns
nslookup <name> <resolver-ip>

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

หลังการตรวจเหล่านั้นเท่านั้นจึงสมเหตุสมผลที่จะเปลี่ยนตัวแปลงหรือสร้างนโยบายไฟร์วอลล์ใหม่ ทั้งสองเป็นการเปลี่ยนแปลงที่ใหญ่กว่าที่หลักฐานรองรับ