Merutekan lalu lintas host lewat VPN di VM: enam pemeriksaan

Enam pemeriksaan, dijalankan berurutan, menentukan apakah sebuah VM dapat menjadi gateway VPN bagi host-nya sendiri. Hypervisor tidak melakukan satu pun dari ini untuk Anda: tamu memiliki terowongan, host memiliki rute, dan jaringan di antaranya adalah perutean biasa. Saya menyimpan daftar ini karena melewatkan satu langkah selalu menghasilkan gejala yang sama, kesunyian, ketika host dengan senang hati mem-ping tamu dan tidak menjangkau apa pun yang internal.

Mulailah dari alasannya. Entah klien korporat hanya dapat dipasang di dalam tamu, atau kebijakan menahannya di sana, dan Anda tetap membutuhkan server build internal dari host. Jika host diizinkan memakai kliennya sendiri, lakukan itu saja: satu terowongan di host selalu mengalahkan dua jaringan plus NAT.

Pemeriksaan 1: host memerlukan tautan yang bisa diberi alamat

Host harus memiliki antarmuka yang berada di prefiks yang sama dengan adaptor kedua tamu. Host-only di VirtualBox, host-only atau VMnet khusus di VMware Workstation, jembatan internal atau perangkat tap di QEMU/KVM, dan switch Internal di Hyper-V semuanya memenuhi syarat. Tamu 192.168.56.2, host 192.168.56.1, prefiks 192.168.56.0/24 adalah tata letak yang saya pakai di laboratorium.

Jaringan mode pengguna QEMU (-netdev user, backend SLIRP bawaan) dan NAT VirtualBox gagal total pada pemeriksaan ini. Paket tamu mencapai proses proksi di host, sehingga host tidak pernah melihat perangkat yang membawa alamat tamu dan tidak punya apa pun untuk dijadikan tujuan rute. Default Switch Hyper-V pun sama ceritanya. Jika ping 192.168.56.2 dari host gagal, berhentilah: tidak ada rute yang ditambahkan kemudian yang akan memperbaikinya.

Pemeriksaan 2: tamu meneruskan dan menerjemahkan

Paket dari host datang dengan alamat sumber host-only dan tujuan internal, jadi tamu harus meneruskannya lalu menyembunyikannya di balik alamat terowongannya. Pada tamu Linux itu berarti penerusan, sepasang FORWARD accept, dan source NAT menuju terowongan:

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
sudo iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 192.168.56.0/24 -o tun0 -j MASQUERADE

Aturan MASQUERADE adalah bagian yang orang lewatkan. Router korporat jarang tahu bahwa 192.168.56.0/24 ada; dengan aturan itu, server internal melihat alamat terowongan tamu dan menjawabnya, dan balasannya menemukan jalan kembali ke tamu.

Tamu Windows lebih canggung. IPEnableRouter=1 di bawah SYSTEM\CurrentControlSet\Services\Tcpip\Parameters menyalakan penerusan tanpa penerjemahan, jadi hanya berfungsi di tempat perutean korporat sudah menunjuk balik ke prefiks host-only Anda. Internet Connection Sharing memang menerjemahkan, tetapi menomori ulang adaptor bersama menjadi 192.168.137.1, jadi bacalah alamat yang benar-benar diambilnya sebelum menulis rute host.

Pemeriksaan 3: rute host menyebut tamu, bukan terowongan

Kirim hanya prefiks yang dibutuhkan host melalui tamu. Di Linux satu rute per prefiks sudah cukup dan berbalik dengan bersih:

sudo ip route add 10.20.0.0/16 via 192.168.56.2
ip route get 10.20.30.40

Di Windows padanannya adalah route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. Biarkan -p keluar saat masih menguji, agar rute buruk mati saat reboot, dan tambahkan setelah jalurnya berfungsi. Jangan hapus rute default host kecuali setiap aplikasi di host harus memakai terowongan; jika full tunnel benar-benar syaratnya, tambahkan dua rute /1 dan pertahankan rute langsung ke jaringan hypervisor:

sudo ip route add 0.0.0.0/1 via 192.168.56.2
sudo ip route add 128.0.0.0/1 via 192.168.56.2

