NAT atau jaringan VM bridge: mana yang membawa lalu lintas VPN?

Bridge dan NAT bukan dua cara menyambungkan tamu yang sama ke VPN Anda; keduanya menentukan siapa pemilik paket tamu sebelum ada tunnel yang terlibat. Dalam mode NAT, hypervisor menulis ulang lalu lintas tamu dan mengirimkannya dari kode sisi host, sehingga tamu mengikuti rute apa pun yang host berikan kepada kode itu. Dalam mode bridge, tamu mendapat identitas lapisan tautan sendiri di segmen fisik dan memilih gateway default-nya sendiri, yang membuat tunnel host tidak relevan baginya, kecuali router LAN-lah yang melakukan tunneling. Saya berhenti menganggap VM sebagai berada di VPN dan mulai memperlakukannya sebagai pertanyaan tentang ke mana rute default tamu itu menunjuk. Uji di bawah memakan beberapa menit per mode dan menyelesaikannya tanpa dugaan.

NAT menahan tamu di balik kode hypervisor, tempat rute host berlaku

Di VirtualBox, tamu NAT duduk di 10.0.2.0/24 dengan gateway virtual di 10.0.2.2, proxy DNS di 10.0.2.3, dan tidak punya rute sendiri ke jaringan fisik. Paket keluar diambil mesin NAT, ditulis ulang agar sumbernya host, lalu diteruskan ke tumpukan IP host. Dari sana lalu lintas tamu adalah aliran host, dan pencarian rute dilakukan berdasarkan tujuan: klien tunnel penuh yang memasang 0.0.0.0/1 dan 128.0.0.0/1 di host menangkapnya tanpa pernah tahu ada VM. Bab jaringan VirtualBox dari Oracle mencantumkan default ini jika Anda ingin memastikan alamatnya di build Anda.

Jaringan default libvirt mencapai tempat yang sama dari 192.168.122.0/24, tempat dnsmasq membagikan sewa dan host melakukan masquerade subnet, sehingga paket tamu kembali tiba di keputusan routing host. Pengecualiannya adalah klien yang memilih lalu lintas berdasarkan proses, bukan rute. Jika daftar split-tunnel hanya berisi peramban Anda dan tidak ada yang lain, mesin NAT tidak ada di daftar itu, dan tamu meninggalkan mesin tanpa tunnel sementara peramban host masih tampak tercakup. Subnet sama, hasil berlawanan.

Bridge memberi tamu tempatnya sendiri di LAN fisik

Tamu bridge diberi NIC virtual yang terpasang ke adaptor nyata, mendapat alamat MAC sendiri, dan mengambil sewa DHCP dari jaringan fisik. Gateway default-nya adalah router LAN, bukan hypervisor, dan frame-nya keluar ke kabel melalui adaptor itu. Rute tunnel host tinggal di tabel host dan tidak pernah ditanyai, karena frame tamu tidak pernah masuk ke tumpukan IP host.

Itu memotong dua arah. mDNS dan penjelajahan SMB mulai berfungsi karena tamu melihat lalu lintas siaran LAN, dan tamu menjadi terjangkau dari mesin lain di segmen yang sama tanpa firewall host di antaranya. Bridge juga bukan cara mendorong tamu melewati tunnel yang sudah ada: memasang VM ke antarmuka WireGuard atau OpenVPN host bukan sesuatu yang dilakukan VirtualBox atau libvirt untuk Anda. Jika tamu bridge harus lewat tunnel, tunnel harus berakhir di suatu tempat di LAN itu.

Uji yang mengakhiri perdebatan

Jalankan pemeriksaan yang sama di kedua mode dan catat jawabannya:

• Di host, curl -s https://ifconfig.me memberi alamat v4 publik.
• Di tamu, perintah yang sama, ditambah ip route di Linux atau Get-NetRoute -DestinationPrefix 0.0.0.0/0 di Windows untuk gateway default.
• Identitas resolver: resolvectl status atau cat /etc/resolv.conf di tamu, untuk melihat apakah mengarah ke 10.0.2.3 atau ke server LAN.
• Keluarga alamat: ip -6 addr show scope global dan satu permintaan v6, karena tunnel v4 tidak mengatakan apa pun tentang alamat v6 global yang mungkin dimiliki tamu.

