Mengapa hotspot mengubah hala DNS sebelum VPN bersambung?
Hotspot menulis semula carian pada rangkaiannya sendiri, dan titik akhir nama hos diselesaikan sebelum mana-mana terowong wujud. Jejaki penyelesai mana yang menjawab setiap pertanyaan.
Menyertai rangkaian hotel meletakkan dua keputusan DNS di hadapan anda pada masa berbeza: carian yang dibuat peranti semasa log masuk, dan carian yang dibuat setelah terowong berdiri. Hotspot boleh mempengaruhi yang pertama melalui rangkaian yang dikawalnya. Yang kedua bergantung pada dasar klien itu sendiri, yang merupakan perkara berasingan untuk diperiksa.
Jejaki sambungan mengikut urutan, dari pajakan DHCP pertama hingga pertanyaan yang menyelesaikan nama peribadi. Dua kegagalan yang kelihatan serupa dalam tiket sokongan kemudian terpisah dengan jelas: satu berlaku sebelum terowong wujud, yang lain berlaku di dalamnya.
Apa yang hotspot boleh dan tidak boleh sentuh
Rangkaian akses mengagihkan alamat penyelesai dalam DHCP dan boleh memintas port 53 ke arah alamat itu. Itu cukup untuk menjawab setiap carian tidak dilindungi dengan alamat portal atau halaman sekatan. Itu juga cukup untuk memecahkan klien VPN yang titik akhirnya ditulis sebagai nama hos.
Apa yang hotspot tidak boleh lakukan ialah membaca atau menulis semula pertanyaan setelah ia bergerak di dalam terowong yang telah mantap, dengan andaian terowong itu benar-benar membawanya. Pemintasan bergantung pada melihat soalan dalam teks biasa.
Pertanyaan tetap meninggalkan terowong atas sebab yang tidak berkaitan dengan hotspot: tetapan DNS selamat pelayar, peraturan split-DNS yang mengekalkan akhiran korporat pada penyelesai setempat, atau klien yang dikonfigurasikan untuk mengecualikan DNS daripada terowong. Setiap satu ialah pilihan di pihak klien, dan setiap satu kelihatan seperti gangguan hotspot apabila dilihat dari luar.
| 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 |
Carian awal berlaku sebelum terowong wujud
Klien yang diberi nama hos mesti menyelesaikannya dahulu, dan pada saat itu tiada terowong melindungi pertanyaan. Jika hotspot menjawab dengan alamat portal, rundingan gagal atau tergantung. Jika ia tidak menjawab apa-apa, klien melaporkan ralat nama dan terowong tidak pernah bermula. Mana-mana daripada dua hasil itu menjelaskan log terowong kosong yang jika tidak kelihatan tidak bersalah.
Sistem pengendalian juga menjalankan pemeriksaan kesambungan dan penemuan portal mereka sendiri, yang diterangkan dalam RFC 8910 dan RFC 8952, dan permintaan itu keluar sebelum mana-mana VPN berdiri. Melihatnya dalam log proksi ialah tingkah laku yang dijangka, bukan bukti kebocoran.
Penyelesaian praktikal ialah memberi klien titik akhir yang tidak memerlukan carian. Apabila itu mustahil, selesaikan log masuk dahulu dan sambung selepas itu.
Ketahui penyelesai mana yang menjawab
Tanya sistem dan bukan pelayar, dan jalankan pertanyaan dua kali: sekali melalui mana-mana penyelesai yang digunakan peranti sekarang, sekali terhadap alamat tetap.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Jawapan daripada arahan pertama yang berbeza daripada yang ketiga memberitahu anda bahawa penyelesai setempat memulangkan sesuatu yang lain, dan itulah yang dilakukan hotspot yang mengubah hala. Kegagalan daripada yang ketiga bersama kejayaan daripada yang pertama menunjuk ke portal: penyelesai setempat menyampaikan alamat log masuk sementara port 53 keluar dibuang. Tamat masa pada kedua-duanya bermaksud rangkaian membuang DNS sehingga pengesahan selesai.
Ulangi selepas bersambung dan bandingkan. Jawapan yang di-cache bertahan melalui peralihan, jadi kosongkan cache atau tanya nama baharu untuk pemerhatian kedua.
Kekalkan carian kemudian pada laluan yang anda maksudkan
Profil terowong penuh yang juga menangkap DNS ialah susunan paling mudah: setiap pertanyaan daripada setiap aplikasi pergi ke penyelesai yang ditolak terowong, dan rangkaian setempat hanya melihat trafik yang disulitkan. Buktikan dengan menyelesaikan nama dalaman dan nama awam selepas bersambung, kemudian membandingkan kedua-dua jawapan dengan apa yang dipulangkan penyelesai terowong itu sendiri.
Split-DNS memerlukan senarai domain yang ditulis dengan niat: akhiran korporat melalui terowong, semua yang lain secara setempat, dan tiada pertindihan antara keduanya.
DNS selamat pelayar berada di luar dasar itu, jadi jika ia mesti dimatikan supaya profil berkelakuan seperti yang dijangka, matikannya untuk profil itu dan bukan untuk mesin. Lakukan dalam tetapan pelayar, bukan dengan menyunting penyelesai sistem, supaya perubahan kelihatan lain kali. Catat jawapan, penyelesai dan peringkat sambungan dalam satu baris setiap ujian. Laporan yang mengatakan DNS gagal pada Wi-Fi hotel menggambarkan gejala dengan sekurang-kurangnya tiga punca berbeza.