DNS tamu VirtualBox NAT rusak setelah host bergabung ke VPN

Di host Windows, nama aplikasi internal ter-resolve begitu VPN terhubung, sedangkan di dalam tamu Ubuntu tidak. Tamu mempertahankan pengaturan resolver-nya sendiri, dan adaptor NAT di depannya dapat menjawab kueri DNS dengan dua cara berbeda. Mengarahkan tamu ke resolver publik membuat situs web kembali termuat sementara nama privat tetap rusak. Karena itu jalur resolver dilacak sebelum apa pun diubah.

Lacak satu pencarian melalui adaptor NAT

Pilih satu nama internal yang sepenuhnya memenuhi syarat dan satu nama publik sebagai kontrol. Saat terowongan aktif, pastikan di host bahwa nama internal ter-resolve dan aplikasi di belakangnya terbuka. Lalu jalankan dua pencarian yang sama di dalam tamu dan bandingkan jawabannya, bukan alatnya.

Pastikan adaptor benar-benar NAT biasa sebelum melanjutkan. Adaptor bridge, jaringan NAT bernama, dan klien VPN kedua di dalam tamu masing-masing punya konfigurasi dan penjelasannya sendiri. Menebak pada titik ini membuang sisa penyelidikan.

VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natnet
resolvectl status | head -40
cat /etc/resolv.conf

Perintah pertama menampilkan mode adaptor dan jaringan NAT yang terpasang padanya. Di dalam tamu Ubuntu, perintah kedua mencantumkan pengaturan DNS per tautan, dan yang ketiga sering hanya mengungkap alamat stub lokal, yang berarti upstream sebenarnya ada di tempat lain.

Pisahkan resolusi dan keterjangkauan. Tamu yang menerima alamat benar tetapi tidak dapat membuka koneksi punya masalah perutean, penyaringan, atau izin layanan, dan perubahan DNS lebih lanjut tidak akan pernah menyentuhnya. Uji alamat secara terpisah dan catat mana dari keduanya yang gagal.

Mode proxy dan mode resolver host adalah mekanisme yang berbeda

Dalam mode proxy, mesin NAT meneruskan kueri tamu ke server DNS yang sudah dikenalnya. Dalam mode resolver host, ia mencegat kueri dan meminta sistem operasi host me-resolve nama dengan apa yang sedang digunakan host saat ini. Hanya yang kedua mengikuti klien VPN yang menulis ulang resolusi host saat terowongan naik. Karena itu kedua pengaturan menghasilkan jawaban berbeda pada mesin yang sama.

Perbedaan itu adalah seluruh masalah dalam satu kalimat. Memberi tamu daftar alamat server bukan hal yang sama dengan meminta Windows me-resolve nama melalui resolver yang dikonfigurasi, dan pada VPN dengan DNS terpisah kedua jawaban berbeda. Opsi adaptor menyangkut mekanisme, bukan izin.

Tidak ada mode yang memberikan akses ke apa pun. Otorisasi hidup dalam kebijakan VPN dan dalam layanan, dan pencarian yang berhasil hanya berarti nama berubah menjadi alamat.

Ganti adaptor, lalu verifikasi apa yang diterima tamu

Catat dulu pengaturan jaringan dan DNS VM, lalu matikan mesin agar konfigurasi persisten yang Anda edit. Untuk VM bernama work-ubuntu yang adaptor pertamanya membawa NAT, opsi per adaptor diatur dari host saat VM mati. Nyalakan lagi setelahnya dan periksa hasilnya alih-alih memercayai status keluar.

VBoxManage modifyvm work-ubuntu --natdnshostresolver1 on
VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natdns

Digit terakhir memilih nomor adaptor, jadi itu bukan nilai universal; pengaturan untuk adaptor 2 akan membawa 2 pada posisi itu. Gunakan biner VBoxManage yang sesuai dengan versi VirtualBox terpasang, karena yang lebih lama di PATH dapat menulis pengaturan yang diabaikan versi yang berjalan.

Mengaktifkan opsi proxy sebagai gantinya memilih mekanisme lain dan tidak memberi Anda perilaku resolver host. Setelah tamu menyala, periksa konfigurasi DNS yang sebenarnya dipegangnya, karena resolver yang dipatok atau pengaturan DNS terenkripsi di dalam tamu menjaga aplikasi di jalur lain terlepas dari apa yang ditawarkan adaptor.

Uji sepanjang siklus hidup VPN, bukan hanya sekali

Ulangi kedua pencarian di tamu, lalu buka aplikasi sebenarnya dan biarkan ia memvalidasi nama host TLS. Uji koneksi hanya dengan IP mengisolasi DNS dengan baik, tetapi itu bukan pemeriksaan sertifikat dan tidak boleh dilaporkan sebagai demikian. Catat nama, alamat, dan hasil aplikasi bersama-sama.

Selama jendela yang disetujui, putuskan dan sambungkan kembali VPN host lalu ulangi uji. Hasilnya harus sesuai dengan kebijakan akses, dan resolusi publik yang berfungsi lagi tidak mengatakan apa pun tentang apakah kueri privat tetap di jalur yang dimaksud.

Saat mode resolver host tidak mengubah apa pun, kembalikan nilai yang dicatat dan simpan pengamatan. Klien VPN yang mengecualikan lalu lintas hypervisor, resolver internal yang tidak terjangkau, dan pengaturan tamu yang dipatok masing-masing memerlukan koreksi berbeda, dan menjembatani adaptor mengubah desain jaringan alih-alih mereset DNS.