DNS tidak terselesaikan saat kill switch VPN memblokir port 53
Kill switch bisa memblokir DNS dengan sengaja. Bandingkan resolusi hanya di dalam tunnel dengan pengecualian resolver lokal, lalu tentukan lapisan mana yang sebenarnya gagal.
Saat kill switch menjatuhkan tunnel, ia ikut membawa jalur DNS, dan resolver yang tertinggal jarang yang Anda harapkan. Dua desain menangani momen itu dengan sangat berbeda: memblokir setiap paket DNS yang tidak berada di dalam tunnel, ataumembiarkan satu resolver berdiri sebagai pengecualian. Keduanya bisa dipertahankan. Dari tab peramban gejalanya tampak hampir identik, jadi tugas pertama adalah mencari tahu desain mana yang benar-benar Anda terapkan.
Saya menjaga perbedaan itu di depan mata karena perbaikannya berlawanan di tiap kasus. Satu desain butuh pengecualian lebih lebar, yang lain lebih sempit. Menebak membuat Anda kehilangan privasi atau satu sore.
Dua desain DNS untuk gangguan yang sama
Desain A memperlakukan resolver sebagai layanan lain di balik tunnel. Aturan firewall mengizinkan UDP dan TCP 53 hanya pada antarmuka tunnel, dan alamat yang diberikan ke klien adalah resolver di dalam tunnel. Saat tunnel jatuh, pencarian berhenti, dan itulah hasil yang dimaksud, bukan kegagalan.
Desain B menjaga resolver tetap terjangkau di jaringan lokal, biasanya router pada 192.168.1.1 atau stub sistem operasi pada 127.0.0.53, dengan alasan resolusi nama tidak seharusnya mati bersama tunnel. Itu praktis di LAN rumah tempat router menyelesaikan untuk seluruh rumah. Di Wi-Fi hotel atau bandara pengecualian yang sama menunjuk ke server orang lain, dan setiap nama yang Anda ketik terungkap meski lalu lintas web Anda tetap diblokir.
Batasnya adalah siapa yang memiliki resolver. Jika Anda memercayai yang lokal, pengecualian adalah lubang kecil yang jujur. Jika tidak, desain hanya-tunnel adalah satu-satunya yang bertahan, dan harganya adalah tunnel yang jatuh membawa semua nama.
Mengapa pencarian milik klien VPN sendiri masih berfungsi
Klien harus menyelesaikan nama host gateway sebelum tunnel ada, jadi blokir ketat tidak boleh menutupi jalur bootstrap klien. Sebagian besar klien menembolok alamat titik akhir atau menyediakan pengecualian bootstrap terdokumentasi untuk satu host itu. Jika kumpulan aturan Anda memblokir pencarian itu, tunnel tidak akan pernah kembali dan log menunjukkan klien yang tidak bisa mencapai servernya sendiri, yang merupakan cacat kebijakan, bukan cacat DNS.
DNS terbelah adalah tempat lain hal ini muncul. Klien mendorong zona internal ke resolver privat dan membiarkan sisanya pada resolver sistem. Setelah jatuh, nama publik mungkin masih terselesaikan sementara nama internal kehabisan waktu, karena zona privat tidak punya rute lagi. Bagi pengguna itu "VPN merusak internet"; bagi log resolver itu kueri yang tidak pernah tiba.
Di bawah systemd-resolved Anda dapat melihat pembelahannya secara langsung.resolvectl statusmencantumkan server DNS per tautan dan domain perutean, dan setelah tunnel turun domain internal terus menunjuk ke server pada tautan yang tidak lagi ada. Stub pada 127.0.0.53 masih menerima kueri, lalu menunggu hulu yang tidak akan menjawab, dan itulah sebabnya kegagalan memakan waktu beberapa detik alih-alih langsung kembali.
DNS terenkripsi tidak melewati penyaring paket
DNS over HTTPS dan DNS over TLS berjalan pada 443 dan 853, jadi aturan yang memblokir port 53 tidak mengatakan apa pun tentang keduanya. Memblokir "DNS" berdasarkan port adalah kebijakan tentang port, bukan tentang resolusi nama. Jika kill switch Anda memblokir semua lalu lintas di luar tunnel, DoH tercakup secara kebetulan. Jika Anda menyediakan pengecualian untuk captive portal atau resolver publik, tidak.
Kontrol di sisi klien adalah tuas yang lebih murah. Firefox melepaskan resolver DoH-nya ketika nama kenariuse-application-dns.nettidak terselesaikan, dan itulah sebabnya jaringan terkelola menerbitkan domain itu sebagai NXDOMAIN; kebijakan perusahaan juga dapat mematikannya secara permanen. Android Private DNS dan DNS aman Chrome punya sakelar dan nilai bawaan sendiri. Mematikannya lebih andal daripada mengejar alamat resolver, karena daftar alamat berubah sedangkan kumpulan aturan Anda tidak.
Ada versi ini yang sama sekali bukan soal kebocoran. Aplikasi dengan resolver tersemat tetap butuh jalur jaringan untuk mencapainya. Enkripsi mengubah siapa yang bisa membaca kueri, bukan apakah paket bisa meninggalkan mesin, jadi blokir seluruh perangkat mengalahkan pengaturan itu tanpa menyentuhnya.
Cocokkan gejala dengan lapisan
Sebagian besar laporan datang sebagai satu kalimat, dan kalimat itu biasanya sudah menyebut lapisannya. Tabel di bawah adalah yang saya lewati sebelum menyentuh aturan; intinya memutuskan apakah kueri diblokir, salah diarahkan, atau tidak pernah dikirim.
| Symptom | Likely layer | First check |
|---|---|---|
| Every name fails at once, instantly | Resolver answering with a refusal | Query the resolver by address, not by name |
| Lookups hang for seconds, then time out | Packets dropped with no response | Watch port 53 on the physical link |
| Public names resolve, internal ones do not | Split-DNS routing domain | Per-link DNS servers on the tunnel |
| Names resolve, the page still fails | Not DNS: routing or MTU | Connect to the IP directly |
| Only one application fails | Pinned resolver or cached answer | Check that app's DNS setting |
Dua baris pertama adalah yang salah didiagnosis orang. Jatuh diam-diam dan penolakan sama-sama tampak seperti "DNS rusak" di peramban, tetapi hanya satu yang berarti kill switch Anda menjalankan tugasnya. Penolakan berarti ada yang menjawab, jadi blokirnya bukan di tempat yang Anda kira.
Pulihkan kebijakan resolver, lalu buktikan
Perbaiki desainnya, bukan gejalanya. Untuk resolusi hanya melalui tunnel, izinkan 53 pada antarmuka tunnel, dorong resolver internal bersama konfigurasi tunnel, dan biarkan tautan fisik tanpa izin DNS apa pun. Di wg-quick barisDNS =adalah yang menuliskan resolver ke konfigurasi antarmuka, jadi tunnel yang melewatkannya membiarkan resolver lama di tempatnya dan setiap kueri di jalur yang salah.manual wg-quickmendokumentasikan perilaku itu per platform.
Lalu verifikasi dalam urutan ini. Di Linux,resolvectl statusmenampilkan tautan aktif,dig +short example.commenguji nama publik,dig @10.8.0.1 internal.example.commenguji yang privat, dansudo tcpdump -ni any port 53menunjukkan antarmuka mana yang dipakai paket saat Anda menjalankan keduanya. Di Windows,Get-DnsClientServerAddress -AddressFamily IPv4danResolve-DnsName example.commemberikan dua fakta yang sama: siapa yang dikonfigurasi, dan siapa yang menjawab.
Akhiri dengan uji negatif. Putuskan tunnel, pastikan nama publik baru gagal, pastikan nama privat gagal, danpastikan tidak ada paket port 53 yang meninggalkan adaptor fisik. Blokir yang hanya bertahan untuk jawaban tersimpan sama sekali tidak bertahan.
Daftar periksa sebelum menutup tiket:
- Resolver yang dipakai selama gangguan adalah yang dimaksud kebijakan.
- Pencarian titik akhir milik klien sendiri masih diizinkan, lewat tembolok atau pengecualian.
- DoH dan DoT tercakup blokir atau dinonaktifkan oleh kebijakan.
- Zona privat gagal tertutup, bukan terbuka, begitu tunnel hilang.