DNS yang didorong OpenVPN diabaikan: komponen mana yang menerapkannya

Log menunjukkan opsi yang didorong server, tunnel menyala, dan nama internal tetap gagal. Kueri langsung ke resolver menjawab, jadi servernya baik, tetapi setiap aplikasi terus menanyakan router lokal. Yang sampai ke klien adalah tawaran, bukan perubahan pada resolver, dan komponen yang memiliki resolusi nama berbeda di Linux, Windows, dan macOS. Begitu Anda memisahkan opsi dari pemiliknya, empat kesalahan mencakup hampir setiap laporan: tidak ada hook, dua hook bersaing, DNS terpisah bekerja sesuai rancangan, atau nama pendek yang butuh sufiks dan bukan server.

Opsi yang didorong adalah tawaran, bukan pemasangan

Di server, dua direktif menjabarkan niat, bukan efek:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

Klien tidak menerima resolver yang terkonfigurasi. Ia menerima variabel lingkungan, foreign_option_1 dan seterusnya, satu per baris yang didorong, dan sesuatu yang lokal harus membacanya dan menulis ulang status resolver sistem operasi. Di Linux tidak ada yang melakukannya secara bawaan, karena itu server yang benar dan klien yang tersambung masih bisa menyelesaikan nama lewat LAN.

Ada tiga tahap di antara kedua ujung: dorongan harus tiba, klien harus menampakkannya, dan hook harus menerapkannya. Baca tahap tengah di log klien dan tahap terakhir di status resolver, jangan pernah sebaliknya, karena satu baris log hanya membuktikan dua yang pertama.

Pastikan dorongan tiba dan temukan pemiliknya

Mulailah dengan menyebut peluncurnya: perintah openvpn telanjang, instans systemd, NetworkManager, atau klien vendor. Itu menentukan tempat hook bisa hidup. Di host dengan systemd-resolved, resolvectl status mendaftar setiap tautan dengan server DNS dan domain pencarian yang benar-benar dipakainya, dan tautan tunnel tidak selalu bernama tun0.

Jika alamat yang didorong muncul di log tetapi tidak di tautan mana pun, integrasinya hilang. Jika muncul di tautan dan kueri tetap keluar ke tempat lain, masalahnya adalah kueri mana yang memilih tautan itu. NetworkManager dns=dnsmasq di berkas /etc/NetworkManager/NetworkManager.conf menjalankan penerus lokal yang menerapkan DNS terpisah dengan sengaja: nama di dalam domain VPN pergi ke resolver VPN, sisanya mempertahankan jalur sebelumnya. Perilaku ini tampak seperti kesalahan ketika Anda mengharapkan seluruh lalu lintas berpindah; periksa setelan per koneksi dengan nmcli connection show "My VPN", tempat ipv4.dns dan ipv4.dns-search menyimpan nilai di balik apa yang dilaporkan perangkat, sebelum menyebutnya rusak. Jika setiap kueri memang harus mencapai resolver VPN, hapus dns=dnsmasq dari NetworkManager.conf dan mulai ulang NetworkManager, yang mengembalikan resolusi ke setelan koneksi; jika tidak, pertahankan DNS terpisah dan perbaiki daftar domain yang didorong.

Linux: serahkan opsi ke resolver

Paket distribusi menyertakan hook untuk ini, dan klien harus diizinkan menjalankannya. Susunan lazim di host tanpa systemd-resolved:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Dengan systemd-resolved, skrip resolv.conf lama mungkin tidak mengubah apa pun yang penting, karena resolver stub menyimpan status per tautan. update-systemd-resolved pembantu mendokumentasikan bentuk hook yang memakai up-restart dan down-pre, yang penting ketika antarmuka bertahan lebih lama dari satu percobaan koneksi. Apa pun pilihan Anda, satu komponen harus memiliki status itu. Menambahkan hook tak terkait di samping NetworkManager memberi dua penulis pada tautan yang sama, dan hasilnya lalu bergantung pada urutan, bukan konfigurasi Anda.

Ada juga kasus saat NetworkManager mengabaikan opsi yang didorong sepenuhnya sampai alamat server dimasukkan ke setelan IPv4 koneksi, setelah itu status resolver menunjukkan opsi itu dipakai. Layak dicoba sebelum menulis ulang skrip, karena memindahkan masalah dari hook shell ke profil koneksi yang sudah membawa tunnel.

Windows dan macOS menerapkan bagian berbeda

