Merutekan lalu lintas VM di jaringan host-only melalui server TUN OpenVPN

Adaptor host-only membuat jaringan virtual lokal, dan tunnel TUN yang dirutekan membawa paket IP antar alamat. Keduanya bukan jembatan ke yang lain, karena itu konfigurasi yang berfungsi harus menyebut siapa yang meneruskan dan siapa pemilik rute pulang. Kalau dua penetapan itu tertukar, tamu menjawab tunnel dengan sumber yang tidak pernah diminta klien tunnel. Rancangan di bawah menjaga kedua prefiks tetap terpisah dan membuat jalur pulang menjadi eksplisit.

Dua jaringan, dua prefiks

Beri prefiks berbeda untuk kumpulan tunnel dan jaringan host-only, dan jangan pernah memakai yang satu untuk yang lain. Dalam contoh ini kumpulan VPN adalah 10.44.0.0/24 dan jaringan host-only adalah 192.168.99.0/24, dengan host di 192.168.99.1 dan tamu di 192.168.99.20. Memberikan prefiks yang sama ke perangkat TUN dan ke adaptor host-only tidak menyatukan keduanya. Itu menciptakan dua klaim atas satu rentang alamat, dan tabel perutean lalu menjawab untuk klaim yang kebetulan dipertahankannya.

Adaptor host-only ada di host dan di dalam tamu, dan ia tidak punya jalur keluar dari mesin itu sendiri. Sambungan jembatan dan NAT punya paparan berbeda, dan beralih ke mode jembatan bukan syarat untuk mencapai satu layanan tamu.

Host sudah memegang jalurnya

Lihat apa yang sudah ada sebelum menambahkan apa pun. Host punya antarmuka di jaringan host-only dan rute untuk prefiks itu, keduanya dibuat saat adaptor naik.

ip -br addr show
ip route show 192.168.99.0/24
sysctl net.ipv4.ip_forward

Baris ketiga adalah mekanisme yang menjadikan host sebagai lompatan. Tanpanya, paket yang datang dari tunnel dialamatkan ke jaringan yang bisa dijangkau host tetapi tidak akan diteruskannya. Penerusan perlu dan tidak cukup. Kebijakan penyaringan tetap memutuskan apakah aliran tertentu antara antarmuka tunnel dan antarmuka host-only diizinkan, dan keputusan itu harus tertulis, bukan di kebijakan bawaan yang tak dibaca siapa pun.

Dorong rutenya, lalu saring apa yang dijangkau

Server dapat menyediakan prefiks host-only kepada klien yang menerima rute yang didorong, yaitu mekanisme yang sama seperti untuk subjaringan lain di belakang tunnel.

push "route 192.168.99.0 255.255.255.0"
iptables -A FORWARD -i tun0 -o vboxnet0 -d 192.168.99.20 -p tcp --dport 5432 -j ACCEPT
iptables -A FORWARD -i vboxnet0 -o tun0 -s 192.168.99.20 -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Dua aturan itu mengizinkan satu layanan dalam satu arah dan balasannya. Rute yang menjangkau seluruh prefiks dan penyaring yang mengizinkan satu port adalah kombinasi yang disengaja; rute plus penerimaan tanpa syarat adalah cara layanan laboratorium menjadi layanan yang terbuka. Rute yang didorong juga bukan otorisasi. Klien menerimanya, host meneruskannya, dan firewall tamu serta layanan itu sendiri masih punya suara.

Tamu butuh jalan pulang

Tamu yang dijangkau dari 10.44.0.x harus mengirim balasannya ke alamat host-only milik host, atau host harus menerjemahkan sumbernya. Menerima alamat dari DHCP VirtualBox tidak menjelaskan apa pun soal salah satu pengaturan itu.

ip route add 10.44.0.0/24 via 192.168.99.1 dev enp0s8
ip route get 10.44.0.15

Menambahkan rute itu di dalam tamu mempertahankan sumber asli, yang menjaga kebijakan dan log per klien tetap bermakna. Penerjemahan sumber terbatas di host adalah alternatifnya, dan itu berhasil, dengan biaya menyembunyikan klien mana yang terhubung. Tumpang tindih adalah mode kegagalan lainnya. Klien jarak jauh yang LAN rumahnya sudah memakai 192.168.99.0/24 akan membaca rute yang didorong sebagai jaringannya sendiri, dan tidak ada perubahan di sisi server yang memperbaiki ambiguitas itu. Beri nomor ulang satu sisi atau pilih prefiks yang kemungkinan kecil bertabrakan.

Perangkat TUN membawa paket IP, jadi menambahkan gateway bawaan di dalam tamu tidak mengubah tunnel menjadi segmen Ethernet dengan adaptor host-only. Jembatan TAP adalah rancangan lain dengan dukungan klien dan kepemilikan alamatnya sendiri, dan mencampur kedua deskripsi menghasilkan konfigurasi yang tak pernah bertemu.

Verifikasi, lalu buat ia bertahan melewati mulai ulang

Uji satu layanan tak berbahaya dari klien jarak jauh biasa, periksa rute pulang tamu, dan pastikan layanan yang tidak Anda izinkan ditolak, bukan melambat.

ss -lntp '( sport = :5432 )'
conntrack -L | grep 192.168.99.20

Lalu mulai ulang layanan VPN dan jaringan mesin virtual, dan ulangi tiga pemeriksaan yang sama. Rute yang ditambahkan dengan tangan bertahan sampai reboot berikutnya, dan konfigurasi yang hanya bekerja dalam sesi hangat bukanlah rancangan. Catat kedua prefiks, kebijakan penerusan, dan rute tamu bersama-sama. Siapa pun yang menambahkan mesin virtual berikutnya akan memerlukan ketiganya dan kalau tidak akan menemukannya lagi satu koneksi gagal demi satu.