Hostferkear troch in VPN yn in VM liede: seis kontrôles

Seis kontrôles, op folchoarder útfierd, beslisse oft in VM tsjinje kin as VPN-poarte foar syn eigen host. De hypervisor docht hjirfan neat foar jo: de gast hat de tunnel, de host hat in rûte, en it netwurk dertusken is gewoane routing. Ik hâld de list by, want it oerslaan fan ien stap jout altyd itselde symptoom, stilte, wêrby't de host de gast fleurich pinget en neat intern berikt.

Begjin by de reden. Of de bedriuwsclient wurdt allinnich yn de gast ynstallearre, of it belied hâldt him dêr, en jo hawwe noch altyd de interne build-tsjinner fan 'e host nedich. As de host syn eigen client hawwe mei, doch dat dan: ien tunnel op 'e host wint altyd fan twa netwurken plus in NAT.

Kontrôle 1: de host hat in keppeling nedich dy't er adressearje kin

De host moat in ynterface hawwe yn itselde foarheaksel as de twadde adapter fan 'e gast. Host-only yn VirtualBox, host-only of in oanpast VMnet yn VMware Workstation, in ynterne brêge of tap-apparaat yn QEMU/KVM, en in Internal-skeakelder yn Hyper-V foldogge allegear. Gast 192.168.56.2, host 192.168.56.1, foarheaksel 192.168.56.0/24 is de yndieling dy't ik yn laboratoaria brûk.

QEMU-netwurkjen yn brûkersmodus (-netdev user, de standert SLIRP-backend) en VirtualBox NAT misse dizze kontrôle folslein. Pakketten fan 'e gast berikke in proxyproses op 'e host, dat de host sjocht nea in apparaat dat de adressen fan 'e gast draacht en hat neat om in rûte nei te wizen. De Default Switch fan Hyper-V is itselde ferhaal. As ping 192.168.56.2 fan 'e host mislearret, stop dan: gjin rûte dy't letter tafoege wurdt, sil dat reparearje.

Kontrôle 2: de gast stjoert troch en oerset

Pakketten fan 'e host komme oan mei in host-only boarneadres en in ynterne bestimming, dat de gast moat se trochstjoere en dan efter syn tunneladres ferskûlje. Op in Linux-gast betsjut dat trochstjoere, in FORWARD accept-pear en source NAT nei de tunnel ta:

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

De MASQUERADE-regel is it part dat minsken weilitte. Bedriuwsrouters witte selden dat 192.168.56.0/24 bestiet; mei de regel sjogge ynterne tsjinners it tunneladres fan 'e gast en antwurdzje dêrop, en it antwurd fynt syn wei werom nei de gast.

In Windows-gast is knoffeliger. IPEnableRouter=1 ûnder SYSTEM\CurrentControlSet\Services\Tcpip\Parameters set trochstjoeren oan sûnder oersetting, dat it wurket allinnich dêr't bedriuwsrouting al werom wiist nei jo host-only foarheaksel. Internet Connection Sharing oerset wol, mar it fernûmeret de dielde adapter nei 192.168.137.1, dat lês it adres dat er eins naam foardat jo hostrûtes skriuwe.

Kontrôle 3: hostrûtes neame de gast, net de tunnel

Stjoer allinnich de foarheaksels dy't de host nedich hat troch de gast. Op Linux is ien rûte per foarheaksel genôch en it draait skjin werom:

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

Op Windows is it ekwulint route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. Litte -p weilje wylst jo noch teste, sadat in minne rûte by in werstart stjert, en foegje it ta as it paad wurket. Ferwiderje de standertrûte fan 'e host net, útsein as elke applikaasje op 'e host de tunnel brûke moat; as folsleine tunnel echt de eask is, foegje de twa /1-rûtes ta en hâld de direkte rûte nei it hypervisor-netwurk:

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