Klien Windows memang menyetel server DNS adaptor VPN, tetapi Windows tetap memilih antarmuka berdasarkan metrik dan tetap butuh sufiks untuk memperluas nama pendek. Pastikan status adaptor, bukan profilnya:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

Jika alamatnya hilang, setel dengan Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, lalu tambahkan sufiks ke properti IPv4 adaptor agar fileserver menjadi fileserver.corp.example. Nilai SearchList sekala mesin di bawah Tcpip\Parameters melakukan hal sama. Bila nama panjang terselesaikan dan yang telanjang tidak, resolver sudah benar dan daftar pencarian yang salah. Perbaikannya, berurutan: dorong sebuah DOMAIN agar klien mempelajari sufiks, tambahkan sufiks itu ke daftar pencarian adaptor atau koneksi, dan sebagai langkah sementara sematkan nama di hosts, atau LMHOSTS di Windows; penjelajahan NetBIOS tidak melewati router, jadi siaran yang menemukan nama pendek di LAN kantor tidak pernah mencapai klien tunnel.

block-outside-dns block-outside-dns adalah perilaku klien Windows, bukan baris profil portabel, dan menyalinnya ke profil Linux atau macOS tidak mereproduksinya di sana. Jika nama publik bekerja dan yang internal gagal di Windows, bandingkan urutan adaptor di Setelan lanjutan dengan ipconfig /all. Di macOS urutan resolver per layanan milik sistem, jadi gunakan scutil --dns untuk melihat resolver mana yang ditanya untuk domain mana, dan perlakukan setiap perbaikan profil yang dilaporkan sebagai bergantung pada klien, bukan umum.

Mesin virtual di laptop yang sama tidak mewarisi apa pun dari ini. Beri tamu entri resolver sendiri untuk domain internal, atau biarkan NAT hypervisor meneruskan kuerinya lewat host, yang hanya benar selama tunnel host menyala.

Riwayat adalah sebab ketiga. Server DNS atau setelan sufiks dari profil sebelumnya bisa bertahan melewati sambung ulang, jadi ketika adaptor tampak benar dan pencarian tetap gagal, bandingkan adaptor hidup dengan Get-VpnConnection dan hapus atau timpa entri basi sebelum menyentuh server.

Buktikan ke mana kueri pergi

Tangkapan saat satu pencarian menyelesaikan perdebatan: tcpdump -ni eth0 port 53 menunjukkan kueri di antarmuka fisik, yang berarti keluar di luar tunnel dan resolver tidak pernah diganti. dig @10.8.0.1 name.corp.example lalu memisahkan dua kasus tersisa. Jika kueri langsung menjawab, resolver bekerja dan klien tidak memakainya; jika habis waktu, resolver tak terjangkau lewat tunnel dan tidak ada perubahan lokal yang membantu.

Jika resolver yang masih dipakai adalah yang dibagikan penyedia, tunnel mengenkripsi lalu lintas sementara nama tetap terlihat oleh penyedia itu. Ini soal kebocoran, bukan fungsi, dan tangkapan yang sama menjawabnya: kueri di antarmuka fisik menuju seseorang di luar tunnel.

Keterjangkauan mencakup firewall di host VPN, yang harus mengizinkan UDP dan TCP 53 dari kumpulan. Port tertutup tampak persis seperti dorongan rusak, begitu juga resolver yang hanya menjawab dari dalam jaringan tunnel. Ulangi tangkapan setelah satu kali putus dan sambung lagi, karena setelan yang muncul pada koneksi pertama dan hilang pada koneksi kedua adalah cacat daur hidup di hook, bukan opsi yang hilang.

Pertahankan satu pemilik dan verifikasi berurutan

Skrip yang menulis ulang DNS adaptor berdasarkan dugaan status tunnel menduplikasi konfigurasi yang sudah dibawa profil, dan gagal diam-diam saat dugaan pertama kali salah. Utamakan setelan DNS koneksi itu sendiri atau satu hook terdokumentasi, dan catat mana yang Anda pilih agar orang berikutnya tidak menambah yang kedua.

Tutup lingkarannya dengan empat pemeriksaan: alamat yang didorong ada di tautan tunnel, nama internal terselesaikan sebagai nama berkualifikasi penuh, nama yang sama terselesaikan tanpa sufiks, dan keduanya masih benar setelah satu sambung ulang. Satu tangkapan memberi tahu mana dari empat yang gagal. Panduan OpenVPN 2.6 mendaftar dhcp-option dan direktif skrip dengan catatan platformnya.