NAT atau rangkaian VM jambatan: yang mana membawa trafik VPN?

Jambatan dan NAT bukan dua cara menyambungkan tetamu yang sama ke VPN anda; kedua-duanya menentukan siapa pemilik paket tetamu sebelum terowong masuk ke dalam gambaran. Dalam mod NAT, hypervisor menulis semula trafik tetamu dan menghantarnya keluar dari kod di sebelah hos, jadi tetamu mengikut laluan yang hos berikan kepada kod itu. Dalam mod jambatan, tetamu mendapat identiti lapisan pautannya sendiri pada segmen fizikal dan memilih get laluan lalai sendiri, yang menjadikan terowong hos tidak relevan kepadanya, kecuali penghala LAN yang melakukan terowong. Saya berhenti menganggap VM berada pada VPN dan mula menganggapnya sebagai persoalan ke mana laluan lalai tetamu itu menunjuk. Ujian di bawah mengambil beberapa minit setiap mod dan menyelesaikannya tanpa tekaan.

NAT menahan tetamu di belakang kod hypervisor, tempat laluan hos terpakai

Dalam VirtualBox, tetamu NAT duduk pada 10.0.2.0/24 dengan get laluan maya pada 10.0.2.2, proksi DNS pada 10.0.2.3, dan tiada laluan sendiri ke rangkaian fizikal. Paket keluar diambil oleh enjin NAT, ditulis semula supaya sumbernya ialah hos, dan diserahkan kepada tindanan IP hos. Dari situ trafik tetamu ialah aliran hos, dan carian laluan dibuat mengikut destinasi: klien terowong penuh yang memasang 0.0.0.0/1 dan 128.0.0.0/1 pada hos menangkapnya tanpa pernah tahu bahawa VM wujud. Bab rangkaian VirtualBox oleh Oracle menyenaraikan nilai lalai ini jika anda mahu mengesahkan alamat pada binaan anda.

Rangkaian lalai libvirt sampai ke tempat yang sama dari 192.168.122.0/24, tempat dnsmasq mengagihkan pajakan dan hos menyamar subnet, jadi paket tetamu datang semula kepada keputusan penghalaan hos. Pengecualian ialah klien yang memilih trafik mengikut proses dan bukan mengikut laluan. Jika senarai terowong terpisah mengandungi pelayar anda sahaja dan tiada yang lain, enjin NAT tiada dalam senarai itu, dan tetamu meninggalkan mesin tanpa terowong manakala pelayar hos masih kelihatan dilindungi. Subnet sama, hasil bertentangan.

Jambatan memberikan tetamu tempatnya sendiri pada LAN fizikal

Tetamu berjambatan diberi NIC maya yang dipasang pada penyesuai sebenar, mendapat alamat MAC sendiri, dan mengambil pajakan DHCP daripada rangkaian fizikal. Get laluan lalainya ialah penghala LAN, bukan hypervisor, dan rangkanya keluar ke wayar melalui penyesuai itu. Laluan terowong hos hidup dalam jadual hos dan tidak pernah ditanya, kerana rangka tetamu tidak pernah masuk ke tindanan IP hos.

Itu memotong kedua-dua arah. mDNS dan pelayaran SMB mula berfungsi kerana tetamu melihat trafik siaran LAN, dan tetamu menjadi boleh dicapai dari mesin lain dalam segmen yang sama tanpa tembok api hos di antaranya. Jambatan juga bukan cara untuk menolak tetamu melalui terowong sedia ada: memasang VM pada antara muka WireGuard atau OpenVPN hos bukan sesuatu yang dilakukan oleh VirtualBox atau libvirt untuk anda. Jika tetamu berjambatan perlu melalui terowong, terowong itu mesti berakhir di suatu tempat pada LAN tersebut.

Ujian yang menamatkan perdebatan

Jalankan pemeriksaan yang sama dalam kedua-dua mod dan catat jawapannya:

• Pada hos, curl -s https://ifconfig.me memberikan alamat v4 awam.
• Dalam tetamu, arahan yang sama, tambah ip route pada Linux atau Get-NetRoute -DestinationPrefix 0.0.0.0/0 pada Windows untuk get laluan lalai.
• Identiti penyelesai: resolvectl status atau cat /etc/resolv.conf dalam tetamu, untuk melihat sama ada ia menunjuk ke 10.0.2.3 atau pelayan LAN.
• Keluarga alamat: ip -6 addr show scope global dan satu permintaan v6, kerana terowong v4 tidak berkata apa-apa tentang alamat v6 global yang mungkin dimiliki tetamu.

