VPN menyala, VM tak terjangkau? Rutenya kemungkinan tidak pernah menjadi masalah

Sambungkan VPN, dan VM pengembangan yang tadi menjawab menjadi diam. Kisah yang jelas menulis dirinya sendiri: terowongan mengambil alih rute, host kini mengirim lalu lintas tamu ke jaringan korporat, dan solusinya adalah menambahkan rute statis atau mengalihkan adaptor ke mode jembatan. Kisah itu kadang benar. Tetapi bukan itu penyebab biasanya, dan bertindak berdasarkan itu lebih dulu cenderung merusak hal lain.

Jaringan host-only adalah jaringan perangkat lunak milik host dan dibagi dengan tamunya, terpisah dari setiap sambungan fisik. Tidak ada yang berubah pada jaringan itu dari antarmuka klien VPN sendiri, jadi sebelum menyentuhnya, cari tahu lapisan mana dari empat lapisan yang benar-benar gagal.

Rutenya biasanya masih lokal

Tanyakan pada kernel, bukan pada halaman depan tabel perutean. Di Linux, ip route get 192.168.56.10 melaporkan rute, antarmuka, dan alamat sumber persis yang akan dipakai, yang merupakan jawaban berbeda dari membaca rute bawaan dan menebak. Jika keluarannya menyebut antarmuka host-only, terowongan sama sekali tidak terlibat di jalur itu.

Dua hal benar-benar dapat merusaknya, dan keduanya masalah alamat, bukan masalah VPN. Subnet jarak jauh yang tumpang tindih dengan prefiks host-only membuat rute yang lebih spesifik menang, dan klien VPN yang memasang rute lebar dengan metrik lebih rendah dapat mencabut prefiks itu. Keduanya terlihat pada perintah yang sama: antarmuka yang disebut di keluaran adalah terowongan, dan perbaikannya milik siapa pun yang memiliki rencana alamat itu.

Pemilihan rute dan penerimaan paket adalah dua keputusan berbeda

Unsur inilah yang biasanya terlewat oleh model mental. Bahkan dengan rute lokal yang sempurna, klien VPN dapat menolak paket. Banyak klien menerapkan kebijakan akses jaringan lokal yang menentukan tujuan mana yang diizinkan di luar terowongan, dan subnet yang tersambung tidak memperbarui daftar itu secara otomatis.

Jadi kegagalannya tampak identik dengan masalah perutean dari sisi aplikasi, dan sangat berbeda dari sisi klien. Jika ip route get menyebut antarmuka yang benar dan koneksi tetap habis waktu, berhentilah menyunting rute dan bacalah perilaku akses lokal klien yang terdokumentasi. Sebagian klien menyediakan daftar izin untuk subnet lokal, sebagian memblokir semua yang bukan terowongan, dan sebagian hanya memblokir saat kill switch aktif.

Pembedaan itu penting karena perbaikannya tidak dapat dipertukarkan. Menambahkan rute tidak dapat memenuhi filter, dan menonaktifkan filter untuk mencapai satu tamu adalah keputusan yang jauh lebih besar daripada yang disiratkan gejalanya.

Tamu punya tiga cara untuk mengatakan tidak

Tamu yang bisa menjelajahi internet tidak membuktikan apa pun tentang layanan yang Anda inginkan. Pendengar mungkin terikat ke 127.0.0.1 di dalam tamu, dan dalam kasus itu tidak ada permintaan dari host yang bisa tiba, sebaik apa pun jalurnya. Periksa dengan ss -ltn di dalam tamu dan lihat kolom alamat lokal, bukan hanya port.

Berikutnya adalah firewall tamu itu sendiri. Citra pengembangan dengan bawaan yang ketat dapat menerima paket host dan membuangnya di batas layanan, yang menghasilkan waktu habis yang tampak persis seperti lubang hitam perutean. Terakhir ada konfigurasi layanan itu sendiri: aplikasi web yang terikat ke nama host tertentu, atau daftar alamat klien yang diizinkan, akan menolak permintaan dari subnet host-only bahkan ketika setiap paket tiba.

Telusuri ketiganya sebelum mempertimbangkan mengubah mode jaringan VM. Masing-masing adalah perubahan yang lebih kecil daripada merancang ulang sambungan tamu, dan masing-masing punya uji yang jelas.

Apa sebenarnya jembatan itu, dan berapa biayanya

Mengalihkan adaptor ke mode jembatan bukan perbaikan jalur host-only. Itu adalah keputusan untuk menempatkan tamu di jaringan lain, biasanya LAN fisik, tempat ia menjadi terlihat bagi segala hal lain yang hidup di sana. Itu mungkin persis yang Anda inginkan. Tetapi itu bukan yang dilakukan konfigurasi awal.

Gunakan saat tamu memang perlu menjadi rekan di LAN itu dan pemaparannya disetujui. Jangan gunakan karena satu layanan berhenti menjawab, sebab perubahan itu dapat memindahkan tamu keluar dari isolasi yang membuatnya aman untuk pengembangan.

Setelah setiap koreksi yang disetujui, uji dalam urutan tetap: permintaan baru dari host ke tamu, sumber daya korporat yang diperlukan melalui terowongan, dan perilaku penolakan yang dimaksud dengan terowongan dimatikan. Jika yang terakhir tidak lagi berlaku, koreksinya melampaui masalahnya.

Bagian VirtualBox tentang jaringan host-only menjelaskan antarmuka perangkat lunak di sisi host dan bagaimana ia berbeda dari sambungan jembatan, yang merupakan rujukan yang layak dibaca sebelum menganggap kedua mode itu dapat dipertukarkan.