Usmerjanje prometa gostitelja skozi VPN v VM: šest preverjanj

Šest preverjanj, izvedenih po vrsti, odloči, ali je VM lahko prehod VPN za svojega lastnega gostitelja. Hipervizor ničesar od tega ne naredi namesto vas: tunel ima gost, pot ima gostitelj, omrežje med njima pa je običajno usmerjanje. Seznam držim zato, ker preskok enega koraka vedno da isti simptom, tišino, ko gostitelj veselo pinga gosta in ne doseže ničesar notranjega.

Začnite z razlogom. Ali se poslovni odjemalec namesti samo znotraj gosta, ali pa ga politika zadrži tam, in še vedno potrebujete notranji strežnik build z gostitelja. Če sme imeti gostitelj svojega odjemalca, naredite to: en tunel na gostitelju vedno premaga dve omrežji plus NAT.

Preverjanje 1: gostitelj potrebuje povezavo, ki ji lahko dodeli naslov

Gostitelj mora imeti vmesnik v istem predponi kot drugi adapter gosta. Host-only v VirtualBoxu, host-only ali lasten VMnet v VMware Workstation, notranji most ali naprava tap v QEMU/KVM in stikalo Internal v Hyper-V so vsi primerni. Gost 192.168.56.2, gostitelj 192.168.56.1, predpona 192.168.56.0/24 je postavitev, ki jo uporabljam v laboratorijih.

Omrežje QEMU v uporabniškem načinu (-netdev user, privzeti backend SLIRP) in NAT VirtualBoxa popolnoma padeta na tem preverjanju. Paketi gosta dosežejo posredniški proces na gostitelju, zato gostitelj nikoli ne vidi naprave, ki bi nosila naslove gosta, in nima kam usmeriti poti. Default Switch v Hyper-V je ista zgodba. Če ping 192.168.56.2 z gostitelja ne uspe, se ustavite: nobena pozneje dodana pot tega ne popravi.

Preverjanje 2: gost posreduje in prevaja

Paketi z gostitelja prispejo z izvornim naslovom iz omrežja host-only in notranjim ciljem, zato jih mora gost posredovati in nato skriti za naslovom svojega tunela. Na gostu Linux to pomeni posredovanje, par FORWARD accept in source NAT proti tunelu:

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

Pravilo MASQUERADE je tisti del, ki ga ljudje izpustijo. Poslovni usmerjevalniki le redko vedo, da 192.168.56.0/24 obstaja; s pravilom notranji strežniki vidijo naslov tunela gosta in nanj odgovorijo, odgovor pa najde pot nazaj do gosta.

Gost Windows je nerodnejši. IPEnableRouter=1 pod SYSTEM\CurrentControlSet\Services\Tcpip\Parameters vklopi posredovanje brez prevajanja, zato deluje le tam, kjer poslovno usmerjanje že kaže nazaj na vašo predpono host-only. Internet Connection Sharing prevaja, vendar preštevilči skupni adapter na 192.168.137.1, zato preberite naslov, ki ga je dejansko prevzel, preden napišete poti gostitelja.

Preverjanje 3: poti gostitelja imenujejo gosta, ne tunela

Skozi gosta pošiljajte le predpone, ki jih gostitelj potrebuje. V Linuxu zadostuje ena pot na predpono in se čisto obrne:

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

V Windowsu je ustreznica route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. Med preizkušanjem pustite -p izklopljen, da slaba pot umre ob ponovnem zagonu, in ga dodajte, ko pot deluje. Ne odstranite privzete poti gostitelja, razen če mora vsaka aplikacija na gostitelju uporabljati tunel; če je polni tunel res zahteva, dodajte dve poti /1 in obdržite neposredno pot v omrežje hipervizorja:

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

Na gostitelju Windows preverite tudi metriko vmesnika. Pot, dodana medtem ko je bil adapter host-only onemogočen, ostane v tabeli, vendar nikoli ne prenaša prometa, in drugi adapter z nižjo metriko lahko dobi iskanje za isto predpono.

Preverjanje 4: DNS sledi poti, ne privzeti nastavitvi tunela

Poti premikajo pakete; razreševalnik odloči, katera imena ustvarijo pakete. Omejite poslovni razreševalnik na poslovno območje, namesto da bi zamenjali razreševalnik gostitelja, in ga usmerite na strežnik DNS, ki ga nova pot že doseže. S systemd-resolved na gostitelju:

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

V Windowsu enako naredi vnos v tabeli pravil razreševanja imen: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. Če gost poganja svoj razreševalnik na naslovu host-only, uporabite ta naslov, a šele potem, ko potrdite, da odgovarja na 192.168.56.2 in ne na loopback.

Nato preverite MTU, preden krivite DNS za počasne strani. Vmesnik tunela je manjši od 1500-bajtnega vmesnika gostitelja, zato gostitelj, ki pošilja segmente polne velikosti z nastavljenim bitom DF, vidi, da se izgubijo nekje znotraj gosta. Klasičen simptom je delujoč ping in notranja spletna aplikacija, ki se po rokovanju TLS ustavi. Zategnite MSS na poti posredovanja v gostu:

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

Preverjanje 5: preverite z obeh koncev

Z gostitelja naj traceroute ali tracert na notranji naslov pokaže 192.168.56.2 kot prvi skok, ne fizičnega prehoda. V gostu opazujte, kako isti poskus odhaja: tcpdump -ni any host 10.20.30.40 pokaže posredovano zahtevo na strani host-only in prevedeno na tunelu. Zahteva, ki odide, se vrne in gostitelja vseeno pusti tihega, kaže na povratno pot.

Dve napaki pojasnita večino tega. Ali tunel gosta ne nosi povratne poti za predpono host-only, ker manjka pravilo NAT, ali pa pot gostitelja kaže na naslov, ki ga gost po ponovnem zagonu nima več. Znova preberite naslove s ip -br addr in ip route get, namesto da bi zaupali zapiskom prejšnje seje.

Preverjanje 6: poskrbite, da preživi ponovni zagon in nadgradnjo hipervizorja

Ohranite obe polovici: konfiguracijo poti netplan ali NetworkManager na gostitelju, route add ... -p v Windowsu in net.ipv4.ip_forward=1 v /etc/sysctl.d/ plus nabor pravil požarnega zidu, ki se v gostu znova naloži. Naredite posnetek gosta takoj, ko je konfiguracija potrjena, preden prispe naslednja posodobitev poslovnega odjemalca.

Omrežja host-only se preštevilčijo, ko hipervizor znova ustvari svoje adapterje, kar tiho razveljavi vsako pot in pravilo NAT, zgrajeno na 192.168.56.0/24. Po nadgradnji znova zaženite prva tri preverjanja po vrsti; to vzame minuto in ujame primer, ko ima gostitelj svojo pot še vedno, medtem ko se je gost preselil v novo podomrežje.

IPv6 potrebuje svoj prehod. Pravila ip6tables, zapisi AAAA in druga družina poti gostitelja ne sledijo nastavitvi IPv4, in poslovna storitev, dostopna prek IPv6, bo videti trajno pokvarjena, medtem ko IPv4 deluje.

Uspelo ali ne, po vrsti: gostitelj lahko pinga naslov host-only gosta; gost posreduje in izvede MASQUERADE proti tunelu; ip route get vrne gosta kot prehod za notranjo predpono; poslovna imena se razrešijo prek omejenega razreševalnika; traceroute pokaže gosta prvega; in istih šest odgovorov preživi ponovni zagon.