Pagruruta ng trapiko ng host sa pamamagitan ng VPN sa isang VM: anim na pagsusuri

Anim na pagsusuri, na isinasagawa ayon sa pagkakasunod-sunod, ang nagtatakda kung ang isang VM ay maaaring maging VPN gateway para sa sarili nitong host. Wala sa mga ito ang ginagawa ng hypervisor para sa iyo: pag-aari ng guest ang tunnel, pag-aari ng host ang ruta, at ang network sa pagitan nila ay ordinaryong routing. Hinahawakan ko ang listahan dahil ang paglaktaw ng isang hakbang ay laging nagbibigay ng parehong sintomas, katahimikan, kung saan masayang piniping ng host ang guest at wala itong naaabot na anumang panloob.

Magsimula sa dahilan. Alinman sa kliyenteng pang-korporasyon ay naka-install lamang sa loob ng guest, o pinapanatili ito ng patakaran doon, at kailangan mo pa rin ang panloob na build server mula sa host. Kung pinapayagan ang host na magkaroon ng sariling kliyente, gawin iyon sa halip: isang tunnel sa host ang panalo laban sa dalawang network at isang NAT sa bawat pagkakataon.

Pagsusuri 1: kailangan ng host ng link na mabibigyan niya ng address

Ang host ay dapat may interface sa parehong prefix ng ikalawang adapter ng guest. Host-only sa VirtualBox, host-only o custom na VMnet sa VMware Workstation, panloob na tulay o tap device sa QEMU/KVM, at Internal switch sa Hyper-V ay lahat kwalipikado. Guest 192.168.56.2, host 192.168.56.1, prefix 192.168.56.0/24 ang layout na ginagamit ko sa mga lab.

Ang user-mode networking ng QEMU (-netdev user, ang default na SLIRP backend) at NAT ng VirtualBox ay ganap na bumabagsak sa pagsusuring ito. Umaabot ang mga packet ng guest sa isang proxy process sa host, kaya hindi kailanman nakikita ng host ang device na may mga address ng guest at wala siyang mapagdidireksyunan ng ruta. Ang Default Switch ng Hyper-V ay parehong kuwento. Kung nabigo ang ping 192.168.56.2 mula sa host, huminto: walang rutang idadagdag mamaya ang makakapag-ayos niyan.

Pagsusuri 2: nagpapasa at nagsasalin ang guest

Dumarating ang mga packet mula sa host na may source address na host-only at panloob na destinasyon, kaya kailangang ipasa ng guest ang mga ito at pagkatapos itago sa likod ng address ng sarili nitong tunnel. Sa isang Linux guest, nangangahulugan iyon ng pagpapasa, isang pares na FORWARD accept, at source NAT patungo sa tunnel:

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

Ang MASQUERADE rule ang bahaging iniiwan ng mga tao. Bihirang malaman ng mga corporate router na may 192.168.56.0/24; sa rule na ito, nakikita ng mga panloob na server ang address ng tunnel ng guest at sinasagot ito, at nakakahanap ng daan pabalik sa guest ang sagot.

Mas gusot ang isang Windows guest. Binubuksan ng IPEnableRouter=1 sa ilalim ng SYSTEM\CurrentControlSet\Services\Tcpip\Parameters ang pagpapasa nang walang salin, kaya gumagana lamang ito kung saan itinuturo na ng corporate routing pabalik sa iyong host-only prefix. Nagsasalin ang Internet Connection Sharing, ngunit muling binibilang ang ibinahaging adapter sa 192.168.137.1, kaya basahin ang address na aktwal nitong nakuha bago magsulat ng mga ruta ng host.

Pagsusuri 3: pinapangalanan ng ruta ng host ang guest, hindi ang tunnel

Ipadala lamang sa pamamagitan ng guest ang mga prefix na kailangan ng host. Sa Linux sapat na ang isang ruta bawat prefix at malinis itong bumabalik:

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

Sa Windows ang katumbas ay route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. Iwanan ang -p habang nagsubok ka pa, upang mamatay ang masamang ruta sa reboot, at idagdag ito kapag gumana na ang daan. Huwag alisin ang default na ruta ng host maliban kung dapat gamitin ng bawat aplikasyon sa host ang tunnel; kung tunay na kailangan ang buong tunnel, idagdag ang dalawang rutang /1 at panatilihin ang direktang ruta patungo sa network ng 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

