Mengapa nama DNS peribadi gagal pada klien VPN dan di mana perlu diperiksa

Anda membuka komputer riba di bilik hotel, memulakan klien, menaip nama pelayan fail dalaman, dan tidak mendapat apa-apa. Terowong melaporkan bersambung, dan ping ke alamat dalam subnet yang sama masih menjawab, jadi pengangkutan itu sendiri baik. Hanya namanya yang gagal, dan jurang itu menyempitkan masalah kepada dua tempat: penyelesai mana yang ditanya oleh klien dan sama ada jawapan yang diterimanya boleh kembali melalui terowong. Betulkan satu dan langkau yang lain, dan kegagalan itu hanya berpindah.

Sebelum menyunting mana-mana profil, sahkan apa yang klien lakukan dengan nama itu. Pada Linux, resolvectl query files.corp.example menunjukkan pautan dan penyelesai mana yang menghasilkan jawapan. Pada Windows, Resolve-DnsName files.corp.example menunjukkan pelayan yang menjawab dan alamat yang dikembalikannya.

Baca jawapan sebelum mengubah apa pun

Jika nama kembali sebagai NXDOMAIN dalam beberapa milisaat, pertanyaan itu tidak pernah sampai ke zon anda dan penyelesai awam atau hotel yang menjawab. Jika ia kembali selepas jeda panjang, ada sesuatu yang membuang port UDP 53 di jalan dan klien akhirnya beralih ke sandaran. Jika ia menjawab dengan alamat yang betul tetapi sambungan masih tersekat, pencarian itu baik dan masalah anda terletak pada penghalaan atau pada perkhidmatan itu sendiri.

Pembahagian kepada tiga itu menjimatkan satu jam meneka. Ia juga memberitahu sama ada anda perlu menyentuh VPN langsung: nama yang diselesaikan ke alamat peribadi yang betul sudah membuktikan laluan penyelesai, jadi kerja yang tinggal berada pada laluan data.

Edarkan penyelesai dari dalam terowong

Klien terbahagi kepada dua kumpulan. Satu kumpulan boleh diberi penyelesai oleh pelayan semasa sambungan disediakan; kumpulan lain menyimpan tetapan itu dalam fail setempat yang tidak boleh diubah oleh mana-mana get laluan dari jauh.

OpenVPN tergolong dalam kumpulan pertama. Pada pelayan, push "dhcp-option DNS 10.8.0.53" dan push "dhcp-option DOMAIN corp.example" turun melalui saluran kawalan, tetapi hanya jika konfigurasi klien masih mengaktifkan pull. Klien yang disunting dengan tangan dan membawa pull-filter ignore "dhcp-option" tidak akan pernah melihatnya, dan satu baris itu menjelaskan banyak sekali kes «pelayan menolaknya tetapi komputer riba saya tidak bersetuju».

WireGuard tergolong dalam kumpulan kedua, kerana protokol itu langsung tidak mempunyai rundingan pilihan. Penyelesai dan domain carian masuk ke blok [Interface] klien itu sendiri sebagai DNS = 10.8.0.53, corp.example. wg-quick menerapkannya melalui resolvconf atau systemd-resolved, dan pada Windows klien rasmi memasang peraturan NRPT yang wujud hanya selagi terowong naik: Get-DnsClientNrptPolicy menyenaraikannya, yang menjadikannya cara pantas untuk melihat sama ada klien pernah menerapkan fail anda.

IPsec/IKEv2 terletak di tengah-tengah. Pemalam attr strongSwan boleh memulangkan pelayan DNS yang diambil daripada kumpulan, dan klien Windows biasanya menerimanya, tetapi profil yang memakukan pelayan namanya sendiri mengalahkan apa sahaja yang ditawarkan get laluan. Pada klien Linux langkah manual yang setara ialah resolvectl dns wg0 10.8.0.53 diikuti oleh resolvectl domain wg0 '~corp.example'; kedua-duanya hilang bersama antara muka, yang memang itulah yang anda mahukan untuk tetapan yang terbatas kepada terowong.

Bataskan akhiran itu daripada menelan setiap pertanyaan

Mengarahkan seluruh senarai penyelesai klien ke pelayan dalaman anda mudah dan biasanya salah. Setiap nama awam kemudian diselesaikan dari jalan keluar pusat data anda, CDN memulangkan alamat yang jauh, dan satu gangguan penyelesai turut menjatuhkan pelayaran pengguna.

