DNS tidak diselesaikan apabila kill switch VPN menyekat port 53
Kill switch boleh menyekat DNS dengan sengaja. Bandingkan penyelesaian hanya di dalam terowong dengan pengecualian penyelesai tempatan, kemudian tentukan lapisan mana yang sebenarnya gagal.
Apabila kill switch menjatuhkan terowong, ia turut membawa laluan DNS, dan penyelesai yang tertinggal jarang yang anda jangkakan. Dua reka bentuk menangani detik itu dengan sangat berbeza: menyekat setiap paket DNS yang tidak berada di dalam terowong, ataumembiarkan satu penyelesai berdiri sebagai pengecualian. Kedua-duanya boleh dipertahankan. Dari tab pelayar gejalanya kelihatan hampir sama, jadi tugas pertama ialah mengetahui reka bentuk mana yang sebenarnya anda gunakan.
Saya menyimpan perbezaan itu di hadapan kerana pembaikannya bertentangan dalam setiap kes. Satu reka bentuk memerlukan pengecualian lebih luas, yang lain lebih sempit. Meneka membuat anda kehilangan privasi atau satu petang.
Dua reka bentuk DNS untuk gangguan yang sama
Reka bentuk A menganggap penyelesai sebagai satu lagi perkhidmatan di belakang terowong. Peraturan tembok api membenarkan UDP dan TCP 53 hanya pada antara muka terowong, dan alamat yang diberi kepada klien ialah penyelesai di dalam terowong. Apabila terowong jatuh, carian berhenti, dan itulah hasil yang dimaksudkan, bukan kerosakan.
Reka bentuk B mengekalkan penyelesai boleh dicapai pada rangkaian tempatan, biasanya penghala pada 192.168.1.1 atau stub sistem pengendalian pada 127.0.0.53, atas alasan penyelesaian nama tidak sepatutnya mati bersama terowong. Ia mudah pada LAN rumah tempat penghala menyelesaikan untuk seluruh rumah. Pada Wi-Fi hotel atau lapangan terbang pengecualian yang sama menunjuk ke pelayan orang lain, dan setiap nama yang anda taip didedahkan walaupun trafik web anda kekal disekat.
Sempadan ialah siapa yang memiliki penyelesai. Jika anda mempercayai yang tempatan, pengecualian ialah lubang kecil yang jujur. Jika tidak, reka bentuk hanya-terowong ialah satu-satunya yang bertahan, dan harganya ialah terowong yang jatuh membawa semua nama.
Mengapa carian klien VPN sendiri masih berfungsi
Klien perlu menyelesaikan nama hos get laluan sebelum terowong wujud, jadi sekatan ketat tidak boleh meliputi laluan butstrap klien. Kebanyakan klien sama ada menyimpan alamat titik akhir dalam cache atau menyediakan pengecualian butstrap berdokumen untuk hos tunggal itu. Jika set peraturan anda menyekat carian itu, terowong tidak akan kembali dan log menunjukkan klien yang tidak dapat mencapai pelayannya sendiri, yang merupakan kecacatan dasar dan bukan kecacatan DNS.
DNS terbahagi ialah tempat lain perkara ini muncul. Klien menolak zon dalaman ke penyelesai peribadi dan membiarkan segala-galanya kepada penyelesai sistem. Selepas jatuh, nama awam mungkin masih diselesaikan manakala nama dalaman tamat masa, kerana zon peribadi tiada laluan lagi. Bagi pengguna itu "VPN merosakkan internet"; bagi log penyelesai itu pertanyaan yang tidak pernah tiba.
Di bawah systemd-resolved anda boleh melihat pembahagian itu secara langsung.resolvectl statusmenyenaraikan pelayan DNS setiap pautan dan domain penghalaan, dan selepas terowong turun domain dalaman terus menunjuk ke pelayan pada pautan yang tidak lagi wujud. Stub pada 127.0.0.53 masih menerima pertanyaan, kemudian menunggu huluan yang tidak akan menjawab, dan itulah sebabnya kegagalan mengambil beberapa saat dan bukannya kembali serta-merta.
DNS tersulit tidak mengelak penapis paket
DNS over HTTPS dan DNS over TLS bergerak pada 443 dan 853, jadi peraturan yang menyekat port 53 tidak berkata apa-apa tentangnya. Menyekat "DNS" mengikut port ialah dasar tentang port, bukan tentang penyelesaian nama. Jika kill switch anda menyekat semua trafik di luar terowong, DoH diliputi secara kebetulan. Jika anda menyediakan pengecualian untuk portal tawanan atau penyelesai awam, ia tidak diliputi.
Kawalan di pihak klien ialah tuas yang lebih murah. Firefox melepaskan penyelesai DoH-nya apabila nama kenariuse-application-dns.nettidak diselesaikan, dan itulah sebabnya rangkaian terurus menerbitkan domain itu sebagai NXDOMAIN; dasar perusahaan juga boleh mematikannya secara kekal. Android Private DNS dan DNS selamat Chrome mempunyai suis dan nilai lalai mereka sendiri. Mematikannya lebih boleh dipercayai daripada mengejar alamat penyelesai, kerana senarai alamat berubah dan set peraturan anda tidak.
Ada versi perkara ini yang sama sekali bukan tentang kebocoran. Aplikasi dengan penyelesai tersemat masih memerlukan laluan rangkaian untuk mencapainya. Penyulitan mengubah siapa yang boleh membaca pertanyaan, bukan sama ada paket boleh meninggalkan mesin, jadi sekatan seluruh peranti mengalahkan tetapan itu tanpa menyentuhnya.
Padankan gejala dengan lapisan
Kebanyakan laporan sampai sebagai satu ayat, dan ayat itu biasanya sudah menamakan lapisannya. Jadual di bawah ialah yang saya lalui sebelum menyentuh peraturan; tujuannya ialah memutuskan sama ada pertanyaan disekat, salah dihalakan atau tidak pernah dihantar.
| 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 ialah yang orang salah diagnosis. Kejatuhan senyap dan penolakan kedua-duanya kelihatan seperti "DNS rosak" dalam pelayar, tetapi hanya satu daripadanya bermakna kill switch anda melakukan tugasnya. Penolakan bermakna ada sesuatu yang menjawab, jadi sekatan itu bukan di tempat yang anda fikirkan.
Pulihkan dasar penyelesai, kemudian buktikannya
Betulkan reka bentuk, bukan gejalanya. Untuk penyelesaian hanya melalui terowong, benarkan 53 pada antara muka terowong, tolak penyelesai dalaman bersama konfigurasi terowong, dan biarkan pautan fizikal tanpa sebarang kebenaran DNS. Dalam wg-quick, barisDNS =itulah yang menulis penyelesai ke dalam konfigurasi antara muka, jadi terowong yang meninggalkannya membiarkan penyelesai lama di tempatnya dan setiap pertanyaan pada laluan yang salah.manual wg-quickmendokumenkan tingkah laku itu mengikut platform.
Kemudian sahkan dalam susunan ini. Pada Linux,resolvectl statusmenunjukkan pautan aktif,dig +short example.commenguji nama awam,dig @10.8.0.1 internal.example.commenguji yang peribadi, dansudo tcpdump -ni any port 53menunjukkan antara muka mana yang digunakan oleh paket semasa anda menjalankan kedua-duanya. Pada Windows,Get-DnsClientServerAddress -AddressFamily IPv4danResolve-DnsName example.commemberikan dua fakta yang sama: siapa yang dikonfigurasikan, dan siapa yang menjawab.
Akhiri dengan ujian negatif. Putuskan terowong, sahkan bahawa nama awam baharu gagal, sahkan bahawa nama peribadi gagal, dansahkan bahawa tiada paket port 53 meninggalkan penyesuai fizikal. Sekatan yang hanya bertahan untuk jawapan cache tidak bertahan langsung.
Senarai semak sebelum menutup tiket:
- Penyelesai yang digunakan semasa gangguan ialah yang dimaksudkan oleh dasar.
- Carian titik akhir klien sendiri masih dibenarkan, melalui cache atau pengecualian.
- DoH dan DoT sama ada diliputi oleh sekatan atau dimatikan oleh dasar.
- Zon peribadi gagal tertutup, bukan terbuka, sebaik sahaja terowong hilang.