openfortivpn terus menimpa DNS? Temukan pemilik sebenarnya

Ikuti koneksi sejak momen ia naik: klien mengautentikasi, pppd bernegosiasi, lalu sesuatu menulis pengaturan DNS ke sistem operasi. Jika Anda hanya tahu bahwa VPN mengubah resolver Anda, Anda belum tahu tahap mana yang melakukannya. Dua di antaranya bisa, dan pada klien yang memakai integrasi pppd terdokumentasi keduanya berjalan cukup berdekatan sehingga tampak seperti satu pelaku. Menamai penulisnya adalah langkah pertama; memilih penggantinya adalah langkah kedua, dan itu keputusan terpisah dengan mode kegagalannya sendiri.

Urutan di bawah mengikuti klien ke arah luar: apa yang diubah koneksi, sakelar mana membungkam penulis mana, siapa yang seharusnya mengambil alih, dan bagaimana memastikan hasilnya bertahan setelah koneksi ulang. Setiap tahap meninggalkan jejak berbeda, dan jejak itulah yang memberi tahu Anda apakah serah terima benar-benar terjadi.

Mulailah dari apa yang sebenarnya diubah koneksi

Hubungkan sekali dengan perintah biasa Anda dan bandingkan resolusi sebelum dan sesudah. Pada host Linux yang menjalankan systemd-resolved, resolvectl status mencetak server DNS dan domain pencarian per tautan, dan tautan tun atau ppp baru yang membawa servernya sendiri adalah sidik jari pembaruan dari sisi klien. Di macOS, scutil --dns menampilkan konfigurasi resolver dalam urutan yang dipakai aplikasi untuk menanyakannya.

Bandingkan itu dengan berkas yang Anda harapkan berubah. Entri yang terikat koneksi di tampilan per tautan dan /etc/resolv.conf yang ditulis ulang adalah dua hasil berbeda, dan yang kedua bisa berupa tautan simbolik yang dikelola sepenuhnya oleh hal lain. Catat alamat resolver, domain pencarian, dan nama antarmuka pada saat yang sama; perubahan pada salah satunya menunjuk ke penulis yang berbeda. Tanpa garis dasar itu, setiap perbaikan berikutnya hanyalah dugaan tentang komponen mana dari tiga yang bergeser.

Dua sakelar dan penulis yang dibungkam masing-masing

openfortivpn mendokumentasikan fragmen opsi yang mematikan kedua penulis yang bisa dikendalikannya, dan setiap sakelar punya padanan yang ditulis lengkap yang diperlakukan manual sebagai pengaturan 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 menghentikan klien menerapkan server DNS yang dipelajarinya dari gateway, sementara --pppd-no-peerdns menghentikan pppd mendorong DNS peer ke dalam sistem. Manual upstream memperingatkan bahwa pembaruan DNS lewat PPP dapat berlomba dengan pembaruan DNS milik klien sendiri, karena itu kedua sakelar harus ada di fragmen alih-alih salah satunya dianggap cukup.

Tidak ada sakelar yang menyebut resolver pengganti, dan tidak ada yang menghentikan manajer jaringan, klien DHCP, atau integrasi VPN terpisah untuk menulis resolusi setelahnya. Membungkam dua penulis membiarkan medan terbuka alih-alih dimiliki. Jika komponen ketiga sudah mengelola DNS, fragmen tidak mengubah apa pun yang dapat Anda amati; jika tidak ada yang mengelolanya, Anda baru saja menghapus satu-satunya sumber resolusi nama privat. Itu pengaturan yang sah hanya bila pemilik pengganti dipilih lebih dulu dan diuji sendiri.

Pilih pemilik sebelum Anda menonaktifkan apa pun

Putuskan lebih dulu siapa yang menjawab kueri untuk nama kerja, karena pilihan itu membatasi semua yang sesudahnya. Mempertahankan resolver yang ada berarti zona privat harus sudah dapat dijangkau dari mana pun klien berada, dan resolver privat di dalam kantor memerlukan rute yang bertahan saat terowongan naik. Mengirim setiap kueri ke satu layanan internal adalah kebijakan ketiga dengan mode kegagalan yang lebih tajam: ketika layanan itu tidak terjangkau, nama publik ikut gagal bersama yang privat.

Kepemilikan rute sengaja tetap terpisah. Opsi rute tidak diperlukan karena Anda mengubah DNS, dan mematikan pemasangan rute tanpa memasang pengganti dapat membuat resolver yang baru Anda pilih tidak terjangkau. Periksa tabel perutean secara khusus untuk alamat resolver, bukan hanya untuk subnet aplikasi yang kebetulan Anda uji.

Periksa resolusi per tautan, bukan per berkas

Satu /etc/resolv.conf bukan inventaris tentang apa yang sebenarnya dipakai aplikasi pada host dengan resolusi terbatas atau per domain, jadi bacalah keadaan resolver sebagaimana platform memaparkannya.

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

Tanyakan satu nama privat dan satu nama publik setelah koneksi naik, dan catat tautan mana yang menjawab masing-masing. Ketika tautan VPN membawa daftar pencarian per domain, nama privat dapat teresolusi dengan benar sementara nama publik masih menuju resolver lokal, dan pemisahan itu adalah rancangan yang bekerja, bukan kerusakan. Jika kueri privat gagal, periksa rute ke resolver sebelum menyentuh DNS lagi; jika berhasil sementara aplikasi masih gagal, aplikasi mungkin membaca resolver miliknya sendiri yang di-cache atau dikonfigurasi terpisah.

Sambungkan ulang dan pastikan keadaan terputus

Turunkan koneksi dan ulangi kedua kueri. Apa pun yang dipasang pemilik terpilih seharusnya dihapus atau dipulihkan oleh pemilik itu, bukan ditinggalkan oleh klien yang Anda bungkam. Entri per tautan yang basi dan bertahan lebih lama dari terowongan terus mengirim kueri privat ke alamat yang tidak lagi terjangkau.

Lalu sambungkan ulang dan baca lagi ketiga nilai yang sama: alamat resolver, domain pencarian, antarmuka.

Jika semuanya cocok dengan kebijakan yang Anda catat, serah terima selesai dan klien VPN bukan lagi salah satu penulisnya. Jika suatu nilai bergeser kembali beberapa detik setelah tautan naik, ada hal lain yang masih menerapkan konfigurasi, dan langkah berikutnya adalah mengenali komponen itu alih-alih menambah sakelar lagi. Keadaan akhir yang Anda inginkan tidak dramatis: satu pemilik, satu kebijakan terdokumentasi, dan host terputus yang teresolusi persis seperti sebelum terowongan ada.