Menghalakan trafik hos melalui VPN dalam VM: enam semakan

Enam semakan, dijalankan mengikut urutan, menentukan sama ada VM boleh bertindak sebagai pintu masuk VPN untuk hosnya sendiri. Hipervisor tidak melakukan apa-apa daripada ini untuk anda: tetamu memiliki terowong, hos memiliki laluan, dan rangkaian di antaranya ialah penghalakan biasa. Saya menyimpan senarai ini kerana melangkau satu langkah sentiasa menghasilkan gejala yang sama, kesenyapan, apabila hos dengan gembira mengeping tetamu dan tidak sampai kepada apa-apa yang dalaman.

Mulakan dengan sebabnya. Sama ada klien korporat hanya dipasang di dalam tetamu, atau dasar mengekalkannya di sana, dan anda masih memerlukan pelayan binaan dalaman daripada hos. Jika hos dibenarkan mempunyai kliennya sendiri, lakukan itu: satu terowong pada hos sentiasa mengalahkan dua rangkaian campur NAT.

Semakan 1: hos memerlukan pautan yang boleh diberi alamat

Hos mesti memiliki antara muka dalam awalan yang sama dengan penyesuai kedua tetamu. Host-only dalam VirtualBox, host-only atau VMnet tersuai dalam VMware Workstation, jambatan dalaman atau peranti tap dalam QEMU/KVM, dan suis Internal dalam Hyper-V semuanya layak. Tetamu 192.168.56.2, hos 192.168.56.1, awalan 192.168.56.0/24 ialah susun atur yang saya gunakan di makmal.

Rangkaian mod pengguna QEMU (-netdev user, backend SLIRP lalai) dan NAT VirtualBox gagal sepenuhnya pada semakan ini. Paket tetamu sampai ke proses proksi pada hos, jadi hos tidak pernah melihat peranti yang membawa alamat tetamu dan tiada apa-apa untuk dihalakan laluan. Default Switch Hyper-V ialah kisah yang sama. Jika ping 192.168.56.2 dari hos gagal, berhenti: tiada laluan yang ditambah kemudian akan membaikinya.

Semakan 2: tetamu memajukan dan menterjemah

Paket dari hos tiba dengan alamat sumber host-only dan destinasi dalaman, jadi tetamu mesti memajukannya dan kemudian menyembunyikannya di belakang alamat terowongnya. Pada tetamu Linux itu bermakna pemajuan, sepasang FORWARD accept, dan source NAT menuju terowong:

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

Peraturan MASQUERADE ialah bahagian yang orang tinggalkan. Penghala korporat jarang tahu bahawa 192.168.56.0/24 wujud; dengan peraturan itu, pelayan dalaman melihat alamat terowong tetamu dan menjawabnya, dan jawapan menemui jalan pulang ke tetamu.

Tetamu Windows lebih kekok. IPEnableRouter=1 di bawah SYSTEM\CurrentControlSet\Services\Tcpip\Parameters menghidupkan pemajuan tanpa terjemahan, jadi ia hanya berfungsi di tempat penghalakan korporat sudah menunjuk balik ke awalan host-only anda. Internet Connection Sharing menterjemah, tetapi menomborkan semula penyesuai kongsi ke 192.168.137.1, jadi baca alamat yang benar-benar diambilnya sebelum menulis laluan hos.

Semakan 3: laluan hos menamakan tetamu, bukan terowong

Hantar hanya awalan yang diperlukan hos melalui tetamu. Pada Linux satu laluan bagi setiap awalan sudah cukup dan ia berbalik dengan bersih:

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

Pada Windows padanannya ialah route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. Biarkan -p keluar semasa anda masih menguji, supaya laluan buruk mati semasa but semula, dan tambahkannya apabila laluan berfungsi. Jangan buang laluan lalai hos melainkan setiap aplikasi pada hos perlu menggunakan terowong; jika terowong penuh benar-benar keperluannya, tambah dua laluan /1 dan kekalkan laluan terus ke rangkaian hipervisor:

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

