DNS yang ditolak oleh OpenVPN diabaikan: komponen mana yang menggunakannya

Log menunjukkan pilihan yang ditolak oleh pelayan, terowong aktif, dan nama dalaman masih gagal. Pertanyaan terus kepada penyelesai menjawab, jadi pelayan itu betul, tetapi setiap aplikasi terus bertanya kepada penghala setempat. Apa yang sampai kepada klien ialah tawaran, bukan perubahan pada penyelesai, dan komponen yang memiliki penyelesaian nama berbeza pada Linux, Windows dan macOS. Sebaik sahaja anda memisahkan pilihan itu daripada pemiliknya, empat kerosakan meliputi hampir setiap laporan: tiada cangkuk, dua cangkuk bersaing, DNS berpecah berfungsi seperti direka, atau nama pendek yang memerlukan akhiran dan bukan pelayan.

Pilihan yang ditolak ialah tawaran, bukan pemasangan

Pada pelayan, dua arahan menerangkan niat, bukan kesan:

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

Klien tidak menerima penyelesai yang dikonfigurasikan. Ia menerima pemboleh ubah persekitaran, foreign_option_1 dan seterusnya, satu bagi setiap baris yang ditolak, dan sesuatu yang setempat mesti membacanya dan menulis semula keadaan penyelesai sistem pengendalian. Pada Linux tiada apa-apa yang berbuat demikian secara lalai, sebab itu pelayan yang betul dan klien yang bersambung masih boleh menyelesaikan nama melalui LAN.

Tiga peringkat terletak antara kedua-dua hujung: tolakan mesti tiba, klien mesti mendedahkannya, dan cangkuk mesti menggunakannya. Baca peringkat tengah dalam log klien dan peringkat terakhir dalam keadaan penyelesai, jangan sekali-kali sebaliknya, kerana satu baris log hanya membuktikan dua yang pertama.

Pastikan tolakan tiba dan cari pemiliknya

Mulakan dengan menamakan pelancar: arahan openvpn kosong, satu contoh systemd, NetworkManager atau klien vendor. Itu menentukan di mana cangkuk boleh tinggal. Pada hos dengan systemd-resolved, resolvectl status menyenaraikan setiap pautan dengan pelayan DNS dan domain carian yang benar-benar digunakannya, dan pautan terowong tidak selalu bernama tun0.

Jika alamat yang ditolak muncul dalam log tetapi tiada pada mana-mana pautan, integrasi itu hilang. Jika ia muncul pada pautan dan pertanyaan masih keluar di tempat lain, masalahnya ialah pertanyaan mana yang memilih pautan itu. NetworkManager dns=dnsmasq dalam fail /etc/NetworkManager/NetworkManager.conf menjalankan penghantar setempat yang melaksanakan DNS berpecah dengan sengaja: nama dalam domain VPN pergi ke penyelesai VPN, segala-galanya mengekalkan laluan sebelumnya. Tingkah laku ini kelihatan seperti kerosakan apabila anda menjangka semua trafik akan berpindah; semak tetapan setiap sambungan dengan nmcli connection show "My VPN", di mana ipv4.dns dan ipv4.dns-search memegang nilai di sebalik apa yang dilaporkan peranti, sebelum menyebutnya rosak. Jika setiap pertanyaan benar-benar harus sampai ke penyelesai VPN, buang dns=dnsmasq daripada NetworkManager.conf dan mulakan semula NetworkManager, yang mengembalikan penyelesaian nama kepada tetapan sambungan; jika tidak, kekalkan DNS berpecah dan betulkan senarai domain yang ditolak.

Linux: serahkan pilihan kepada penyelesai

Pakej pengedaran menyediakan cangkuk untuk ini, dan klien mesti dibenarkan menjalankannya. Susunan lazim pada hos 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-apa yang penting, kerana penyelesai stub menyimpan keadaan bagi setiap pautan. update-systemd-resolved pembantu mendokumenkan bentuk cangkuk yang menggunakan up-restart dan down-pre, yang penting apabila antara muka hidup lebih lama daripada satu percubaan sambungan. Apa pun yang anda pilih, satu komponen mesti memiliki keadaan itu. Menambah cangkuk tidak berkaitan di sebelah NetworkManager memberi dua penulis kepada pautan yang sama, dan hasilnya bergantung pada urutan dan bukan pada konfigurasi anda.

Ada juga kes di mana NetworkManager mengabaikan pilihan yang ditolak sepenuhnya sehingga alamat pelayan dimasukkan dalam tetapan IPv4 sambungan, kemudian keadaan penyelesai menunjukkan ia sedang digunakan. Layak dicuba sebelum menulis semula skrip, kerana ia memindahkan masalah daripada cangkuk shell kepada profil sambungan yang sudah membawa terowong.

Windows dan macOS menggunakan bahagian berbeza

