Split tunnel mengecualikan peramban, bukan kueri DNS-nya

Peramban dikecualikan dari terowongan, halaman IP publik memastikan lalu lintasnya keluar lewat koneksi rumah, dan wiki internal tetap tidak terbuka. Resolusi nama pergi ke tempat lain, dan tempat lain itu biasanya resolver yang dikonfigurasi VPN. Jalur data dan jalur resolver adalah keputusan terpisah di sebagian besar rancangan split tunnel. Periksa mana yang benar-benar dipakai peramban sebelum menyebut pengecualian itu rusak.

Jalur data dan jalur resolver terpisah

Pengecualian mengeluarkan paket aplikasi dari terowongan, yang merupakan keputusan perutean dan tembok api pada jalur data. Resolusi nama adalah pencarian lain: sebuah proses bertanya ke resolver sistem, dan resolver itu memutuskan server mana yang menerima pertanyaan.

Keduanya bisa disengaja dan berbeda. Penerapan kerja dapat menyimpan ruang nama internal di resolver korporat sambil mengirim penjelajahan publik terpilih ke luar terowongan, justru karena nama internal tidak diresolusi di tempat lain. Kasus yang membingungkan adalah kebalikannya: situs publik gagal karena peramban tidak pernah bertanya ke resolver yang diharapkan penerapan. Catat rute dan resolver secara terpisah, dan separuh perdebatan hilang.

Temukan proses mana yang mengajukan pertanyaan

Peramban dapat memakai resolver sistem, layanan DNS terenkripsinya sendiri, atau resolver yang ditetapkan sistem operasi per jaringan. Yang pertama mengikuti kebijakan platform, yang kedua melewati kebijakan itu sepenuhnya, dan yang ketiga bergantung pada tautan mana kueri dirutekan.

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

Baca konfigurasi efektif sebelum menguji: tautan mana yang membawa server DNS, ruang nama apa yang diklaim, dan apakah kebijakan per nama menimpa nilai bawaan. Di Linux, DNS terpisah memakai domain perutean; di Windows, tabel kebijakan resolusi nama melakukan hal yang sama untuk ruang nama. Keduanya tidak terlihat dari halaman uji kebocoran.

Putuskan resolver mana melihat nama mana

Tuliskan pemetaan yang dimaksud sebelum mengubah apa pun: nama internal ke resolver korporat, nama publik ke layanan yang diizinkan kebijakan, dan pengecualian dengan pemiliknya. Tanpa daftar itu, setiap label uji kebocoran menjadi perdebatan kebijakan yang tak dapat diselesaikan siapa pun.

Lalu periksa pengaturan peramban itu sendiri, karena DNS terenkripsi di peramban diterapkan sebelum sistem operasi menerima kueri. Pengguna yang mengaktifkannya untuk melewati portal tawanan telah diam-diam menimpa resolver yang dipilih penerapan. Itu keputusan konfigurasi, bukan kebocoran, dan pantas mendapat keputusan, bukan daftar blokir.

Jangan menulis ulang setiap bidang DNS agar satu label uji menjadi hijau. Label itu menggambarkan satu kueri dari satu proses pada satu saat.

Verifikasi kueri dan koneksi secara terpisah

Uji kedua jalur secara terpisah. Uji koneksi menunjukkan rute data, dan uji resolver menunjukkan siapa yang menerima nama.

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

Tanyakan juga ke resolver secara eksplisit, agar kegagalan dapat diatribusikan ke server, bukan ke jalur. Lalu mulai ulang peramban dan ulangi, karena aplikasi menyimpan jawaban negatif di cache dan kegagalan lama tampak menetap.

Setelah perubahan disetujui, catat rute data dan penerima resolver sebagai dua baris terpisah beserta tanggalnya. Jika perilaku kembali pada penyambungan ulang berikutnya, profil yang menyediakannya adalah yang harus diperbaiki, bukan peramban.