Mengapa nama DNS privat gagal di klien VPN dan di mana harus memeriksa

Anda membuka laptop di kamar hotel, menjalankan klien, mengetik nama server file internal, dan tidak mendapat apa pun. Terowongan melaporkan tersambung, dan ping ke alamat di subnet yang sama masih menjawab, jadi transportnya sendiri baik-baik saja. Hanya namanya yang gagal, dan celah itu menyempitkan masalah ke dua tempat: resolver mana yang ditanyai klien dan apakah jawaban yang diterimanya bisa kembali melalui terowongan. Benahi satu dan lewati yang lain, dan kegagalannya sekadar berpindah.

Sebelum menyunting profil apa pun, pastikan apa yang dilakukan klien dengan nama tersebut. Di Linux, resolvectl query files.corp.example menunjukkan tautan dan resolver mana yang menghasilkan jawaban. Di Windows, Resolve-DnsName files.corp.example menunjukkan server yang menjawab dan alamat yang dikembalikannya.

Baca jawabannya sebelum mengubah apa pun

Jika nama kembali sebagai NXDOMAIN dalam beberapa milidetik, kueri tidak pernah mencapai zona Anda dan resolver publik atau hotel yang menjawab. Jika kembali setelah jeda panjang, ada sesuatu yang membuang port UDP 53 di jalan dan klien akhirnya beralih ke cadangan. Jika menjawab dengan alamat yang benar tetapi koneksi masih tersendat, pencariannya baik dan masalah Anda ada pada perutean atau pada layanannya sendiri.

Pembagian menjadi tiga itu menghemat satu jam menduga-duga. Ini juga memberi tahu apakah Anda perlu menyentuh VPN sama sekali: nama yang terselesaikan ke alamat privat yang benar sudah membuktikan jalur resolver, jadi sisa pekerjaannya ada di jalur data.

Bagikan resolver dari dalam terowongan

Klien terbagi menjadi dua kelompok. Satu kelompok bisa diberi resolver oleh server saat koneksi disiapkan; kelompok lain menyimpan pengaturannya di berkas lokal yang tidak bisa diubah gateway mana pun dari jarak jauh.

OpenVPN termasuk kelompok pertama. Di server, push "dhcp-option DNS 10.8.0.53" dan push "dhcp-option DOMAIN corp.example" turun melalui kanal kendali, tetapi hanya jika konfigurasi klien masih mengaktifkan pull. Klien yang disunting tangan dan membawa pull-filter ignore "dhcp-option" tidak akan pernah melihatnya, dan satu baris itu menjelaskan banyak sekali kasus «server mendorongnya tetapi laptop saya tidak setuju».

WireGuard termasuk kelompok kedua, karena protokolnya sama sekali tidak punya negosiasi opsi. Resolver dan domain pencarian masuk ke blok [Interface] milik klien sebagai DNS = 10.8.0.53, corp.example. wg-quick menerapkannya melalui resolvconf atau systemd-resolved, dan di Windows klien resmi memasang aturan NRPT yang hanya ada selama terowongan menyala: Get-DnsClientNrptPolicy mendaftarnya, sehingga itu menjadi cara cepat untuk melihat apakah klien pernah menerapkan berkas Anda.

IPsec/IKEv2 berada di antaranya. Plugin attr strongSwan dapat mengembalikan server DNS yang diambil dari kumpulan, dan klien Windows biasanya menerimanya, tetapi profil yang mematok server nama sendiri menang atas apa pun yang ditawarkan gateway. Di klien Linux langkah manual yang setara adalah resolvectl dns wg0 10.8.0.53 lalu resolvectl domain wg0 '~corp.example'; keduanya hilang bersama antarmuka, yang justru Anda inginkan untuk pengaturan yang dibatasi terowongan.

Batasi sufiksnya alih-alih menelan setiap kueri

Mengarahkan seluruh daftar resolver klien ke server internal Anda mudah dan biasanya salah. Setiap nama publik lalu diselesaikan dari jalur keluar pusat data Anda, CDN mengembalikan alamat yang jauh, dan satu gangguan resolver ikut menjatuhkan penjelajahan pengguna.

