Rute trafikken til verten gjennom ein VPN i ein VM: seks kontrollar

Seks kontrollar, køyrde i rekkefølgje, avgjer om ein VM kan tena som VPN-gateway for sin eigen vert. Hypervisoren gjer ingenting av dette for deg: gjesten eig tunnelen, verten eig ei rute, og nettet mellom dei er vanleg ruting. Eg held på lista fordi å hoppe over eitt steg alltid gir det same symptomet, stillheit, der verten gledeleg pingar gjesten og ikkje når noko internt.

Start med årsaka. Anten blir bedriftsklienten installert berre inne i gjesten, eller så held policyen han der, og du treng framleis den interne byggjetenaren frå verten. Viss verten får lov til å ha sin eigen klient, gjer det i staden: éin tunnel på verten slår kvar gong to nettverk pluss ein NAT.

Kontroll 1: verten treng ei lenkje han kan adressere

Verten må eige eit grensesnitt i same prefiks som den andre adapteren til gjesten. Host-only i VirtualBox, host-only eller eit tilpassa VMnet i VMware Workstation, ei intern bru eller eit tap-utstyr i QEMU/KVM og ein Internal-brytar i Hyper-V kvalifiserer alle. Gjest 192.168.56.2, vert 192.168.56.1, prefiks 192.168.56.0/24 er oppsettet eg brukar i laboratorium.

QEMU-nettverk i brukarmodus (-netdev user, standard SLIRP-backend) og VirtualBox NAT feilar denne kontrollen heilt. Gjestepakkane når ein proxyprosess på verten, så verten ser aldri eit utstyr som ber adressene til gjesten og har ingenting å peike ei rute mot. Default Switch i Hyper-V er same historia. Viss ping 192.168.56.2 frå verten feilar, stopp: inga rute som blir lagd til seinare reparerer det.

Kontroll 2: gjesten vidaresender og omset

Pakkar frå verten kjem inn med ei host-only kjeldeadresse og ein intern destinasjon, så gjesten må vidaresende dei og deretter gøyme dei bak tunneladressa si. På ein Linux-gjest tyder det vidaresending, eit FORWARD accept-par og source NAT mot tunnelen:

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

MASQUERADE-regelen er den delen folk utelèt. Bedriftsrutarar veit sjeldan at 192.168.56.0/24 finst; med regelen ser interne tenarar tunneladressa til gjesten og svarar på ho, og svaret finn vegen tilbake til gjesten.

Ein Windows-gjest er meir klønete. IPEnableRouter=1 under SYSTEM\CurrentControlSet\Services\Tcpip\Parameters slår på vidaresending utan omsetjing, så det verkar berre der bedriftsrutinga allereie peikar tilbake på host-only-prefikset ditt. Internet Connection Sharing omset, men omnummererer den delte adapteren til 192.168.137.1, så les adressa han faktisk tok før du skriv vertsruter.

Kontroll 3: vertsruter namngir gjesten, ikkje tunnelen

Send berre prefiksa verten treng gjennom gjesten. På Linux er éi rute per prefiks nok, og ho snur reint tilbake:

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

På Windows er motstykket route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. Utelat -p medan du framleis testar, slik at ei dårleg rute døyr ved omstart, og legg ho til når vegen verkar. Ikkje fjern standardruta til verten med mindre kvar applikasjon på verten skal bruke tunnelen; viss full tunnel verkeleg er kravet, legg til dei to /1-rutene og hald den direkte ruta til hypervisor-nettet:

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

På ein Windows-vert bør du også sjekke grensesnittmetrikken. Ei rute som vart lagd til medan host-only-adapteren var deaktivert, blir i tabellen men ber aldri trafikk, og ein annan adapter med lågare metrikk kan vinne oppslaget for same prefiks.

Kontroll 4: DNS følgjer ruta, ikkje standarden til tunnelen

Ruter flyttar pakkar; resolvaren avgjer kva namn som lagar pakkar. Avgrens bedriftsresolvaren til bedriftssona i staden for å byte ut resolvaren til verten, og peik han mot ein DNS-tenar som den nye ruta allereie når. Med systemd-resolved på verten:

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

På Windows gjer ein oppføring i namneoppløysings-policytabellen same nytten: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. Viss gjesten køyrer sin eigen resolvar på host-only-adressa, bruk den adressa i staden, men først etter å ha stadfesta at han svarar på 192.168.56.2 og ikkje på loopback.

Sjekk deretter MTU før du klandrar DNS for treige sider. Tunnelgrensesnittet er mindre enn 1500-byte-grensesnittet til verten, så ein vert som sender fullstore segment med DF-biten sett, ser dei bli droppa ein stad inne i gjesten. Det klassiske symptomet er ein fungerande ping og ein intern webapp som stoppar etter TLS-handtrykket. Stram MSS på vidaresendingsvegen i gjesten:

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

Kontroll 5: verifiser frå begge endar

Frå verten skal traceroute eller tracert mot ei intern adresse vise 192.168.56.2 som første hopp, ikkje den fysiske gatewayen. I gjesten ser du det same forsøket gå ut: tcpdump -ni any host 10.20.30.40 viser den vidaresende førespurnaden på host-only-sida og den omsette på tunnelen. Ein førespurnad som går ut, kjem tilbake og likevel lèt verten vere stille, peikar på returvegen.

To feil forklarer det meste. Anten ber tunnelen til gjesten inga returrute for host-only-prefikset fordi NAT-regelen manglar, eller vertsruta peikar på ei adresse gjesten ikkje lenger har etter ein omstart. Les adressene på nytt med ip -br addr og ip route get i staden for å stole på notat frå førre økt.

Kontroll 6: gjer det robust mot omstart og hypervisor-oppgradering

Gjer begge halvdelane varige: netplan- eller NetworkManager-rutekonfigurasjon på verten, route add ... -p på Windows, og net.ipv4.ip_forward=1 i /etc/sysctl.d/ pluss eit regelsett for brannmur som blir lasta på nytt i gjesten. Ta eit snapshot av gjesten når konfigurasjonen er verifisert, før neste bedriftsklientoppdatering kjem.

Host-only-nett blir omnummererte når ein hypervisor gjenopprettar adapterane sine, noko som stille gjer kvar rute og NAT-regel bygd på 192.168.56.0/24 ugyldig. Etter ei oppgradering, køyr dei tre første kontrollane på nytt i rekkefølgje; det tek eit minutt og fangar tilfellet der verten framleis har ruta si medan gjesten har flytta til eit nytt subnett.

IPv6 treng sin eigen runde. ip6tables-reglar, AAAA-poster og ein andre vertsrute-familie følgjer ikkje IPv4-oppsettet, og ein bedriftsteneste som er tilgjengeleg over IPv6 vil sjå permanent øydelagd ut medan IPv4 verkar.

Bestått eller ikkje, i rekkefølgje: verten kan pinge host-only-adressa til gjesten; gjesten vidaresender og gjer MASQUERADE mot tunnelen; ip route get returnerer gjesten som gateway for det interne prefikset; bedriftsnamn blir løyste gjennom den avgrensa resolvaren; traceroute viser gjesten først; og dei same seks svara overlever ein omstart.