Alamat awam yang sepadan bermakna tetamu berada pada laluan hos. Alamat tetamu yang sepadan dengan jalan keluar biasa LAN bermakna ia tidak. Langkah yang orang terlepas ialah kawalan: turunkan terowong hos dan ulangi permintaan tetamu. Jika tetamu terus melayar, ia tidak pernah bergantung pada terowong hos, apa pun yang disiratkan oleh nama mod. Dalam mod NAT, tetamu sepatutnya kehilangan internet apabila terowong hos diturunkan, kecuali klien dikonfigurasikan untuk membenarkan trafik tanpa terowong, yang sendiri wajar diketahui.

Dua isyarat berdusta. Ping yang berjaya membuktikan kebolehcapaian, bukan laluan keluar. Dan DNS boleh dijawab oleh proksi 10.0.2.3 melalui penyelesai hos sementara TCP mengambil laluan lain, dan begitulah anda mendapat halaman yang dimuatkan dan log masuk yang tidak pernah selesai.

Mod mana yang sesuai untuk kerja itu

Mod ialah keputusan penghalaan, jadi pilihnya daripada keperluan dan bukan daripada kebiasaan:

Baris pertama ialah tempat orang terperangkap: NAT dengan klien terowong penuh hos memang melindungi tetamu, tetapi hanya selagi klien berterowong mengikut laluan dan pautan atas hos ialah terowong itu. Pindahkan klien kepada senarai kebenaran untuk pelayar sahaja dan perlindungan itu hilang tanpa sebarang ralat di mana-mana. Baris keempat ialah kesilapan sebaliknya: tetamu yang dijambatkan atas kemudahan dan mula diam-diam menjawab SMB atau SSH pada LAN pejabat.

Kegagalan yang disalahkan pada VPN

Pada Windows, terjemahan NAT berjalan di dalam proses VM VirtualBox, jadi klien setiap aplikasi memerlukan imej yang tepat itu dalam senarainya dan bukan peraturan menyeluruh untuk mesin maya. Apabila kemas kini klien membina semula senarai prosesnya, tetamu NAT paling dahulu kehilangan perlindungan, dan laporannya terbaca seperti VM yang sampai ke LAN tetapi tidak ke internet sementara hos berada dalam keadaan baik.

Jambatan ke Wi-Fi ialah satu lagi klasik. Titik akses jarang meneruskan rangka dengan MAC sumber asing, jadi jambatan ke wlan0 sama ada gagal sepenuhnya atau berfungsi sehingga pengasingan klien pada AP mula menggugurkannya. VirtualBox tetap akan menawarkan penyesuai wayarles dalam senarainya. Jika hos berada pada Wi-Fi dan tetamu perlu dijambatkan, rancang untuk mengujinya dan bukan menganggapnya.

MTU ialah yang ketiga. Tetamu berjambatan mengekalkan MTU 1500 bait LAN, dan jika ia menjalankan klien WireGuard sendiri pada 1420, jabat tangan TLS besar tersekat sementara permintaan kecil berjaya. Di bawah NAT, MTU terowong hos ialah masalah hos, tetapi tetamu masih percaya pada 1500, dan UDP dengan bit don't-fragment dihidupkan hilang dengan cara yang sama.

Catat mod, kemudian semak semula selepas setiap perubahan penyesuai

Catat mod, antara muka hos yang digunakan oleh jambatan, get laluan lalai tetamu, penyelesainya, dan alamat keluarnya v4 dan v6. Rekod itulah yang menjadikan kegagalan seterusnya murah: apabila komputer riba berpindah dari dok ke Wi-Fi, tetamu berjambatan mengikut jambatan ke penyesuai fizikal lain dan mungkin mengambil pajakan semula dalam subnet lain, manakala tetamu NAT mengekalkan alamat 10.0.2.x dan diam-diam mewarisi pautan atas yang lain.

Sebelum menutup tiket, sahkan setiap satu daripada ini:

• Alamat keluar tetamu berbeza daripada alamat keluar hos, jadi ia tidak berada pada terowong hos.
• Penyelesainya ialah proksi 10.0.2.3 atau pelayan LAN, dan anda tahu yang mana menjawab.
• Tiada alamat v6 global dalam tetamu jika reka bentuk terowong hanya v4.
• Dengan terowong hos diturunkan, tetamu berhenti melayar, atau anda kini tahu ia tidak pernah bergantung padanya.
• Tetamu tidak melihat trafik siaran LAN yang bukan urusannya.