Siapa sebenarnya menggunakan tetapan DNS OpenConnect pada Windows?

Menaikkan terowong bukan sama dengan memasang nilai DNS-nya. OpenConnect berunding, dan pembantu di sebelah Windows menggunakan. Jurang antara kedua-dua langkah itu menjelaskan kebanyakan kegagalan nama peribadi pada klien ini, dan pembantu itu hampir tidak pernah menjadi halaman tetapan VPN Windows.

Asingkan apa yang ditawarkan gateway daripada apa yang dipasang Windows

Klien menyerahkan data sambungan kepada antara muka skrip, dan varian Unix serta Windows ialah program berasingan. Pada Windows pelaksanaannya biasanya pembantu JavaScript yang membaca pemboleh ubah seperti pelayan DNS dalaman dan domain dalaman sebelum menyentuh mana-mana penyesuai. Tiada apa-apa dalam terowong itu sendiri menulis keadaan penyelesai.

Pemisahan itu penting kerana sesuatu nilai boleh wujud dalam rundingan dan tidak pernah sampai kepada penyesuai. Pembantu yang hilang, gagal di pertengahan jalan atau merupakan salinan lama yang dibendel dalam pembalut GUI membiarkan Windows tepat seperti sebelumnya. Sesi kelihatan bersambung, nama peribadi masih diselesaikan melalui penyedia tempatan, dan tiada apa-apa dalam tetingkap klien menunjukkan perbezaannya. Membaca output pembantu itu sendiri ialah satu-satunya cara yang boleh dipercayai untuk mengetahui peringkat mana yang rosak.

Pembalut GUI mungkin membawa salinan klien dan pembantunya sendiri, jadi openconnect.exe kedua di tempat lain pada cakera tidak membuktikan apa-apa. Cari fail boleh laku yang memulakan sesi sebelum menilai konfigurasinya.

Baca keadaan penyelesai tanpa mengubahnya

Tiga pertanyaan baca sahaja meliputi kekeliruan biasa, dan setiap satu menjawab soalan yang berbeza:

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

Pelayan pada peringkat penyesuai ialah apa yang kebanyakan orang maksudkan dengan DNS VPN. Akhiran khusus sambungan menentukan sama ada nama pendek dikembangkan sama sekali. Senarai dasar ruang nama terpakai kepada nama yang sepadan tanpa mengira susunan penyesuai, dan hasil kosong di situ bukan kerosakan apabila pembantu itu tidak pernah berniat menciptanya. Membaca ketiga-tiganya sebelum mengedit ialah apa yang menghalang pembaikan yang hanya memindahkan gejala ke tempat lain.

Mulakan dengan nama yang layak sepenuhnya. Jika FQDN diselesaikan dan nama pendek tidak, jurangnya ialah akhiran atau senarai carian, bukan alamat pelayan.

Tanya pelayan yang dimaksudkan secara langsung sebagai langkah kedua, dengan mana-mana alat penyelesai yang sudah dipasang. Jawapan langsung membuktikan pelayan itu boleh dicapai dan berwibawa untuk zon tersebut. Ia tidak membuktikan apa-apa tentang pelayan mana yang ditanya oleh aplikasi secara lalai.

Namakan komponen yang memiliki sambungan

Dua susunan biasa. Klien yang dimulakan daripada terminal menyerahkan laluan skripnya secara jelas, jadi pemiliknya kelihatan dalam arahan yang dijalankan. Aplikasi berbendel memulakan klien untuk anda dan menyimpan pembantu dalam direktorinya sendiri, yang bermaksud vendor menentukan bila ia berubah.

Bandingkan versi pembantu merentas pemasangan sebelum menukar apa-apa. Menjalankan pembantu yang diambil daripada cermin dengan hak yang dipertingkatkan kerana nama fail kelihatan biasa menjadikan jurang DNS sebagai insiden keselamatan.

Setelah pemilik diketahui, sasaran pembaikan menjadi jelas: laluan skrip yang disokong dalam pelancar, kemas kini pakej, atau profil yang diperbetulkan pada gateway. Tiada satu pun memerlukan pengeditan sifat penyesuai secara manual.

Betulkan pemiliknya, bukan penyesuainya

DNS yang ditetapkan secara manual pada penyesuai sering bertahan selepas pemutusan, sebab itulah ia kelihatan berfungsi dan kemudian menimbulkan masalah pada rangkaian seterusnya. Penyelesai awam yang dibolkan pada setiap antara muka menyembunyikan masalah ruang nama peribadi dan bukannya menyelesaikannya. Apabila pembantu tidak pernah menerima nilai DNS, profil gateway ialah tempat untuk dilihat. Apabila ia menerimanya dan penyesuai masih menunjukkan pelayan lama, pembantu gagal semasa menyambung dan log klien biasanya merekodkannya berhampiran baris persediaan terowong.

Bina semula keadaan melalui laluan yang disokong, kemudian sahkan satu kitaran penuh: sambung, selesaikan FQDN peribadi, buka perkhidmatan, putuskan sambungan, dan pastikan penyesuai kembali dengan pelayan sebelumnya.

Periksa aplikasi yang sebenarnya gagal

Pelayar dengan tetapan DNS tersulitnya sendiri mengabaikan semua di atas dan terus menjawab daripada penyelesai awam. Aplikasi yang menyimpan jawapan negatif dalam cache dari sebelum terowong dinaikkan berkelakuan sama. Bandingkannya dengan pertanyaan sistem biasa pada mesin yang sama sebelum menukar alamat penyelesai lagi.

Jika pertanyaan sistem betul dan aplikasinya salah, kesalahan yang tinggal berada dalam konfigurasi DNS aplikasi itu, bukan pada laluan VPN.