openfortivpn terus menulis ganti DNS? Cari pemilik sebenar

Ikuti sambungan sejak ia naik: klien mengesahkan, pppd berunding, dan kemudian sesuatu menulis tetapan DNS ke dalam sistem pengendalian. Jika anda hanya tahu VPN menukar penyelesai anda, anda belum tahu peringkat mana yang melakukannya. Dua daripadanya boleh, dan pada klien yang menggunakan integrasi pppd yang didokumenkan kedua-duanya berjalan cukup hampir untuk kelihatan seperti satu pelaku. Menamakan penulis ialah langkah pertama; memilih penggantinya ialah langkah kedua, dan itu keputusan berasingan dengan mod kegagalannya sendiri.

Urutan di bawah mengikuti klien ke arah luar: apa yang diubah oleh sambungan, suis mana mendiamkan penulis mana, siapa yang sepatutnya mengambil alih, dan bagaimana mengesahkan hasilnya bertahan selepas sambungan semula. Setiap peringkat meninggalkan jejak berbeza, dan jejak itulah yang memberitahu anda sama ada penyerahan itu benar-benar berlaku.

Mulakan dengan apa yang sebenarnya diubah oleh sambungan

Sambung sekali dengan arahan biasa anda dan bandingkan resolusi sebelum dan selepas. Pada hos Linux yang menjalankan systemd-resolved, resolvectl status mencetak pelayan DNS dan domain carian bagi setiap pautan, dan pautan tun atau ppp baharu yang membawa pelayannya sendiri ialah cap jari kemas kini dari pihak klien. Pada macOS, scutil --dns menunjukkan konfigurasi penyelesai dalam susunan aplikasi merujuknya.

Bandingkan itu dengan fail yang anda jangkakan berubah. Entri terikat sambungan dalam paparan setiap pautan dan /etc/resolv.conf yang ditulis semula ialah dua hasil berbeza, dan yang kedua mungkin pautan simbolik yang diuruskan sepenuhnya oleh sesuatu yang lain. Catat alamat penyelesai, domain carian dan nama antara muka pada saat yang sama; perubahan pada mana-mana satu daripadanya menunjuk kepada penulis yang berbeza. Tanpa garis dasar itu, setiap pembetulan kemudiannya ialah tekaan tentang komponen mana antara tiga yang bergerak.

Dua suis dan penulis yang didiamkan oleh setiap satu

openfortivpn mendokumenkan serpihan pilihan yang mematikan kedua-dua penulis yang boleh dikawalnya, dan setiap suis mempunyai persamaan yang ditulis penuh yang dianggap manual sebagai tetapan yang sama.

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns menghalang klien daripada menggunakan pelayan DNS yang dipelajarinya daripada get laluan, manakala --pppd-no-peerdns menghalang pppd daripada menolak DNS rakan ke dalam sistem. Manual upstream memberi amaran bahawa kemas kini DNS melalui PPP boleh bersaing dengan kemas kini DNS klien sendiri, sebab itu kedua-dua suis tergolong dalam serpihan dan bukannya salah satu daripadanya dianggap mencukupi.

Tiada suis menamakan penyelesai ganti, dan tiada yang menghalang pengurus rangkaian, klien DHCP atau integrasi VPN berasingan daripada menulis resolusi selepas itu. Mendiamkan dua penulis membiarkan medan terbuka dan bukannya dimiliki. Jika komponen ketiga sudah menguruskan DNS, serpihan itu tidak mengubah apa-apa yang anda boleh perhatikan; jika tiada apa mengurusnya, anda baru sahaja membuang satu-satunya sumber resolusi nama peribadi. Itu susunan yang sah hanya apabila pemilik ganti dipilih dahulu dan diuji secara berasingan.

Pilih pemilik sebelum anda melumpuhkan apa-apa

Tentukan dahulu siapa yang menjawab pertanyaan untuk nama kerja, kerana pilihan itu mengehadkan segala-galanya selepasnya. Mengekalkan penyelesai sedia ada bermakna zon peribadi sudah mesti boleh dicapai dari mana pun klien berada, dan penyelesai peribadi di dalam pejabat memerlukan laluan yang bertahan apabila terowong naik. Menghantar setiap pertanyaan ke satu perkhidmatan dalaman ialah dasar ketiga dengan mod kegagalan yang lebih tajam: apabila perkhidmatan itu tidak boleh dicapai, nama awam gagal bersama yang peribadi.

Pemilikan laluan kekal berasingan dengan sengaja. Pilihan laluan tidak diperlukan kerana anda mengubah DNS, dan melumpuhkan pemasangan laluan tanpa memasang pengganti boleh menjadikan penyelesai yang baru anda pilih tidak boleh dicapai. Semak jadual penghalaan khusus untuk alamat penyelesai, bukan hanya untuk subrangkaian aplikasi yang kebetulan anda uji.

Semak resolusi bagi setiap pautan, bukan setiap fail

Satu /etc/resolv.conf bukan inventori tentang apa yang sebenarnya digunakan aplikasi pada hos dengan resolusi berskop atau setiap domain, jadi bacalah keadaan penyelesai seperti yang didedahkan oleh platform.

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

Tanyakan satu nama peribadi dan satu nama awam setelah sambungan naik, dan catat pautan mana yang menjawab setiap satu. Di tempat pautan VPN membawa senarai carian setiap domain, nama peribadi boleh diselesaikan dengan betul manakala nama awam masih pergi ke penyelesai tempatan, dan pemisahan itu ialah reka bentuk yang berfungsi dan bukan kerosakan. Jika pertanyaan peribadi gagal, periksa laluan ke penyelesai sebelum menyentuh DNS lagi; jika ia berjaya manakala aplikasi masih gagal, aplikasi itu mungkin membaca penyelesai sendiri yang dicache atau dikonfigurasikan secara berasingan.

Sambung semula dan sahkan keadaan terputus

Turunkan sambungan dan ulangi kedua-dua pertanyaan. Apa pun yang dipasang oleh pemilik yang dipilih sepatutnya dialihkan atau dipulihkan oleh pemilik itu, bukan ditinggalkan oleh klien yang anda diamkan. Entri setiap pautan yang lapuk dan hidup lebih lama daripada terowong terus menghantar pertanyaan peribadi ke alamat yang tidak lagi boleh dicapai.

Kemudian sambung semula dan baca tiga nilai yang sama sekali lagi: alamat penyelesai, domain carian, antara muka.

Jika semuanya sepadan dengan dasar yang anda catat, penyerahan selesai dan klien VPN bukan lagi salah seorang penulis. Jika sesuatu nilai berundur semula beberapa saat selepas pautan naik, sesuatu yang lain masih menggunakan konfigurasi, dan langkah seterusnya ialah mengenal pasti komponen itu dan bukannya menambah satu lagi bendera. Keadaan akhir yang anda mahukan tidak dramatik: satu pemilik, satu dasar yang didokumenkan, dan hos terputus yang menyelesaikan tepat seperti sebelum terowong wujud.