Gasheerverkeer deur 'n VPN in 'n VM lei: ses kontroles

Ses kontroles, in volgorde uitgevoer, bepaal of 'n VM as die VPN-deurlaat vir sy eie gasheer kan dien. Die hipervisor doen niks hiervan vir jou nie: die gas besit die tonnel, die gasheer besit 'n roete, en die netwerk tussen hulle is gewone routering. Ek hou die lys by omdat die oorslaan van een stap altyd dieselfde simptoom lewer, stilte, waar die gasheer die gas vrolik ping en niks intern bereik nie.

Begin by die rede. Of die korporatiewe kliënt installeer net binne die gas, of beleid hou dit daar, en jy het steeds die interne boubediener vanaf die gasheer nodig. As die gasheer sy eie kliënt mag hê, doen dit eerder: een tonnel op die gasheer klop elke keer twee netwerke plus 'n NAT.

Kontrole 1: die gasheer het 'n skakel nodig wat hy kan adresseer

Die gasheer moet 'n koppelvlak besit wat in dieselfde voorvoegsel as die gas se tweede adapter sit. Slegs-gasheer in VirtualBox, slegs-gasheer of 'n pasgemaakte VMnet in VMware Workstation, 'n interne brug of tap-toestel in QEMU/KVM, en 'n interne skakelaar in Hyper-V tel almal. Gas 192.168.56.2, gasheer 192.168.56.1, voorvoegsel 192.168.56.0/24 is die uitleg wat ek in laboratoriums gebruik.

QEMU se gebruikermodus-netwerk (-netdev user, die verstek-SLIRP-agtergrond) en VirtualBox se NAT slaag hierdie kontrole heeltemal nie. Gas-pakkies bereik 'n instaanproses op die gasheer, so die gasheer sien nooit 'n toestel wat die gas se adresse dra nie en het niks om 'n roete na te wys nie. Hyper-V se verstek-skakelaar is dieselfde storie. As ping 192.168.56.2 vanaf die gasheer misluk, stop: geen roete wat later bygevoeg word, sal dit herstel nie.

Kontrole 2: die gas stuur deur en vertaal

Pakkies van die gasheer kom aan met 'n slegs-gasheer-bronadres en 'n interne bestemming, so die gas moet hulle deurstuur en dan agter sy tonneladres wegsteek. Op 'n Linux-gas beteken dit deurstuur, 'n FORWARD-aanvaardingspaar en bron-NAT na die tonnel:

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

Die MASQUERADE-reël is die deel wat mense uitlaat. Korporatiewe routers weet selde dat 192.168.56.0/24 bestaan; met die reël sien interne bedieners die gas se tonneladres en antwoord dit, en die antwoord vind sy pad terug na die gas.

'n Windows-gas is lomper. IPEnableRouter=1 onder SYSTEM\CurrentControlSet\Services\Tcpip\Parameters skakel deurstuur aan sonder vertaling, so dit werk net waar korporatiewe routering reeds na jou slegs-gasheer-voorvoegsel terugwys. Internet Connection Sharing vertaal wel, maar dit hernommer die gedeelde adapter na 192.168.137.1, so lees die adres wat dit werklik ingeneem het voordat jy gasheerroetes skryf.

Kontrole 3: gasheerroetes noem die gas, nie die tonnel nie

Stuur net die voorvoegsels wat die gasheer nodig het deur die gas. Op Linux is een roete per voorvoegsel genoeg en dit keer skoon om:

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

Op Windows is die ekwivalent route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. Laat -p uit terwyl jy nog toets, sodat 'n slegte roete met herbegin sterf, en voeg dit by sodra die pad werk. Moenie die gasheer se verstekroete verwyder nie, tensy elke gasheerprogram die tonnel moet gebruik; as volle tonnel regtig die vereiste is, voeg die twee /1-roetes by en hou die skakel-roete na die hipervisor-netwerk:

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 'n Windows-gasheer, kyk ook na die koppelvlakmaatstaf. 'n Roete wat bygevoeg is terwyl die slegs-gasheer-adapter gedeaktiveer was, bly in die tabel maar dra nooit verkeer nie, en 'n tweede adapter met 'n laer maatstaf kan die opsoek vir dieselfde voorvoegsel wen.