Di host Windows, periksa juga metrik antarmuka. Rute yang ditambahkan saat adaptor host-only dinonaktifkan tetap ada di tabel tetapi tidak pernah membawa lalu lintas, dan adaptor kedua dengan metrik lebih rendah dapat memenangkan pencarian untuk prefiks yang sama.

Pemeriksaan 4: DNS mengikuti rute, bukan default terowongan

Rute memindahkan paket; resolver menentukan nama mana yang menghasilkan paket. Batasi resolver korporat ke zona korporat alih-alih mengganti resolver host, dan arahkan ke server DNS yang sudah dijangkau rute baru. Dengan systemd-resolved di host:

resolvectl dns eth1 10.20.0.53
resolvectl domain eth1 '~corp.example.com'

Di Windows, entri tabel kebijakan resolusi nama melakukan hal yang sama: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. Jika tamu menjalankan resolver sendiri di alamat host-only, pakai alamat itu sebagai gantinya, tetapi hanya setelah memastikan alamat itu menjawab di 192.168.56.2 dan bukan di loopback.

Lalu periksa MTU sebelum menyalahkan DNS atas halaman lambat. Antarmuka terowongan lebih kecil daripada antarmuka 1500 byte host, jadi host yang mengirim segmen berukuran penuh dengan bit DF aktif akan melihatnya dibuang di suatu tempat di dalam tamu. Gejala klasiknya adalah ping yang berfungsi dan aplikasi web internal yang tersendat setelah jabat tangan TLS. Kencangkan MSS di jalur penerusan tamu:

sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Pemeriksaan 5: verifikasi dari kedua ujung

Dari host, traceroute atau tracert ke alamat internal harus menunjukkan 192.168.56.2 sebagai hop pertama, bukan gateway fisik. Di tamu, amati upaya yang sama keluar: tcpdump -ni any host 10.20.30.40 menunjukkan permintaan yang diteruskan di sisi host-only dan yang diterjemahkan di terowongan. Permintaan yang keluar, kembali, dan tetap membuat host bisu menunjuk ke jalur balik.

Dua kegagalan menjelaskan sebagian besar hal itu. Entah terowongan tamu tidak membawa rute balik untuk prefiks host-only karena aturan NAT hilang, atau rute host menunjuk alamat yang tidak lagi dipegang tamu setelah restart. Baca ulang alamatnya dengan ip -br addr dan ip route get alih-alih memercayai catatan sesi sebelumnya.

Pemeriksaan 6: buat bertahan terhadap reboot dan peningkatan hypervisor

Pertahankan kedua bagian: konfigurasi rute netplan atau NetworkManager di host, route add ... -p di Windows, dan net.ipv4.ip_forward=1 di /etc/sysctl.d/ plus seperangkat aturan firewall yang dimuat ulang di tamu. Ambil snapshot tamu begitu konfigurasi terverifikasi, sebelum pembaruan klien korporat berikutnya datang.

Jaringan host-only dinomori ulang saat hypervisor membuat ulang adaptornya, yang diam-diam membatalkan setiap rute dan aturan NAT yang dibangun di atas 192.168.56.0/24. Setelah peningkatan, jalankan ulang tiga pemeriksaan pertama secara berurutan; itu perlu satu menit dan menangkap kasus ketika host masih punya rutenya sementara tamu sudah pindah ke subnet baru.

IPv6 perlu giliran sendiri. Aturan ip6tables, catatan AAAA, dan keluarga rute host kedua tidak mengikuti penyiapan IPv4, dan layanan korporat yang dapat dijangkau lewat IPv6 akan tampak rusak permanen sementara IPv4 berfungsi.

Lulus atau tidak, berurutan: host dapat mem-ping alamat host-only tamu; tamu meneruskan dan melakukan MASQUERADE menuju terowongan; ip route get mengembalikan tamu sebagai gateway untuk prefiks internal; nama korporat diresolusi lewat resolver terbatas; traceroute menunjukkan tamu lebih dulu; dan enam jawaban yang sama bertahan setelah reboot.