Klien Windows memang menetapkan pelayan DNS penyesuai VPN, tetapi Windows masih memilih antara muka mengikut metrik dan masih memerlukan akhiran untuk mengembangkan nama pendek. Sahkan keadaan penyesuai dan bukan profil:

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

Jika alamat tiada, tetapkannya dengan Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, kemudian tambah akhiran itu pada sifat IPv4 penyesuai supaya fileserver menjadi fileserver.corp.example. Nilai SearchList seluruh mesin di bawah Tcpip\Parameters melakukan perkara yang sama. Di mana nama panjang diselesaikan dan nama kosong tidak, penyelesai sudah betul dan senarai carian yang salah. Pembetulan, mengikut urutan: tolak DOMAIN supaya klien mempelajari akhiran, tambah akhiran itu pada senarai carian penyesuai atau sambungan, dan sebagai langkah sementara pin nama itu dalam hosts, atau LMHOSTS pada Windows; pelayaran NetBIOS tidak melintasi penghala, jadi siaran yang menemui nama pendek pada LAN pejabat tidak pernah sampai kepada klien terowong.

block-outside-dns block-outside-dns ialah tingkah laku klien Windows, bukan baris profil mudah alih, dan menyalinnya ke profil Linux atau macOS tidak menghasilkannya di sana. Jika nama awam berfungsi dan nama dalaman gagal pada Windows, bandingkan urutan penyesuai di bawah Tetapan lanjutan dengan ipconfig /all. Pada macOS urutan penyelesai bagi setiap perkhidmatan milik sistem, jadi gunakan scutil --dns untuk melihat penyelesai mana yang ditanya bagi domain mana, dan layan mana-mana pembetulan profil tunggal yang dilaporkan sebagai bergantung pada klien dan bukan umum.

Mesin maya pada komputer riba yang sama tidak mewarisi apa-apa daripada ini. Berikan tetamu entri penyelesai sendiri untuk domain dalaman, atau biarkan NAT hipervisor menghantar pertanyaannya melalui hos, yang hanya betul selagi terowong hos aktif.

Sejarah ialah punca ketiga. Pelayan DNS atau tetapan akhiran daripada profil terdahulu boleh bertahan melalui sambungan semula, jadi apabila penyesuai kelihatan betul dan carian masih gagal, bandingkan penyesuai hidup dengan Get-VpnConnection dan padam atau tulis ganti entri usang sebelum anda menyentuh pelayan.

Buktikan ke mana pertanyaan itu pergi

Tangkapan semasa satu carian menyelesaikan perdebatan: tcpdump -ni eth0 port 53 menunjukkan pertanyaan pada antara muka fizikal, yang bermaksud ia keluar di luar terowong dan penyelesai tidak pernah ditukar. dig @10.8.0.1 name.corp.example kemudian memisahkan dua kes yang tinggal. Jika pertanyaan langsung menjawab, penyelesai berfungsi dan klien tidak menggunakannya; jika ia tamat masa, penyelesai tidak dapat dicapai melalui terowong dan tiada perubahan setempat akan membantu.

Jika penyelesai yang masih digunakan ialah yang diberikan oleh pembekal, terowong menyulitkan trafik manakala nama kekal kelihatan kepada pembekal itu. Ini persoalan kebocoran dan bukan fungsi, dan tangkapan yang sama menjawabnya: pertanyaan pada antara muka fizikal pergi kepada seseorang di luar terowong.

Kebolehcapaian termasuk tembok api pada hos VPN, yang mesti membenarkan UDP dan TCP 53 daripada kumpulan. Port yang disekat kelihatan sama seperti tolakan yang rosak, dan begitu juga penyelesai yang hanya menjawab dari dalam rangkaian terowong. Ulangi tangkapan selepas satu kali putus dan sambung semula, kerana tetapan yang muncul pada sambungan pertama dan hilang pada yang kedua ialah kerosakan kitaran hayat dalam cangkuk, bukan pilihan yang hilang.

Kekalkan satu pemilik dan sahkan mengikut urutan

Skrip yang menulis semula DNS penyesuai berdasarkan keadaan terowong yang diandaikan menduplikasi konfigurasi yang sudah dibawa profil, dan ia gagal secara senyap pada kali pertama andaian itu salah. Utamakan tetapan DNS sambungan itu sendiri atau satu cangkuk yang didokumenkan, dan catat mana yang anda pilih supaya orang seterusnya tidak menambah yang kedua.

Tutup gelung dengan empat semakan: alamat yang ditolak hadir pada pautan terowong, nama dalaman diselesaikan sebagai nama yang layak sepenuhnya, nama yang sama diselesaikan tanpa akhiran, dan kedua-duanya masih benar selepas satu sambungan semula. Satu tangkapan memberitahu anda yang mana antara empat itu gagal. Manual OpenVPN 2.6 menyenaraikan dhcp-option dan arahan skrip dengan nota platformnya.