VPN DNS กับ DoH ของเบราว์เซอร์: สิ่งที่การทดสอบการรั่วไหลบอกคุณไม่ได้
ที่อยู่จากการทดสอบการรั่วไหลบอกเพียงว่า resolver ตัวใดตอบกลับ คำขอที่เข้ารหัส DNS แบบแยกส่วน และนโยบายของเบราว์เซอร์เป็นตัวตัดสินว่าชื่อส่วนตัวยังคงถูกแปลงได้หรือไม่
หน้าการทดสอบการรั่วไหลบอกว่า DNS ของคุณปกติดี ป้ายในเบราว์เซอร์บอกว่าปลอดภัย แต่วิกิภายในยังโหลดไม่ขึ้น ทั้งสามอย่างเป็นจริงพร้อมกันได้ เพราะที่อยู่ของ resolver ไม่ใช่สิ่งเดียวกับนโยบายที่เลือกมัน หรือเส้นทางที่คำขอเดินทางไป สิ่งที่คนเรียกว่าการรั่วไหลของ DNS จริง ๆ แล้วเป็นคำถามเดียว: resolver ตัวใดได้รับชื่อ และการเลือกนั้นตั้งใจหรือไม่ การแยกแยะเรื่องนี้ต้องใช้การตรวจสามครั้ง และมีเพียงครั้งสุดท้ายที่ต้องเปลี่ยนการตั้งค่า
ความเชื่อผิดข้อหนึ่ง: ป้ายบอกชื่อ resolver ของคุณ
การทดสอบการรั่วไหลแปลงชื่อทดสอบแล้วรายงาน ที่อยู่ที่ตอบกลับ ไม่ได้รายงานนโยบายที่เลือก resolver นั้น และเมื่อคำขอถูกห่อด้วย DNS over HTTPS อุปกรณ์กลางทางก็มองไม่เห็นชื่อเลย เครื่องสองเครื่องที่ต่างกันมากให้ป้ายที่ทำให้อุ่นใจเหมือนกัน: เครื่องหนึ่งที่ VPN ผลัก 10.8.0.1 และเบราว์เซอร์ใช้มัน กับอีกเครื่องที่เบราว์เซอร์เพิกเฉยต่อรายการของระบบแล้วส่งชื่อไปยังผู้ให้บริการที่เข้ารหัสของตัวเองผ่านอุโมงค์
ความแตกต่างนี้สำคัญทันทีที่ชื่อส่วนตัวแปลงไม่ได้ ในการตั้งค่าแรก resolver ของ VPN ตอบสำหรับโซนองค์กร ในแบบที่สองเบราว์เซอร์ไม่เคยถามมันเลย ชื่อโฮสต์สั้นจึงแปลงไม่ได้ และความล้มเหลวดูเหมือน VPN เสีย การตรวจจึงไม่ใช่การทดสอบการรั่วไหลอีกครั้ง แต่คือการค้นชื่อที่ resolver เพียงตัวเดียวรู้จัก
ความเชื่อผิดข้อสอง: เบราว์เซอร์ออกจากอุโมงค์
DNS เลือกที่อยู่ การกำหนดเส้นทางพาการเชื่อมต่อไป และทั้งสองเป็นชั้นที่แยกจากกัน คำขอที่ส่งไปยังผู้ให้บริการ DoH สาธารณะยังคงเป็น TCP port 443 ไปยังที่อยู่ที่กำหนดเส้นทางได้ หากตารางเส้นทางของคุณส่งเส้นทางเริ่มต้นเข้าไปในอุโมงค์ คำขอนั้นก็ผ่านอุโมงค์ด้วย แบรนด์ของ resolver ไม่ได้ตัดสินเส้นทาง
สิ่งที่ DoH ในเบราว์เซอร์เปลี่ยนคือผู้รับของชื่อ นั่นเป็นการตัดสินใจเรื่องความเป็นส่วนตัวจริงและเป็นการตัดสินใจเชิงนโยบายจริง แต่ไม่ใช่การข้ามการกำหนดเส้นทาง หากข้อกำหนดของคุณคือให้ชื่ออยู่กับผู้ให้บริการ VPN คำขอที่เข้ารหัสไปยังคนอื่นจะล้มเหลวต่อข้อกำหนดนั้น ทั้งที่ยังใช้อุโมงค์สำหรับการเชื่อมต่อจริง
ความเชื่อผิดข้อสาม: ทุก VPN เขียนทับทุกเบราว์เซอร์
DNS ที่ปลอดภัยในเบราว์เซอร์มีโหมด ไม่ใช่สวิตช์: ปิด, ผู้ให้บริการเริ่มต้นที่มีทางถอย, เทมเพลตกำหนดเอง, หรือนโยบายที่ระบบปฏิบัติการหรือองค์กรบังคับใช้ กรณีทางถอยคือกรณีที่ทำให้เกิดรายงานเป็นระยะ เมื่อปลายทางที่เข้ารหัสเข้าถึงไม่ได้ เบราว์เซอร์อาจถอยกลับไปใช้ resolver ของระบบ แล็ปท็อปเครื่องเดียวกันจึงแปลงชื่อส่วนตัวได้ถูกต้องในวันจันทร์แต่ไม่ได้ในวันอังคาร
ในขณะเดียวกัน ไคลเอนต์ VPN ส่วนใหญ่ตั้ง resolver ของระบบเมื่อการเชื่อมต่อขึ้น และคืนค่าตัวก่อนหน้าเมื่อมันล่ม เบราว์เซอร์ที่ถือ resolver ที่เข้ารหัสแบบกำหนดเองไม่รับรู้การคืนค่านั้นเลย นี่คือเหตุผลที่โปรไฟล์เดียวกันทำงานต่างกันบนแล็ปท็อปสองเครื่อง และเหตุผลที่ resolv.conf ดูถูกต้องในขณะที่เบราว์เซอร์ยังถามคนอื่น
resolvectl status # per-link DNS servers and split-DNS domains
scutil --dns | head -30 # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1 # ask the VPN resolver directlyรันคำสั่งเหล่านั้นขณะเชื่อมต่ออยู่ บันทึกโดเมนที่ resolver แต่ละตัวอ้างสิทธิ์ และเปรียบเทียบกับสิ่งที่เบราว์เซอร์รายงานเกี่ยวกับโหมดของตัวเอง เอกสาร DoH ของ Mozilla เป็นคำอธิบายที่สมเหตุสมผลว่าพฤติกรรมเริ่มต้นและทางถอยของเบราว์เซอร์ควรทำงานอย่างไร
การตัดสินใจมีปัจจัยนำเข้าสามอย่าง ไม่ใช่หนึ่ง
ชื่อส่วนตัว ความไว้วางใจในผู้ให้บริการ และการเข้าถึงได้ เป็นตัวกำหนดการจัดวางที่ถูกต้อง ชื่อที่ resolver ของ VPN เท่านั้นรู้จักบังคับให้ใช้ DNS แบบแยกส่วน: ส่วนต่อท้ายส่วนตัวไปยัง resolver ที่ถูกผลักเข้ามา ส่วนอื่นทั้งหมดเป็นไปตามนโยบายที่คุณเลือกสำหรับชื่อสาธารณะ ความไว้วางใจในผู้ให้บริการกำหนดว่าชื่อสาธารณะควรไปยัง resolver นั้นด้วยหรือไปยังบริการแยก การเข้าถึงได้กำหนดว่า resolver ที่เข้ารหัสซึ่งคุณเลือกใช้ได้จริงบนเครือข่ายนี้หรือไม่
| Condition | What it forces |
|---|---|
| Internal names must resolve | Split DNS: private suffixes to the VPN resolver, the rest to your chosen default |
| Queries must stay with one operator | Pin both the system resolver and the browser mode, and disable fallback |
| Resolver only reachable through the tunnel | Keep the pushed resolver; do not point DoH at an endpoint your routes exclude |
ไม่มีแถวใดในการเหล่านี้เป็นการแนะนำสากล resolver ที่ VPN ดูแลรวบรวมการสังเกตไว้กับผู้ให้บริการรายนั้น บริการแยกเพิ่มผู้รับอีกหนึ่งรายของชื่อที่ถูกถาม ทั้งสองรูปแบบไม่พิสูจน์อะไรเกี่ยวกับการเก็บรักษา เว้นแต่คุณจะอ่านนโยบาย
เขียนการตัดสินใจลงไปตามโปรไฟล์ เพราะการตั้งค่าเหล่านี้เลื่อนไหว โปรไฟล์ที่ผลัก resolver เมื่อเดือนที่แล้วอาจไม่ผลักอะไรเลยวันนี้ และเบราว์เซอร์จะเก็บปลายทางกำหนดเองเก่าที่ยังตอบอยู่ไว้อย่างมีความสุข สิ่งที่ควรอยู่ในบันทึกคือที่อยู่ resolver ส่วนต่อท้ายที่มันถือครอง และโหมดของเบราว์เซอร์ ไม่ใช่แบรนด์ของบริการ
ทดสอบนโยบายที่คุณคิดว่าตั้งค่าไว้
ทดสอบด้วยชื่อ ไม่ใช่ด้วยป้าย แปลงชื่อสาธารณะและชื่อส่วนตัวผ่าน resolver ของระบบ แล้วทำซ้ำในเบราว์เซอร์ด้วยการตั้งค่า DNS ที่ปลอดภัยของมันในโหมดที่คุณตั้งใจจะใช้ หากชื่อส่วนตัวล้มเหลวเฉพาะในเบราว์เซอร์ คุณพบความไม่ตรงกันของผู้รับโดยไม่ต้องแตะการตั้งค่า VPN แม้แต่รายการเดียว
จากนั้นเชื่อมต่อใหม่และตรวจการคืนค่า เพราะนั่นคือที่อยู่ของบั๊กการส่งต่อ: ตัดการเชื่อมต่อ ยืนยันว่า resolver ก่อนหน้ากลับมา เชื่อมต่อใหม่ ยืนยันว่าตัวที่ถูกผลักกลับมา สุดท้าย ทดสอบเบราว์เซอร์ที่มีนโยบายแบบจัดการหากคุณมี เพราะโหมดนั้นอาจปฏิเสธการเปลี่ยนแปลงของคุณทั้งหมดและเก็บ resolver ก่อนหน้าไว้อย่างเงียบ ๆ
เริ่มจากคำถามเรื่องเนมสเปซ แล้วคุณจะหลีกเลี่ยงเรื่องเหล่านี้ได้เป็นส่วนใหญ่ หากเครื่องต้องเข้าถึงชื่อภายใน resolver ที่เข้ารหัสของเบราว์เซอร์เป็นการตัดสินใจเกี่ยวกับครึ่งสาธารณะเท่านั้น และครึ่งส่วนตัวยังอยู่กับสิ่งที่ VPN ผลักมา