Kontrole 4: DNS volg die roete, nie die tonnel se verstek nie

Roetes skuif pakkies; die oplosser besluit watter name pakkies lewer. Beperk die korporatiewe oplosser tot die korporatiewe sone in plaas daarvan om die gasheer se oplosser te vervang, en wys dit na 'n DNS-bediener wat die nuwe roete reeds bereik. Met systemd-resolved op die gasheer:

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

Op Windows doen 'n inskrywing in die naamoplossingsbeleidstabel dieselfde werk: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. As die gas sy eie oplosser op die slegs-gasheer-adres laat loop, gebruik daardie adres eerder, maar eers nadat jy bevestig het dat dit op 192.168.56.2 antwoord en nie op loopback nie.

Kontroleer dan die MTU voordat jy DNS blameer vir stadige bladsye. Die tonnelkoppelvlak is kleiner as die gasheer se 1500-greep-koppelvlak, so 'n gasheer wat volgrootte segmente met die DF-bietjie gestel stuur, kry hulle iewers binne die gas laat val. Die klassieke simptoom is 'n werkende ping en 'n interne webtoepassing wat ná die TLS-handdruk vassteek. Knyp MSS in die gas se deurstuurpad:

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

Kontrole 5: verifieer van beide kante

Vanaf die gasheer moet traceroute of tracert na 'n interne adres 192.168.56.2 as die eerste hop wys, nie die fisiese deurlaat nie. In die gas, kyk hoe dieselfde poging uitgaan: tcpdump -ni any host 10.20.30.40 wys die deurgestuurde versoek aan die slegs-gasheer-kant en die vertaalde een op die tonnel. 'n Versoek wat uitgaan, terugkom en die gasheer steeds stil laat, wys na die terugpad.

Twee foute verantwoord die meeste daarvan. Of die gas se tonnel dra geen roete terug vir die slegs-gasheer-voorvoegsel nie omdat die NAT-reël ontbreek, óf die gasheerroete wys na 'n adres wat die gas ná 'n herbegin nie meer het nie. Lees die adresse weer met ip -br addr en ip route get eerder as om notas van die vorige sessie te vertrou.

Kontrole 6: laat dit 'n herbegin en 'n hipervisor-opgradering oorleef

Bewaar beide helftes: netplan- of NetworkManager-roetekonfigurasie op die gasheer, route add ... -p op Windows, en net.ipv4.ip_forward=1 in /etc/sysctl.d/ plus 'n vuurmuurreëlstel wat in die gas herlaai. Neem 'n momentopname van die gas sodra die konfigurasie verifieer, voordat die volgende korporatiewe kliëntopdatering land.

Slegs-gasheer-netwerke word hernommer wanneer 'n hipervisor sy adapters herskep, wat elke roete en NAT-reël wat op 192.168.56.0/24 gebou is, stil ongeldig maak. Herhaal ná 'n opgradering die eerste drie kontroles in volgorde; dit kos 'n minuut en vang die geval waar die gasheer nog sy roete het terwyl die gas na 'n nuwe subnet geskuif het.

IPv6 het sy eie ronde nodig. ip6tables-reëls, AAAA-rekords en 'n tweede gasheerroete-familie volg nie die IPv4-opstelling nie, en 'n korporatiewe diens wat oor IPv6 bereikbaar is, sal permanent stukkend lyk terwyl IPv4 werk.

Slaag of misluk, in volgorde: gasheer kan die gas se slegs-gasheer-adres ping; die gas stuur deur en MASQUERADE na die tonnel; ip route get gee die gas as deurlaat vir die interne voorvoegsel terug; korporatiewe name los op deur die beperkte oplosser; traceroute wys die gas eerste; en dieselfde ses antwoorde oorleef 'n herbegin.