Pada hos Windows, periksa juga metrik antara muka. Laluan yang ditambah semasa penyesuai host-only dilumpuhkan kekal dalam jadual tetapi tidak pernah membawa trafik, dan penyesuai kedua dengan metrik lebih rendah boleh memenangi carian untuk awalan yang sama.

Semakan 4: DNS mengikut laluan, bukan lalai terowong

Laluan menggerakkan paket; penyelesai menentukan nama mana yang menghasilkan paket. Hadkan penyelesai korporat kepada zon korporat dan bukan menggantikan penyelesai hos, dan halakan ia ke pelayan DNS yang sudah dicapai oleh laluan baharu. Dengan systemd-resolved pada hos:

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

Pada Windows, entri dalam jadual dasar penyelesaian nama melakukan kerja yang sama: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. Jika tetamu menjalankan penyelesainya sendiri pada alamat host-only, gunakan alamat itu, tetapi hanya selepas mengesahkan ia menjawab pada 192.168.56.2 dan bukan pada loopback.

Kemudian periksa MTU sebelum menyalahkan DNS atas halaman perlahan. Antara muka terowong lebih kecil daripada antara muka 1500 bait hos, jadi hos yang menghantar segmen bersaiz penuh dengan bit DF dihidupkan melihatnya digugurkan di suatu tempat dalam tetamu. Gejala klasik ialah ping yang berfungsi dan aplikasi web dalaman yang tersekat selepas jabat tangan TLS. Ketatkan MSS pada laluan pemajuan tetamu:

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

Semakan 5: sahkan dari kedua-dua hujung

Dari hos, traceroute atau tracert ke alamat dalaman sepatutnya menunjukkan 192.168.56.2 sebagai hop pertama, bukan pintu masuk fizikal. Dalam tetamu, perhatikan cubaan yang sama keluar: tcpdump -ni any host 10.20.30.40 menunjukkan permintaan yang dimajukan di sisi host-only dan yang diterjemah pada terowong. Permintaan yang keluar, kembali dan masih membiarkan hos bisu menunjuk ke laluan balik.

Dua kegagalan menjelaskan sebahagian besar daripada itu. Sama ada terowong tetamu tidak membawa laluan balik untuk awalan host-only kerana peraturan NAT tiada, atau laluan hos menunjuk ke alamat yang tidak lagi dipegang tetamu selepas but semula. Baca semula alamat dengan ip -br addr dan ip route get dan bukan mempercayai nota sesi lepas.

Semakan 6: buat ia bertahan selepas but semula dan peningkatan hipervisor

Kekalkan kedua-dua bahagian: konfigurasi laluan netplan atau NetworkManager pada hos, route add ... -p pada Windows, dan net.ipv4.ip_forward=1 dalam /etc/sysctl.d/ serta set peraturan tembok api yang dimuat semula dalam tetamu. Ambil snapshot tetamu sebaik konfigurasi disahkan, sebelum kemas kini klien korporat seterusnya tiba.

Rangkaian host-only dinomborkan semula apabila hipervisor mencipta semula penyesuainya, yang secara senyap membatalkan setiap laluan dan peraturan NAT yang dibina atas 192.168.56.0/24. Selepas peningkatan, ulang tiga semakan pertama mengikut urutan; ia mengambil masa seminit dan menangkap kes hos masih mempunyai laluannya manakala tetamu telah berpindah ke subnet baharu.

IPv6 memerlukan pusingan sendiri. Peraturan ip6tables, rekod AAAA dan keluarga laluan hos kedua tidak mengikut persediaan IPv4, dan perkhidmatan korporat yang boleh dicapai melalui IPv6 akan kelihatan rosak secara kekal manakala IPv4 berfungsi.

Lulus atau tidak, mengikut urutan: hos boleh mengeping alamat host-only tetamu; tetamu memajukan dan melakukan MASQUERADE menuju terowong; ip route get memulangkan tetamu sebagai pintu masuk untuk awalan dalaman; nama korporat diselesaikan melalui penyelesai terhad; traceroute menunjukkan tetamu dahulu; dan enam jawapan yang sama bertahan selepas but semula.