ทำไมฮอตสปอตจึงเปลี่ยนเส้นทาง DNS ก่อนที่ VPN จะเชื่อมต่อ
ฮอตสปอตรีไรต์การค้นหาในเครือข่ายของตัวเอง และปลายทางที่เป็นชื่อโฮสต์จะถูกแก้ไขก่อนที่อุโมงค์ใด ๆ จะมีอยู่ ติดตามว่าตัวแก้ไขใดตอบคำถามแต่ละครั้ง
การเชื่อมต่อกับเครือข่ายโรงแรมวางการตัดสินใจ DNS สองอย่างไว้ตรงหน้าคุณในเวลาที่ต่างกัน คือการค้นหาที่อุปกรณ์ทำระหว่างลงชื่อเข้าใช้ และการค้นหาที่ทำหลังจากอุโมงค์ขึ้นแล้ว ฮอตสปอตสามารถมีอิทธิพลต่ออย่างแรกผ่านเครือข่ายที่มันควบคุม ส่วนอย่างที่สองขึ้นอยู่กับนโยบายของไคลเอนต์เอง ซึ่งเป็นเรื่องแยกที่ต้องตรวจสอบ
ไล่การเชื่อมต่อตามลำดับ ตั้งแต่การเช่า DHCP ครั้งแรกจนถึงคำถามที่แก้ชื่อส่วนตัว ความล้มเหลวสองอย่างที่ดูเหมือนกันในตั๋วสนับสนุนจะแยกออกจากกันชัดเจน อย่างหนึ่งเกิดก่อนมีอุโมงค์ อีกอย่างเกิดภายในอุโมงค์
สิ่งที่ฮอตสปอตแตะได้และแตะไม่ได้
เครือข่ายการเข้าถึงแจกจ่ายที่อยู่ตัวแก้ไขผ่าน DHCP และสามารถดักพอร์ต 53 ไปยังที่อยู่นั้นได้ เท่านี้ก็เพียงพอที่จะตอบทุกการค้นหาที่ไม่มีการป้องกันด้วยที่อยู่พอร์ทัลหรือหน้าบล็อก และยังเพียงพอที่จะทำให้ไคลเอนต์ VPN ที่เขียนปลายทางเป็นชื่อโฮสต์เสียหายด้วย
สิ่งที่ฮอตสปอตทำไม่ได้คืออ่านหรือเขียนคำถามใหม่เมื่อมันเดินทางอยู่ภายในอุโมงค์ที่สร้างขึ้นแล้ว โดยสมมติว่าอุโมงค์นั้นพามันจริง การดักนั้นขึ้นอยู่กับการเห็นคำถามในข้อความธรรมดา
คำถามออกจากอุโมงค์อยู่ดีด้วยเหตุผลที่ไม่เกี่ยวกับฮอตสปอต การตั้งค่า DNS ปลอดภัยของเบราว์เซอร์ กฎ split-DNS ที่เก็บส่วนต่อท้ายขององค์กรไว้ที่ตัวแก้ไขภายใน หรือไคลเอนต์ที่ตั้งค่าให้ยกเว้น DNS จากอุโมงค์ แต่ละอย่างเป็นการเลือกฝั่งไคลเอนต์ และแต่ละอย่างดูเหมือนการรบกวนของฮอตสปอตเมื่อมองจากภายนอก
| Path | Who answers | What a failure looks like |
|---|---|---|
| Lookup before the tunnel is up | The network's resolver | The client never reaches its endpoint |
| Lookup inside the tunnel | The resolver pushed by the client | Local policy or tunnel DNS is misconfigured |
| Browser secure DNS | A DoH provider over port 443 | Both the hotspot and the tunnel policy are bypassed |
การค้นหาครั้งแรกเกิดขึ้นก่อนที่อุโมงค์จะมีอยู่
ไคลเอนต์ที่ได้รับชื่อโฮสต์ต้องแก้ชื่อนั้นก่อน และในขณะนั้นไม่มีอุโมงค์ใดปกป้องคำถาม หากฮอตสปอตตอบด้วยที่อยู่พอร์ทัล การเจรจาจะล้มเหลวหรือค้าง หากตอบด้วยความว่างเปล่า ไคลเอนต์จะรายงานข้อผิดพลาดชื่อและอุโมงค์จะไม่เริ่มเลย ผลลัพธ์ทั้งสองอย่างอธิบายบันทึกอุโมงค์ว่างที่ดูเหมือนไม่มีพิษภัย
ระบบปฏิบัติการยังทำการตรวจสอบการเชื่อมต่อและการค้นหาพอร์ทัลของตัวเอง ซึ่งอธิบายไว้ใน RFC 8910 และ RFC 8952 และคำขอเหล่านั้นออกไปก่อนที่ VPN ใดจะขึ้น การเห็นสิ่งเหล่านั้นในบันทึกพร็อกซีเป็นพฤติกรรมที่คาดไว้ ไม่ใช่หลักฐานการรั่ว
วิธีแก้ที่ใช้ได้จริงคือให้ไคลเอนต์มีปลายทางที่ไม่ต้องค้นหา เมื่อทำไม่ได้ ให้ลงชื่อเข้าใช้ให้เสร็จก่อนแล้วค่อยเชื่อมต่อ
ค้นหาว่าตัวแก้ไขใดตอบ
ถามระบบไม่ใช่เบราว์เซอร์ และรันคำถามสองครั้ง ครั้งหนึ่งผ่านตัวแก้ไขที่อุปกรณ์ใช้อยู่ตอนนี้ อีกครั้งกับที่อยู่คงที่
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
คำตอบจากคำสั่งแรกที่ต่างจากคำสั่งที่สามบอกว่าตัวแก้ไขภายในตอบสิ่งอื่น ซึ่งเป็นสิ่งที่ฮอตสปอตที่เปลี่ยนเส้นทางทำ ความล้มเหลวจากคำสั่งที่สามพร้อมความสำเร็จจากคำสั่งแรกชี้ไปที่พอร์ทัล ตัวแก้ไขภายในให้ที่อยู่ลงชื่อเข้าใช้ ขณะที่พอร์ต 53 ขาออกถูกทิ้ง การหมดเวลาทั้งสองหมายความว่าเครือข่ายทิ้ง DNS จนกว่าการยืนยันตัวตนจะเสร็จ
ทำซ้ำหลังเชื่อมต่อและเปรียบเทียบ คำตอบที่แคชไว้จะอยู่รอดผ่านการเปลี่ยน ดังนั้นล้างแคชหรือถามชื่อใหม่สำหรับการสังเกตครั้งที่สอง
ทำให้การค้นหาต่อไปอยู่บนเส้นทางที่คุณตั้งใจ
โปรไฟล์อุโมงค์เต็มที่ดัก DNS ด้วยเป็นการจัดวางที่ง่ายที่สุด ทุกคำถามจากทุกแอปพลิเคชันไปยังตัวแก้ไขที่อุโมงค์ดันมา และเครือข่ายภายในเห็นเฉพาะการรับส่งที่เข้ารหัส พิสูจน์ได้โดยแก้ชื่อภายในและชื่อสาธารณะหลังเชื่อมต่อ แล้วเปรียบเทียบคำตอบทั้งสองกับสิ่งที่ตัวแก้ไขของอุโมงค์ตอบด้วยตัวเอง
split-DNS ต้องมีรายการโดเมนที่เขียนอย่างตั้งใจ ส่วนต่อท้ายขององค์กรผ่านอุโมงค์ ส่วนอื่นทั้งหมดภายใน และไม่ทับซ้อนกันระหว่างสองอย่าง
DNS ปลอดภัยของเบราว์เซอร์อยู่นอกนโยบายนั้น ดังนั้นหากต้องปิดเพื่อให้โปรไฟล์ทำงานตามที่คาดไว้ ให้ปิดสำหรับโปรไฟล์นั้นไม่ใช่ทั้งเครื่อง ทำในตั้งค่าเบราว์เซอร์ ไม่ใช่แก้ตัวแก้ไขของระบบ เพื่อให้เห็นการเปลี่ยนแปลงในครั้งถัดไป บันทึกคำตอบ ตัวแก้ไข และขั้นตอนการเชื่อมต่อในหนึ่งบรรทัดต่อการทดสอบ รายงานที่บอกว่า DNS ล้มเหลวบน Wi-Fi ของโรงแรมอธิบายอาการที่มีสาเหตุต่างกันอย่างน้อยสามอย่าง