Siapa yang sebenarnya menerapkan pengaturan DNS OpenConnect di Windows?

Menyalakan tunnel tidak sama dengan memasang nilai DNS-nya. OpenConnect bernegosiasi, dan helper di sisi Windows menerapkan. Kesenjangan antara kedua langkah itu menjelaskan sebagian besar kegagalan nama privat pada klien ini, dan helper hampir tidak pernah merupakan halaman pengaturan VPN Windows.

Pisahkan apa yang ditawarkan gateway dari apa yang dipasang Windows

Klien menyerahkan data koneksi ke antarmuka skrip, dan varian Unix serta Windows adalah program terpisah. Di Windows implementasinya biasanya helper JavaScript yang membaca variabel seperti server DNS internal dan domain internal sebelum menyentuh adaptor mana pun. Tidak ada apa pun di dalam tunnel itu sendiri yang menulis status resolver.

Pemisahan itu penting karena sebuah nilai bisa ada dalam negosiasi dan tidak pernah mencapai adaptor. Helper yang hilang, gagal di tengah jalan, atau merupakan salinan lama yang dibundel di dalam pembungkus GUI membiarkan Windows persis seperti sebelumnya. Sesi tampak terhubung, nama privat tetap diselesaikan melalui penyedia lokal, dan tidak ada apa pun di jendela klien yang memberi petunjuk tentang perbedaannya. Membaca keluaran helper itu sendiri adalah satu-satunya cara andal untuk mengetahui tahap mana yang rusak.

Pembungkus GUI dapat membawa salinannya sendiri dari klien dan helper, jadi openconnect.exe kedua di tempat lain pada disk tidak membuktikan apa pun. Temukan executable yang memulai sesi sebelum menilai konfigurasinya.

Baca status resolver tanpa mengubahnya

Tiga kueri hanya-baca mencakup kebingungan yang biasa, dan masing-masing menjawab pertanyaan berbeda:

Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix
Get-DnsClientNrptPolicy -Effective

Server pada tingkat adaptor adalah yang dimaksud kebanyakan orang dengan DNS VPN. Sufiks khusus koneksi menentukan apakah nama pendek diperluas sama sekali. Daftar kebijakan namespace berlaku untuk nama yang cocok terlepas dari urutan adaptor, dan hasil kosong di sana bukan cacat ketika helper tidak pernah berniat membuatnya. Membaca ketiganya sebelum mengedit adalah yang mencegah perbaikan yang hanya memindahkan gejala ke tempat lain.

Mulailah dengan nama yang sepenuhnya memenuhi syarat. Jika FQDN berhasil diselesaikan dan nama pendek tidak, sufiks atau daftar pencarian adalah celahnya, bukan alamat server.

Tanyakan langsung ke server yang dimaksud sebagai langkah kedua, dengan alat resolver apa pun yang sudah terpasang. Jawaban langsung membuktikan server dapat dijangkau dan berwenang untuk zona tersebut. Itu tidak membuktikan apa pun tentang server mana yang ditanyakan aplikasi secara default.

Namai komponen yang memiliki koneksi

Dua susunan yang umum. Klien yang dijalankan dari terminal meneruskan jalur skripnya secara eksplisit, sehingga pemiliknya terlihat dalam perintah yang dijalankan. Aplikasi terpaket menjalankan klien untuk Anda dan menyimpan helper di direktorinya sendiri, yang berarti vendor memutuskan kapan ia berubah.

Bandingkan versi helper di antara pemasangan sebelum menukar apa pun. Menjalankan helper yang diambil dari cermin dengan hak yang ditinggikan karena nama berkasnya terlihat familier mengubah celah DNS menjadi insiden keamanan.

Setelah pemilik diketahui, sasaran perbaikan menjadi jelas: jalur skrip yang didukung di peluncur, pembaruan paket, atau profil yang dikoreksi di gateway. Tidak satu pun dari itu memerlukan pengeditan properti adaptor secara manual.

Perbaiki pemiliknya, bukan adaptornya

DNS yang diatur manual pada adaptor sering bertahan setelah pemutusan, itulah sebabnya tampak berfungsi lalu menimbulkan masalah pada jaringan berikutnya. Resolver publik yang dibaut ke setiap antarmuka menyembunyikan masalah namespace privat alih-alih menyelesaikannya. Ketika helper tidak pernah menerima nilai DNS, profil gateway adalah tempat untuk melihat. Ketika ia menerimanya dan adaptor masih menampilkan server lama, helper gagal saat menyambung dan log klien biasanya mencatatnya di dekat baris penyiapan tunnel.

Bangun ulang status melalui jalur yang didukung, lalu verifikasi satu siklus penuh: sambungkan, selesaikan FQDN privat, buka layanan, putuskan, dan konfirmasi adaptor kembali dengan server sebelumnya.

Periksa aplikasi yang sebenarnya gagal

Peramban dengan pengaturan DNS terenkripsi sendiri mengabaikan semua di atas dan terus menjawab dari resolver publik. Aplikasi yang menyimpan jawaban negatif ter-cache dari sebelum tunnel menyala berperilaku sama. Bandingkan dengan kueri sistem biasa pada mesin yang sama sebelum mengubah alamat resolver lagi.

Jika kueri sistem benar dan aplikasinya salah, kesalahan yang tersisa berada di dalam konfigurasi DNS aplikasi itu, bukan di jalur VPN.