Hantar hanya akhiran peribadi ke dalam. Pada systemd-resolved, domain yang bermula dengan ~ hanya untuk penghalaan, jadi ~corp.example bermaksud pertanyaan di bawah akhiran itu pergi ke pelayan pautan tersebut sementara segala-galanya masih menggunakan rangkaian fizikal. Windows melakukan perkara yang sama dengan peraturan NRPT yang terbatas kepada ruang nama, dan macOS dengan fail penyelesai tambahan di bawah /etc/resolver/.

Nama multicast berhak mendapat jawapannya sendiri. Nama .local adalah link-local mengikut reka bentuk (RFC 6762) dan antara muka tun titik-ke-titik tidak membawa kumpulan multicast itu, jadi menambah penyelesai awam tidak akan menerbitkannya dan bertanya kepada penyelesai unicast dalaman tentangnya memulangkan NXDOMAIN. Pemantul seperti avahi dalam mod pemantul boleh menjambatani dua segmen, tetapi itu keputusan di sebelah pelayan yang tidak boleh diminta oleh mana-mana klien. Jika pencetak atau NAS mesti boleh dicapai dengan nama, berikan ia rekod A dalam zon anda.

Buktikan jawapan itu boleh kembali

Jawapan betul yang menunjuk ke alamat yang tidak dapat dicapai kelihatan sama seperti masalah penyelesai sehingga anda memeriksa laluannya. Tanya kernel ke mana jawapan itu akan pergi: ip route get 10.20.5.20 menamakan antara muka dan, lebih berguna, alamat sumber yang akan digunakannya.

Perhatikan alamat penyelesai itu sendiri. Klien dengan DNS = 10.8.0.53 di sebelah AllowedIPs = 10.20.0.0/16 menghantar pertanyaannya keluar melalui NIC fizikal, di mana ia mati secara senyap, kerana penyelesai itu tidak berada dalam mana-mana prefiks yang dituntut terowong. Ketidakpadanan itu ialah kegagalan satu-punca yang paling biasa di seluruh bidang ini, dan ia tidak kelihatan melainkan anda membandingkan tetapan DNS dengan prefiks yang dibenarkan baris demi baris.

Julat yang bertindih menyebabkan kegagalan sebaliknya. Jawapannya betul, laluannya wujud, dan ia menunjuk ke hos yang salah, kerana 192.168.0.0/24 di rumah lebih spesifik daripada laluan terowong ke julat yang sama. Nomborkan semula satu pihak atau tolak laluan yang lebih sempit, kemudian sahkan tembok api dan laluan balik hos perkhidmatannya; nota strongSwan tentang pemajuan merangkumi sebelah sysctl laluan itu.

Sijil ialah pemeriksaan identiti berasingan yang orang salahkan pada DNS. Jika pelayar melaporkan ketidakpadanan nama dan bukannya ralat penyelesaian, pencarian itu sudah berjaya dan SAN pada sijil itulah yang perlu dibaiki. Uji HTTPS terhadap nama, jangan sekali-kali terhadap IP telanjang.

Uji semula dari klien, bukan dari get laluan

Uji di dalam aplikasi yang diadukan pengguna, kerana pencarian di baris perintah tidak membuktikan pelayar menempuh laluan yang sama. DNS selamat Chrome dan network.trr.mode Firefox boleh memintas penyelesai sistem sepenuhnya, dan apabila ia berbuat demikian, nama peribadi sama ada gagal atau bocor ke penyelesai awam. Membandingkan resolvectl query dengan dig @10.8.0.53 files.corp.example yang dijalankan dengan tangan memberitahu anda yang mana satu daripada kedua-duanya berlaku.

Kemudian putuskan dan sambung semula sebelum mengisytiharkannya selesai. Tetapan yang dipasang dengan tangan pada antara muka hilang bersama antara muka, dan profil yang hanya kelihatan betul kerana suntingan setempat yang terlupa akan gagal pada but seterusnya.

Senarai semak ringkas untuk mesin seterusnya: nama diselesaikan melalui penyelesai terowong, akhiran itu terbatas dan bukan global, alamat penyelesai berada di dalam prefiks yang dibenarkan, hos daripada jawapan menjawab pada port perkhidmatan, dan sijil merangkumi nama yang ditaip pengguna.