Nama internal gagal di VPN sementara situs publik tetap terbuka

Seorang pengguna melaporkan bahwa nama host intranet tidak terurai melalui VPN. Laporan kedua, dari laptop yang sama, mengatakan uji kebocoran masih menunjukkan kueri dijawab oleh resolver lokal. Keduanya terdengar seperti satu masalah, padahal dua, dengan bukti berbeda, dan perbaikan biasa untuk yang pertama memperburuk yang kedua. Pisahkan keduanya sebelum menyentuh pengaturan apa pun.

Dua gejala yang bukan satu kesalahan

Gagal menguraikan nama internal berarti pertanyaan pergi ke tempat yang tidak punya jawabannya. Kueri yang keluar dari terowongan berarti pertanyaan pergi ke tempat yang salah bahkan ketika jawabannya tersedia. Keduanya kegagalan yang berlawanan: satu jawaban hilang, yang lain tujuan berlebih.

Jebakannya adalah menambahkan resolver kantor di mana-mana memperbaiki yang pertama dan menjamin yang kedua. Menambahkan resolver publik di mana-mana melakukan sebaliknya.

Catat kedua pengamatan dengan stempel waktu, lalu jalankan empat pemeriksaan di bawah ini secara berurutan.

Resolver adaptor mana yang menerima pertanyaan

Di Windows, klien DNS memilih server menurut urutan pengikatan adaptor, dan adaptor terowongan tidak otomatis menjadi yang pertama. Buka pengaturan lanjutan adaptor dan pindahkan koneksi akses jarak jauh di atas adaptor fisik, lalu sambungkan ulang agar perubahan berlaku pada sesi baru.

Urutan pengikatan hanya separuh pertama. Klien juga harus tahu nama mana yang menjadi milik adaptor itu, dan itu pertanyaan sufiks, bukan pertanyaan urutan.

Letakkan keluaran ipconfig /all dari mesin yang berfungsi di samping keluaran laptop, keduanya diambil saat terowongan aktif. Mesin yang berfungsi akan menunjukkan sufiks DNS khusus koneksi pada adaptor kantornya, sedangkan laptop mungkin tidak menunjukkan apa pun pada terowongan. Perbedaan itu menjelaskan seluruh kelas laporan yang mengatakan servernya ada di sana dan namanya tetap gagal, karena tanpa sufiks nama pendek tidak pernah dilengkapi ke zona yang dilayani resolver kantor.

Nama pendek butuh sufiks sebelum butuh rute

Mengetik nama host tanpa kualifikasi meminta resolver menebak domain. Tebakan itu datang dari daftar sufiks yang terpasang pada koneksi, dan jika daftar itu kosong kueri keluar sebagai satu label yang tidak akan cocok dengan zona privat mana pun.

Salin sufiks mesin yang berfungsi ke properti IPv4 adaptor VPN pada tab DNS, lalu sambungkan ulang. Di Linux padanannya adalah domain pencarian pada tautan terowongan, yang ditampilkan systemd-resolved per tautan, bukan secara global.

Pisahkan kedua pengaturan dalam catatan Anda. Sufiks mengubah apa yang ditanyakan; alamat resolver mengubah siapa yang ditanya. Memperbaiki satu sementara yang lain salah menghasilkan hasil yang tampak acak.

Tanya resolver secara langsung, lalu namanya

Kueri langsung ke resolver kantor memisahkan masalah nama dari masalah jalur, karena melewati sepenuhnya pemilihan resolver oleh klien.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Perintah pertama menanyakan nama yang sepenuhnya memenuhi syarat ke server tertentu. Jika menjawab, resolver dan rute ke sana baik-baik saja dan kesalahannya ada pada pemilihan atau sufiks. Jika waktu habis, alamatnya salah atau tidak dapat dijangkau dan masalahnya pada perutean, bukan DNS. Perintah kedua menunjukkan apa yang terjadi dengan nama pendek, dan yang ketiga mencetak konfigurasi resolver per tautan pada host systemd.

Perhatikan jawaban wildcard, yang dikembalikan sebagian jaringan untuk nama tak dikenal. Jawaban yang tampak masuk akal bukan bukti bahwa server yang dimaksud menjawab, jadi bandingkan alamat yang dikembalikan dengan alamat yang benar-benar dipakai layanan internal. Jika alamat itu milik halaman parkir atau proksi, resolver menjawab tetapi jawabannya tidak pernah milik Anda. Perbedaan itu menghemat satu jam mengejar terowongan yang sebenarnya berfungsi sepanjang waktu.

Di Linux, klien VPN yang menulis ulang /etc/resolv.conf sepenuhnya menggantikan resolver lokal. vpnc menampilkan DNSUpdate no untuk menghentikannya, dan systemd-resolved hanya dapat mengarahkan domain yang terdaftar ke tautan terowongan. Kedua pendekatan menjaga nama publik pada resolver lokal sambil mengirim nama internal ke kantor.

Kebocoran adalah aturan, bukan kotak centang

Resolusi nama adalah pertukaran UDP ke port 53, jadi terowongan yang membawa lalu lintas web tetapi bukan UDP meninggalkan kueri di jalur fisik. Buktikan dengan menangkap paket di NIC fisik saat nama publik diuraikan. Kueri yang terlihat di antarmuka itu dalam bentuk terbaca berarti terowongan tidak membawanya.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Jika kueri muncul di antarmuka itu dalam bentuk terbaca, terowongan tidak membawanya. Perbaikannya adalah aturan yang mengizinkan port 53 hanya ke resolver yang didorong VPN dan membuang tujuan lain, ditambah konfigurasi klien yang tidak diam-diam membuang opsi yang didorong.

Bagian terakhir itu lebih penting daripada kelihatannya. Jalankan OpenVPN dengan route-nopull dan opsi DNS yang didorong hilang bersama rute, kecuali filter tarik diperlebar untuk mempertahankannya. dan klien yang mengabaikan dhcp-option DNS akan terus memakai apa yang sudah dimilikinya sebelumnya. Setiap perubahan di sisi server membutuhkan sesi baru agar berlaku, karena daftar resolver dikirim saat terowongan naik dan sesi yang basi terus menunjukkan keadaan lama.

Catat kegagalan mana yang benar-benar Anda amati sebelum menutup tiket. Jawaban internal yang hilang dan kueri yang lolos dari terowongan menuntut perbaikan berbeda, dan perubahan sufiks yang memperbaiki yang pertama dapat diam-diam memperburuk yang kedua. Orang berikutnya yang mengambil tiket akan mempercayai label, jadi buat labelnya akurat.