Mengapa hotspot mengalihkan DNS sebelum VPN terhubung?
Hotspot menulis ulang pencarian di jaringannya sendiri, dan titik akhir berupa nama host diselesaikan sebelum ada terowongan. Lacak resolver mana yang menjawab setiap kueri.
Bergabung ke jaringan hotel menempatkan dua keputusan DNS di depan Anda pada saat berbeda: pencarian yang dilakukan perangkat saat masuk, dan pencarian yang dilakukan setelah terowongan berdiri. Hotspot dapat memengaruhi yang pertama melalui jaringan yang dikendalikannya. Yang kedua bergantung pada kebijakan klien itu sendiri, yang merupakan hal terpisah untuk diperiksa.
Telusuri koneksi secara berurutan, dari sewa DHCP pertama hingga kueri yang menyelesaikan nama privat. Dua kegagalan yang tampak identik dalam tiket dukungan lalu terpisah dengan jelas: satu terjadi sebelum terowongan ada, yang lain terjadi di dalamnya.
Apa yang bisa dan tidak bisa disentuh hotspot
Jaringan akses membagikan alamat resolver melalui DHCP dan dapat mencegat port 53 menuju alamat itu. Itu cukup untuk menjawab setiap pencarian tanpa perlindungan dengan alamat portal atau halaman pemblokiran. Itu juga cukup untuk merusak klien VPN yang titik akhirnya ditulis sebagai nama host.
Yang tidak bisa dilakukan hotspot adalah membaca atau menulis ulang kueri setelah kueri itu berjalan di dalam terowongan yang sudah terbentuk, dengan asumsi terowongan itu benar-benar membawanya. Pencegatan bergantung pada melihat pertanyaannya dalam teks biasa.
Kueri tetap meninggalkan terowongan karena alasan yang tidak terkait hotspot: pengaturan DNS aman peramban, aturan split-DNS yang menahan sufiks korporat pada resolver lokal, atau klien yang dikonfigurasi untuk mengecualikan DNS dari terowongan. Masing-masing adalah pilihan di sisi klien, dan masing-masing tampak seperti gangguan hotspot bila 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 |
Pencarian awal terjadi sebelum terowongan ada
Klien yang diberi nama host harus menyelesaikannya lebih dulu, dan pada saat itu tidak ada terowongan yang melindungi kueri. Jika hotspot menjawab dengan alamat portal, negosiasi gagal atau menggantung. Jika menjawab dengan kosong, klien melaporkan kesalahan nama dan terowongan tidak pernah mulai. Salah satu dari kedua hasil itu menjelaskan log terowongan kosong yang jika tidak tampak tidak bersalah.
Sistem operasi juga menjalankan pemeriksaan konektivitas dan penemuan portalnya sendiri, yang dijelaskan dalam RFC 8910 dan RFC 8952, dan permintaan itu keluar sebelum VPN mana pun berdiri. Melihatnya di log proksi adalah perilaku yang diharapkan, bukan bukti kebocoran.
Perbaikan praktisnya adalah memberi klien titik akhir yang tidak memerlukan pencarian. Bila itu mustahil, selesaikan dulu proses masuk lalu hubungkan.
Cari tahu resolver mana yang menjawab
Tanyakan ke sistem, bukan ke peramban, dan jalankan kueri dua kali: sekali melalui resolver apa pun yang sedang dipakai perangkat, sekali terhadap alamat tetap.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Jawaban dari perintah pertama yang berbeda dari yang ketiga memberi tahu Anda bahwa resolver lokal mengembalikan sesuatu yang lain, yang memang dilakukan hotspot yang mengalihkan. Kegagalan dari yang ketiga disertai keberhasilan dari yang pertama menunjuk ke portal: resolver lokal menyajikan alamat masuk sementara port 53 keluar dibuang. Waktu habis pada keduanya berarti jaringan membuang DNS sampai autentikasi selesai.
Ulangi setelah terhubung dan bandingkan. Jawaban yang di-cache bertahan melewati transisi, jadi kosongkan cache atau tanyakan nama baru untuk pengamatan kedua.
Jaga pencarian berikutnya pada jalur yang Anda maksudkan
Profil terowongan penuh yang juga menangkap DNS adalah susunan paling sederhana: setiap kueri dari setiap aplikasi pergi ke resolver yang didorong terowongan, dan jaringan lokal hanya melihat lalu lintas terenkripsi. Buktikan dengan menyelesaikan nama internal dan nama publik setelah terhubung, lalu membandingkan kedua jawaban dengan apa yang dikembalikan resolver terowongan sendirian.
Split-DNS memerlukan daftar domain yang ditulis dengan sengaja: sufiks korporat melalui terowongan, semua yang lain secara lokal, dan tanpa tumpang tindih di antara keduanya.
DNS aman peramban berada di luar kebijakan itu, jadi jika harus mati agar profil berperilaku dapat diprediksi, matikan untuk profil itu, bukan untuk mesin. Lakukan di pengaturan peramban, bukan dengan menyunting resolver sistem, agar perubahannya terlihat lain kali. Catat jawaban, resolver, dan tahap koneksi dalam satu baris per uji. Laporan yang menyatakan DNS gagal di Wi-Fi hotel menggambarkan gejala dengan setidaknya tiga penyebab berbeda.