Op in Windows-host, kontrolearje ek de ynterfacemetryk. In rûte dy't tafoege waard wylst de host-only adapter útskeakele wie, bliuwt yn 'e tabel mar draacht nea ferkear, en in twadde adapter mei in legere metryk kin de syktocht foar itselde foarheaksel winne.

Kontrôle 4: DNS folget de rûte, net it standertpaad fan 'e tunnel

Rûtes ferpleatse pakketten; de resolver beslút hokker nammen pakketten meitsje. Behein de bedriuwsresolver ta de bedriuwssône yn stee fan de resolver fan 'e host te ferfangen, en wiis him nei in DNS-tsjinner dy't de nije rûte al berikt. Mei systemd-resolved op 'e host:

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

Op Windows docht in ynskriuwing yn 'e namme-oplossingsbeliedstabel itselde wurk: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. As de gast syn eigen resolver op it host-only adres draait, brûk dat adres yn stee, mar pas nei't jo befêstige hawwe dat it op 192.168.56.2 antwurdet en net op loopback.

Kontrolearje dan de MTU foardat jo DNS de skuld jouwe fan stadige siden. De tunnel-ynterface is lytser as de 1500-byte-ynterface fan 'e host, dat in host dy't segminten fan folsleine grutte mei de DF-bit oanset stjoert, krijt se earne yn 'e gast weilitten. It klassike symptoom is in wurkjende ping en in ynterne webapp dy't nei de TLS-hânskodding fêstrint. Knyp de MSS yn it trochstjoerpaad fan 'e gast:

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

Kontrôle 5: ferifiearje fan beide kanten

Fan 'e host moat traceroute of tracert nei in yntern adres 192.168.56.2 as earste hop sjen litte, net de fysike poarte. Yn 'e gast, sjoch hoe't deselde poging út giet: tcpdump -ni any host 10.20.30.40 lit it trochstjoerde fersyk oan 'e host-only kant sjen en it oersette op 'e tunnel. In fersyk dat út giet, werom komt en de host dochs stil lit, wiist nei it weromwei.

Twa flaters ferklearje it measte hjirfan. Of de tunnel fan 'e gast draacht gjin weromrûte foar it host-only foarheaksel om't de NAT-regel mist, of de hostrûte wiist nei in adres dat de gast nei in werstart net mear hat. Lês de adressen opnij mei ip -br addr en ip route get yn stee fan te fertrouwen op notysjes fan 'e foarige sesje.

Kontrôle 6: meitsje it bestindich foar in werstart en in hypervisor-opwurdearring

Hâld beide helten fêst: netplan- of NetworkManager-rûtekonfiguraasje op 'e host, route add ... -p op Windows, en net.ipv4.ip_forward=1 yn /etc/sysctl.d/ plus in fjoermuorre-regelset dat yn 'e gast wer lade wurdt. Meitsje in snapshot fan 'e gast sadree't de konfiguraasje ferifiearre is, foardat de folgjende bedriuwsclient-bywurking komt.

Host-only netwurken wurde fernûmere as in hypervisor syn adapters opnij makket, wat stilwei elke rûte en NAT-regel ûnjildich makket dy't op 192.168.56.0/24 boud is. Nei in opwurdearring, fier de earste trije kontrôles op folchoarder wer út; dat kostet in minút en fangt it gefal wêrby't de host syn rûte noch hat wylst de gast nei in nij subnet ferhuze is.

IPv6 hat syn eigen trochgong nedich. Regels fan ip6tables, AAAA-records en in twadde hostrûte-famylje folgje de IPv4-ynstelling net, en in bedriuwstsjinst dy't oer IPv6 berikber is, sil permanint stikken lykje wylst IPv4 wurket.

Slaagd of net, op folchoarder: de host kin it host-only adres fan 'e gast pingje; de gast stjoert troch en docht MASQUERADE nei de tunnel; ip route get jout de gast as poarte foar it ynterne foarheaksel werom; bedriuwsnammen wurde oplost fia de beheinde resolver; traceroute lit de gast earst sjen; en deselde seis antwurden oerlibje in werstart.