Alamat publik yang cocok berarti tamu berada di jalur host. Alamat tamu yang cocok dengan jalan keluar biasa LAN berarti tidak. Langkah yang orang lewatkan adalah kontrol: turunkan tunnel host dan ulangi permintaan tamu. Jika tamu terus menjelajah, ia tidak pernah bergantung pada tunnel host, apa pun yang disiratkan nama mode. Dalam mode NAT, tamu seharusnya kehilangan internet saat tunnel host turun, kecuali klien dikonfigurasi untuk mengizinkan lalu lintas tanpa tunnel, yang layak diketahui sendiri.

Dua sinyal berbohong. Ping yang berhasil membuktikan keterjangkauan, bukan jalur keluar. Dan DNS bisa dijawab proxy 10.0.2.3 melalui resolver host sementara TCP mengambil rute lain, dan begitulah Anda mendapat halaman yang termuat dan login yang tidak pernah selesai.

Mode mana yang cocok untuk pekerjaan itu

Mode adalah keputusan routing, jadi pilihlah dari kebutuhan, bukan dari kebiasaan:

Baris pertama adalah tempat orang tertangkap: NAT plus klien tunnel penuh di host memang mencakup tamu, tetapi hanya selama klien menerowongkan berdasarkan rute dan uplink host adalah tunnel itu. Pindahkan klien ke daftar izin hanya untuk peramban dan cakupan hilang tanpa kesalahan apa pun di mana pun. Baris keempat adalah kesalahan sebaliknya: tamu yang di-bridge demi kenyamanan lalu diam-diam mulai menjawab SMB atau SSH di LAN kantor.

Kegagalan yang dituduhkan ke VPN

Di Windows, terjemahan NAT berjalan di dalam proses VM VirtualBox, jadi klien per aplikasi memerlukan image persis itu di daftarnya, bukan aturan menyeluruh untuk mesin virtual. Ketika pembaruan klien membangun ulang daftar prosesnya, tamu NAT paling dulu kehilangan cakupan, dan laporannya terbaca seperti VM yang bisa mencapai LAN tetapi tidak internet sementara host baik-baik saja.

Bridge ke Wi-Fi adalah klasik lainnya. Titik akses jarang meneruskan frame dengan MAC sumber asing, sehingga bridge ke wlan0 entah gagal sama sekali atau berfungsi sampai isolasi klien di AP mulai menjatuhkannya. VirtualBox tetap akan menawarkan adaptor nirkabel di daftarnya. Jika host di Wi-Fi dan tamu harus di-bridge, rencanakan untuk mengujinya daripada menganggapnya.

MTU adalah yang ketiga. Tamu bridge mempertahankan MTU 1500 byte LAN, dan jika ia menjalankan klien WireGuard sendiri pada 1420, jabat tangan TLS besar macet sementara permintaan kecil berhasil. Di bawah NAT, MTU tunnel host adalah masalah host, tetapi tamu tetap percaya pada 1500, dan UDP dengan bit don't-fragment menyala menghilang dengan cara yang sama.

Catat mode, lalu periksa ulang setelah setiap perubahan adaptor

Catat mode, antarmuka host yang dipakai bridge, gateway default tamu, resolver-nya, serta alamat keluar v4 dan v6-nya. Catatan itulah yang membuat kegagalan berikutnya murah: ketika laptop berpindah dari dock ke Wi-Fi, tamu bridge mengikuti bridge ke adaptor fisik lain dan bisa menyewa ulang ke subnet lain, sementara tamu NAT mempertahankan alamat 10.0.2.x dan diam-diam mewarisi uplink lain.

Sebelum menutup tiket, pastikan setiap hal berikut:

• Alamat keluar tamu berbeda dari alamat keluar host, jadi ia tidak berada di tunnel host.
• Resolver-nya adalah proxy 10.0.2.3 atau server LAN, dan Anda tahu mana yang menjawab.
• Tidak ada alamat v6 global di tamu jika rancangan tunnel hanya v4.
• Dengan tunnel host turun, tamu berhenti menjelajah, atau Anda sekarang tahu ia tidak pernah bergantung padanya.
• Tamu tidak melihat lalu lintas siaran LAN yang bukan urusannya.