Mengapa DNS Berhenti Berfungsi Selepas OpenVPN Menyambung pada Windows

Resolver masih menjawab ping sedangkan port 53 tidak ke mana-mana. Semak sama ada block-outside-dns menapis, kemudian sediakan resolver yang boleh dicapai oleh terowong.

Ping ke resolver pejabat masih dijawab selepas "OpenVPN" menyambung, namun setiap carian nama tetap gagal. Alamat boleh dicapai sedangkan port tidak, gabungan yang masuk akal apabila anda tahu Windows boleh menapis DNS mengikut penyesuai. Dengan block-outside-dns dalam profil, penapis itu ialah suspek pertama dan jadual laluan ialah tempat yang salah untuk dilihat. Dua ujian di bawah memisahkan lapisan dalam beberapa saat.

Alamat boleh dicapai, port mati

Ping yang berjaya membuktikan hos hidup dan laluan wujud. Ia tidak berkata apa-apa tentang kebenaran mencapai port 53, kerana penapis berkenaan bekerja pada lapisan lain dan bergantung pada penyesuai. Itulah sebabnya mesin yang sama boleh menjawab ICMP dan menolak setiap pertanyaan yang dihantar ke alamat yang sama. Jalankan kedua-dua ujian dalam sesi yang sama sebelum menukar sebarang konfigurasi.

ping <resolver-ip>
nslookup <name> <resolver-ip>

Pasangan itu ialah diagnosisnya. Trafik biasa ke subrangkaian terus berjalan sementara penyelesaian nama mati, dan orang membuat kesimpulan bahawa pelayan rosak atau DNS tidak pernah dihantar. Kedua-dua penjelasan mahal untuk dikejar, dan bukti menunjuk ke tempat yang lebih sempit. Sahkan pasangan itu sebelum menyentuh sebarang tetapan.

Pilihan ini ialah peraturan platform penapisan

Rujukan OpenVPN menerangkan block-outside-dns sebagai sekatan Windows Filtering Platform yang menghalang aplikasi daripada mencapai DNS pada penyesuai di luar terowong. Ia meliputi TCP dan UDP port 53. Oleh sebab penapis itu tinggal dalam WFP dan bukan dalam senarai peraturan tembok api biasa, menambah peraturan kebenaran di tempat lain tidak semestinya mengubah hasilnya. Itulah sebabnya nasihat biasa supaya membenarkan DNS terus gagal.

Tetapan itu boleh datang daripada profil yang diimport atau daripada pelayan, dan fail yang terakhir anda sunting "bukan bukti apa yang dimuatkan oleh klien". Baca konfigurasi berkesan dan log sambungan bersama-sama. Pilihan ini juga khusus Windows, dan memperlakukannya sebagai mudah alih menghasilkan nasihat yang tidak terpakai.

Cari komponen klien yang memiliki sekatan itu dan bukannya menambah lebih banyak peraturan. Pemiliknya ialah perkara yang benar-benar boleh membuangnya.

Penapis bukan resolver

Menyekat trafik di luar terowong tidak memasang resolver yang berfungsi di dalamnya. Pilihan ini membuang satu laluan dan menyerahkan konfigurasi DNS terowong kepada sesiapa yang menyediakan profil. Profil yang tidak pernah menghantar resolver kini tidak mempunyai satu pun.

Lakukan tiga pemeriksaan mengikut urutan. Pertama, resolver mana yang benar-benar digunakan oleh aplikasi yang gagal. Kedua, sama ada klien menggunakan tetapan DNS VPN. Ketiga, antara muka mana yang membawa trafik ke resolver itu.

  1. Resolver yang digunakan: bandingkan Resolve-DnsName -Server <resolver-ip> <name> dengan pelayan DNS yang disenaraikan oleh ipconfig /all.
  2. DNS VPN digunakan: periksa entri DNS penyesuai terowong dalam output ipconfig /all yang sama.
  3. Antara muka yang digunakan: Find-NetRoute -RemoteIPAddress <resolver-ip> menamakan antara muka keluar untuk destinasi itu.

Resolver LAN menjadi tidak dapat dicapai mengikut reka bentuk di bawah dasar ini, walaupun trafik LAN lain berjalan. Itulah pilihan itu menjalankan tugasnya. Jika reka bentuk memerlukan DNS melalui VPN, betulkan pendaftaran resolver dan laluan terowong; jika split DNS dengan pengecualian tempatan diperlukan, pemilik konfigurasi mesti menyatakan pengecualian itu dengan cara yang disokong.

Apa yang tidak diliputi oleh pilihan ini

Port 53 bukan keseluruhan penyelesaian nama. DNS over HTTPS dan DNS over TLS menggunakan pengangkutan berbeza, dan sesetengah aplikasi menjalankan logik resolver sendiri tanpa mengira tetapan sistem. Oleh itu pelayar boleh menyelesaikan nama sedangkan baris arahan tidak.

Anggap perbezaan itu sebagai diagnostik dan bukan percanggahan. Bandingkan kedua-duanya sebelum memutuskan bahawa resolver sistem rosak.

Kekalkan kesimpulan itu sempit apabila anda menulisnya. Pilihan ini mengekang satu pengangkutan pada satu platform, dan baki laluan penyelesaian ialah soalan reka bentuk berasingan dengan pemiliknya sendiri.

Periksa keadaan sebelum dan selepas terputus

Jalankan carian yang sama semasa sambungan dan sekali lagi selepas klien pemilik terputus. Yang pertama sepatutnya gagal untuk resolver luar semasa terowong naik, dan yang kedua sepatutnya berjaya apabila penapis dibuang. Jika ia masih gagal selepas terputus, penapis itu tidak dibersihkan.

ipconfig /displaydns
nslookup <name> <resolver-ip>

Memulakan semula perkhidmatan klien atau mesin biasanya membersihkan penapis lama. Itu mengesahkan diagnosis tanpa membuktikan pembaikan kekal. Catat apa yang anda lihat, kerana penapis yang bertahan selepas terputus akan melakukannya lagi, dan catatan itulah yang mewajarkan laporan pepijat.

Hanya selepas pemeriksaan itu masuk akal untuk menggantikan resolver atau membina semula dasar tembok api. Kedua-duanya perubahan yang lebih besar daripada yang disokong bukti.

Artikel berkaitan