Kirim hanya sufiks privat ke dalam. Di systemd-resolved, domain yang diawali ~ hanya untuk perutean, jadi ~corp.example berarti kueri di bawah sufiks itu pergi ke server tautan tersebut sementara semua yang lain tetap memakai jaringan fisik. Windows melakukan hal yang sama dengan aturan NRPT yang dibatasi ke ruang nama, dan macOS dengan berkas resolver tambahan di bawah /etc/resolver/.

Nama multicast layak mendapat jawabannya sendiri. Nama .local bersifat link-local menurut rancangan (RFC 6762) dan antarmuka tun titik-ke-titik tidak membawa grup multicast itu, sehingga menambahkan resolver publik tidak akan menerbitkannya dan menanyakannya ke resolver unicast internal mengembalikan NXDOMAIN. Reflektor seperti avahi dalam mode reflektor dapat menjembatani dua segmen, tetapi itu keputusan di sisi server yang tidak bisa diminta klien mana pun. Jika printer atau NAS harus dapat dijangkau dengan nama, beri ia catatan A di zona Anda.

Buktikan jawabannya bisa kembali

Jawaban benar yang menunjuk ke alamat tak terjangkau terlihat persis seperti masalah resolver sampai Anda memeriksa rutenya. Tanyakan kepada kernel ke mana jawaban itu akan pergi: ip route get 10.20.5.20 menyebut antarmuka dan, lebih berguna, alamat sumber yang akan dipakainya.

Perhatikan alamat resolver itu sendiri. Klien dengan DNS = 10.8.0.53 di samping AllowedIPs = 10.20.0.0/16 mengirim kuerinya lewat NIC fisik, tempat kueri itu mati diam-diam, karena resolver tidak berada di dalam prefiks mana pun yang diklaim terowongan. Ketidakcocokan itu adalah kegagalan satu-sebab paling umum di seluruh bidang ini, dan tak terlihat kecuali Anda membandingkan pengaturan DNS dengan prefiks yang diizinkan baris demi baris.

Rentang yang tumpang tindih menyebabkan kegagalan sebaliknya. Jawabannya benar, rutenya ada, dan ia menunjuk ke host yang salah, karena 192.168.0.0/24 di rumah lebih spesifik daripada rute terowongan ke rentang yang sama. Nomori ulang satu sisi atau dorong rute yang lebih sempit, lalu pastikan firewall dan jalur balik host layanannya; catatan strongSwan tentang penerusan mencakup sisi sysctl jalur itu.

Sertifikat adalah pemeriksaan identitas terpisah yang orang-orang salahkan ke DNS. Jika peramban melaporkan ketidakcocokan nama alih-alih galat resolusi, pencariannya sudah berhasil dan SAN pada sertifikatlah yang perlu diperbaiki. Uji HTTPS terhadap nama, jangan pernah terhadap IP telanjang.

Uji ulang dari klien, bukan dari gateway

Uji di dalam aplikasi yang dikeluhkan pengguna, karena pencarian di baris perintah tidak membuktikan peramban menempuh jalur yang sama. DNS aman Chrome dan network.trr.mode Firefox dapat melewati resolver sistem sepenuhnya, dan bila itu terjadi, nama privat gagal atau bocor ke resolver publik. Membandingkan resolvectl query dengan dig @10.8.0.53 files.corp.example yang dijalankan tangan memberi tahu Anda mana dari keduanya yang terjadi.

Lalu putuskan dan sambungkan kembali sebelum menyebutnya beres. Pengaturan yang dipasang tangan pada antarmuka hilang bersama antarmuka, dan profil yang tampak benar hanya karena suntingan lokal yang terlupa akan gagal saat boot berikutnya.

Daftar periksa singkat untuk mesin berikutnya: nama terselesaikan melalui resolver terowongan, sufiksnya dibatasi alih-alih global, alamat resolver berada di dalam prefiks yang diizinkan, host dari jawaban menjawab di port layanan, dan sertifikat mencakup nama yang diketik pengguna.