Rutte værtens trafik gennem en VPN i en VM: seks kontroller

Seks kontroller, kørt i rækkefølge, afgør, om en VM kan fungere som VPN-gateway for sin egen vært. Hypervisoren gør intet af dette for dig: gæsten ejer tunnelen, værten ejer en rute, og netværket mellem dem er almindelig routing. Jeg holder listen, fordi et sprunget trin altid giver det samme symptom, tavshed, hvor værten glad pinger gæsten og ikke når noget internt.

Start med årsagen. Enten installeres den virksomhedsejede klient kun inde i gæsten, eller også holder politik den der, og du har stadig brug for den interne build-server fra værten. Hvis værten må have sin egen klient, så gør det i stedet: én tunnel på værten slår hver gang to netværk plus en NAT.

Kontrol 1: værten skal have et link, den kan adressere

Værten skal eje et interface i samme præfiks som gæstens anden adapter. Host-only i VirtualBox, host-only eller et tilpasset VMnet i VMware Workstation, en intern bro eller tap-enhed i QEMU/KVM og et Internal-switch i Hyper-V kvalificerer alle. Gæst 192.168.56.2, vært 192.168.56.1, præfiks 192.168.56.0/24 er det layout, jeg bruger i laboratorier.

QEMU-netværk i brugertilstand (-netdev user, standard-SLIRP-backenden) og VirtualBox NAT dumper denne kontrol helt. Gæstens pakker når en proxyproces på værten, så værten ser aldrig en enhed, der bærer gæstens adresser, og har intet at pege en rute på. Hyper-Vs Default Switch er samme historie. Hvis ping 192.168.56.2 fra værten fejler, så stop: ingen rute, der tilføjes senere, reparerer det.

Kontrol 2: gæsten videresender og oversætter

Pakker fra værten ankommer med en host-only kildeadresse og en intern destination, så gæsten skal videresende dem og derefter skjule dem bag sin tunneladresse. På en Linux-gæst betyder det videresendelse, et FORWARD accept-par og source NAT mod 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-reglen er den del, folk udelader. Virksomhedsroutere ved sjældent, at 192.168.56.0/24 findes; med reglen ser interne servere gæstens tunneladresse og svarer på den, og svaret finder vej tilbage til gæsten.

En Windows-gæst er mere klodset. IPEnableRouter=1 under SYSTEM\CurrentControlSet\Services\Tcpip\Parameters slår videresendelse til uden oversættelse, så det virker kun, hvor virksomhedsrouting allerede peger tilbage på dit host-only-præfiks. Internet Connection Sharing oversætter, men omnummererer den delte adapter til 192.168.137.1, så læs den adresse, den faktisk tog, før du skriver værtsruter.

Kontrol 3: værtsruter navngiver gæsten, ikke tunnelen

Send kun de præfikser, værten har brug for, gennem gæsten. På Linux er én rute per præfiks nok, og den vender rent tilbage:

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

På Windows er ækvivalenten route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. Udelad -p, mens du stadig tester, så en dårlig rute dør ved genstart, og tilføj den, når vejen virker. Fjern ikke værtens standardrute, medmindre hver applikation på værten skal bruge tunnelen; hvis full tunnel virkelig er kravet, tilføj de to /1-ruter og behold den direkte rute til hypervisor-netværket:

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å en Windows-vært skal du også kontrollere interfacemetrikken. En rute, der blev tilføjet, mens host-only-adapteren var deaktiveret, bliver i tabellen, men bærer aldrig trafik, og en anden adapter med lavere metrik kan vinde opslaget for samme præfiks.

Kontrol 4: DNS følger ruten, ikke tunnelens standard

Ruter flytter pakker; resolveren afgør, hvilke navne der skaber pakker. Begræns den virksomhedsresolver til virksomhedszonen i stedet for at erstatte værtens resolver, og peg den på en DNS-server, som den nye rute allerede når. Med systemd-resolved på værten:

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

På Windows gør en post i navneopløsningspolitiktabellen det samme: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. Hvis gæsten kører sin egen resolver på host-only-adressen, brug den adresse i stedet, men først efter at have bekræftet, at den svarer på 192.168.56.2 og ikke på loopback.

Kontrollér derefter MTU, før du bebrejder DNS langsomme sider. Tunnelinterfacet er mindre end værtens 1500-byte-interface, så en vært, der sender segmenter i fuld størrelse med DF-bittet sat, ser dem blive droppet et sted inde i gæsten. Det klassiske symptom er en fungerende ping og en intern webapp, der går i stå efter TLS-håndtrykket. Stram MSS i gæstens videresendelsesvej:

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

Kontrol 5: verificér fra begge ender

Fra værten bør traceroute eller tracert til en intern adresse vise 192.168.56.2 som første hop, ikke den fysiske gateway. I gæsten skal du se det samme forsøg forlade: tcpdump -ni any host 10.20.30.40 viser den videresendte anmodning på host-only-siden og den oversatte på tunnelen. En anmodning, der går ud, kommer tilbage og stadig efterlader værten tavs, peger på returvejen.

To fejl forklarer det meste. Enten bærer gæstens tunnel ingen returrute for host-only-præfikset, fordi NAT-reglen mangler, eller værtsruten peger på en adresse, som gæsten ikke længere har efter en genstart. Læs adresserne igen med ip -br addr og ip route get i stedet for at stole på noter fra sidste session.

Kontrol 6: gør det modstandsdygtigt over for genstart og hypervisor-opgradering

Gør begge halvdele varige: netplan- eller NetworkManager-rutekonfiguration på værten, route add ... -p på Windows og net.ipv4.ip_forward=1 i /etc/sysctl.d/ plus et regelsæt til firewall, der genindlæses i gæsten. Tag et snapshot af gæsten, når konfigurationen er verificeret, før den næste virksomheds-klientopdatering lander.

Host-only-netværk omnummereres, når en hypervisor genskaber sine adaptere, hvilket lydløst ugyldiggør hver rute og NAT-regel bygget på 192.168.56.0/24. Efter en opgradering skal du køre de første tre kontroller igen i rækkefølge; det tager et minut og fanger det tilfælde, hvor værten stadig har sin rute, mens gæsten er flyttet til et nyt subnet.

IPv6 kræver sit eget gennemløb. ip6tables-regler, AAAA-poster og en anden værtsrutefamilie følger ikke IPv4-opsætningen, og en virksomhedstjeneste, der kan nås via IPv6, vil se permanent i stykker ud, mens IPv4 virker.

Bestået eller ej, i rækkefølge: værten kan pinge gæstens host-only-adresse; gæsten videresender og laver MASQUERADE mod tunnelen; ip route get returnerer gæsten som gateway for det interne præfiks; virksomhedsnavne opløses gennem den begrænsede resolver; traceroute viser gæsten først; og de samme seks svar overlever en genstart.