Mengapa VPN tamu Anda gagal di balik NAT VirtualBox?

Browser di dalam mesin virtual berfungsi, dan klien VPN pada tamu yang sama tidak dapat membawa data. Tamu jelas memiliki konektivitas, jadi kegagalan terletak pada apa yang dibutuhkan protokol luar VPN dan apa yang akan diteruskan NAT virtual. Tiga kondisi menentukan hasilnya: proses mana yang memiliki VPN, bagaimana pertukaran luar terlihat di kabel, dan apakah mode adaptor adalah yang Anda pikirkan. Menamai kondisi yang dapat Anda ubah adalah seluruh keputusannya.

Temukan proses VPN sebelum menyalahkan jaringan

Tentukan dulu apakah VPN berjalan di dalam tamu atau di host, karena kedua susunan gagal secara berbeda. Klien di dalam tamu membangun koneksi luarnya sendiri melalui adaptor tamu dan terjemahan apa pun di belakangnya. VPN host menangkap lalu lintas tamu menurut kebijakan host dan hypervisor, yang merupakan titik tangkap terpisah dengan aturannya sendiri. Keduanya dapat berjalan bersamaan dan mengaburkan bukti, jadi identifikasi mana yang seharusnya membawa lalu lintas ini sebelum menyentuh salah satunya.

Catat mode adaptor tamu sekarang, sebelum mengubah apa pun. Satu nilai itu menjelaskan sebagian besar dari apa yang berikut, dan itu adalah hal pertama yang akan ditanyakan orang kepada Anda nanti.

Pertukaran luar menentukan kompatibilitas

Panduan jaringan VirtualBox mencantumkan batasan NAT yang penting di sini: ia tidak akan meneruskan protokol selain TCP dan UDP, GRE disebut sebagai tidak didukung, dan PPTP diberikan sebagai contoh yang terdampak. PPTP menggunakan pertukaran kontrol TCP dan GRE untuk data, jadi koneksi kontrol dapat berhasil sementara jalur data tidak dapat melewati batas yang sama. Itu dua bukti berbeda, dan hanya satu yang tentang membawa lalu lintas. Mengizinkan port TCP 47 dalam aturan firewall tidak sama dengan mengizinkan protokol IP 47, dan keduanya terus tertukar.

Pertahankan batasan itu melekat pada susunan NAT ini, bukan pada setiap perangkat yang memakai kata NAT. Router fisik dapat meneruskan GRE tanpa keluhan sementara NAT virtual menjatuhkannya, dan hypervisor lain membuat pilihannya sendiri tentang apa yang diteruskannya. Di mana organisasi menawarkan transportasi yang disetujui di dalam TCP atau UDP, gunakan klien dan profil yang didukungnya untuk jalur itu. Kompatibilitas adalah satu persyaratan di antara beberapa, dan itu tidak menetapkan kepercayaan server, izin akun, atau rute privat yang berfungsi.

Apa yang sebenarnya diubah jembatan

Jembatan menyerahkan alamat MAC tamu ke segmen fisik alih-alih menyembunyikannya di balik terjemahan. Tamu kemudian mengambil alamat dari server DHCP mana pun yang melayani segmen itu, menjawab ARP untuk alamat itu, dan tampil di hadapan sakelar hulu sebagai satu port lagi. Itu menghapus jalur terjemahan virtual, yang justru menjadi alasan resep lama merekomendasikannya, dan itu mengubah tiga hal lain pada saat yang sama. Pengalamatan sekarang datang dari segmen lokal alih-alih dari hypervisor, paparan berarti tamu terlihat oleh segmen itu, dan penerimaan bergantung pada port sakelar dan kebijakannya. Masing-masing dapat menjadi alasan menolak perubahan, dan tidak satu pun tentang protokol VPN.

Penjembatanan tidak memasang plugin yang hilang, tidak menyediakan agen rahasia yang tidak tersedia, dan tidak memperbaiki penolakan autentikasi. Itu juga tidak membuat protokol usang menjadi pilihan yang baik, dan di mana operator memiliki pengganti yang dipelihara, itulah keputusannya alih-alih mengganti hypervisor. Penerusan port adalah peran ketiga sepenuhnya: ia menerbitkan layanan masuk dan tidak melakukan apa pun untuk protokol luar klien keluar.

Dua terowongan, dua jejak bukti

VPN tamu membutuhkan jalur yang dapat digunakan dari antarmuka tamu ke rekannya sebelum alamat internal atau rute privat apa pun penting. Di mana VPN host ada, ia dapat meneruskan atau memblokir pertukaran luar itu menurut kebijakannya sendiri, dan terowongan internal tamu hanya dimulai setelah yang luar berhasil. Cakupan tidak ada lapisan yang dapat dibaca dari satu ikon terhubung atau dari alamat publik browser host.

Simpan pesan kesalahan pertama alih-alih yang terakhir, karena kegagalan paling awal menamai lapisan. Ubah satu susunan jaringan yang didukung setiap kali, dengan profil tamu dan kredensial yang sama, agar perbandingannya berarti. Putuskan dari kegagalan tahap mana yang rusak: integrasi lokal, transportasi, autentikasi, atau akses sumber daya setelah terowongan menyala. Masing-masing memiliki pemilik berbeda, dan hanya satu yang merupakan pertanyaan hypervisor.

Kondisi mana yang sebenarnya menghambat Anda

Sekarang keputusan menyempit menjadi tiga pertanyaan dengan jawaban berbeda. Jika protokol luar berada di luar TCP dan UDP, mode NAT adalah kendalanya, dan jembatan atau transportasi TCP/UDP yang disetujui adalah jalan ke depan. Jika pertukaran luar selesai dan jalur data tidak, kendalanya sama dengan yang terlihat pada bukti kedua. Jika terowongan menyala dan sumber daya tidak menjawab, masalahnya sudah melewati hypervisor ke perutean atau kebijakan.

Tuliskan jawabannya dengan mode adaptor di sampingnya, atau orang berikutnya akan mengulangi sore yang sama. Uji aplikasi sebenarnya dan resolusi nama di dalam tamu setelah koreksi apa pun, lalu sambungkan kembali dan uji kebijakan kegagalan. Halaman web yang berfungsi melalui terowongan hanya membuktikan jalur web berfungsi, yang merupakan klaim lebih kecil daripada yang terasa saat itu.