Sa isang Windows host, suriin din ang metric ng interface. Ang rutang idinagdag habang naka-disable ang host-only adapter ay nananatili sa table ngunit hindi kailanman nagdadala ng trapiko, at ang ikalawang adapter na may mas mababang metric ay maaaring manalo sa paghahanap para sa parehong prefix.

Pagsusuri 4: sinusundan ng DNS ang ruta, hindi ang default ng tunnel

Ginagalaw ng ruta ang mga packet; ang resolver ang nagtatakda kung aling mga pangalan ang gumagawa ng packet. Limitahan ang corporate resolver sa corporate zone sa halip na palitan ang resolver ng host, at ituro ito sa isang DNS server na naaabot na ng bagong ruta. Sa systemd-resolved sa host:

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

Sa Windows, isang entry sa name resolution policy table ang gumagawa ng parehong gawain: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. Kung ang guest ay nagpapatakbo ng sariling resolver sa host-only address, gamitin ang address na iyon sa halip, ngunit pagkatapos lamang kumpirmahin na tumutugon ito sa 192.168.56.2 at hindi sa loopback.

Pagkatapos suriin ang MTU bago sisihin ang DNS sa mabagal na pahina. Ang interface ng tunnel ay mas maliit kaysa 1500-byte interface ng host, kaya ang host na nagpapadala ng full-size na segment na naka-set ang DF bit ay nakikitang itinatapon ang mga ito saanman sa loob ng guest. Ang klasikong sintomas ay isang gumaganang ping at panloob na web app na natigil pagkatapos ng TLS handshake. Higpitan ang MSS sa daan ng pagpapasa ng guest:

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

Pagsusuri 5: i-verify mula sa dalawang dulo

Mula sa host, ang traceroute o tracert patungo sa panloob na address ay dapat magpakita ng 192.168.56.2 bilang unang hop, hindi ang pisikal na gateway. Sa guest, panoorin ang parehong pagtatangkang lumabas: ipinapakita ng tcpdump -ni any host 10.20.30.40 ang ipinasang kahilingan sa panig host-only at ang isinaling kahilingan sa tunnel. Ang kahilingang lumalabas, bumabalik at nag-iiwan pa rin sa host na tahimik ay tumuturo sa daan pabalik.

Dalawang kabiguan ang nagpapaliwanag sa karamihan niyan. Alinman sa tunnel ng guest ay walang rutang pabalik para sa host-only prefix dahil kulang ang NAT rule, o ang ruta ng host ay tumuturo sa address na wala nang hawak ang guest pagkatapos ng restart. Basahin muli ang mga address sa ip -br addr at ip route get sa halip na magtiwala sa mga tala mula sa nakaraang sesyon.

Pagsusuri 6: gawing matibay sa reboot at upgrade ng hypervisor

Panatilihing permanenteng dalawang hati: configuration ng ruta sa netplan o NetworkManager sa host, route add ... -p sa Windows, at net.ipv4.ip_forward=1 sa /etc/sysctl.d/ kasama ang isang set ng firewall rules na muling naglo-load sa guest. Kumuha ng snapshot ng guest kapag na-verify na ang configuration, bago dumating ang susunod na update ng corporate client.

Ang mga host-only network ay muling binibilang kapag muling ginawa ng hypervisor ang mga adapter nito, na tahimik na nagpapawalang-bisa sa bawat ruta at NAT rule na itinayo sa 192.168.56.0/24. Pagkatapos ng upgrade, ulitin ang unang tatlong pagsusuri ayon sa pagkakasunod-sunod; tumatagal ito ng isang minuto at nahuhuli ang kaso kung saan may ruta pa ang host samantalang lumipat ang guest sa bagong subnet.

Kailangan ng IPv6 ng sariling pag-ikot. Ang mga rule ng ip6tables, mga rekord ng AAAA at ikalawang pamilya ng ruta ng host ay hindi sumusunod sa setup ng IPv4, at ang serbisyong pang-korporasyon na maaabot sa IPv6 ay magmumukhang permanenteng sira habang gumagana ang IPv4.

Pumasa man o hindi, ayon sa pagkakasunod-sunod: kayang i-ping ng host ang host-only address ng guest; nagpapasa at gumagawa ng MASQUERADE ang guest patungo sa tunnel; ibinabalik ng ip route get ang guest bilang gateway para sa panloob na prefix; nareresolba ang mga pangalang pang-korporasyon sa limitadong resolver; ipinapakita ng traceroute ang guest muna; at ang parehong anim na sagot ay nakakaligtas sa reboot.