Usmjeravanje prometa hosta kroz VPN u VM-u: šest provjera

Šest provjera, izvedenih po redu, odlučuje može li VM biti VPN pristupnik za vlastiti host. Hipervizor ništa od toga ne radi za vas: gost posjeduje tunel, host posjeduje rutu, a mreža između njih je obično usmjeravanje. Držim ovaj popis jer preskakanje jednog koraka uvijek daje isti simptom, tišinu, gdje host veselo pinga gosta i ne doseže ništa interno.

Počnite s razlogom. Ili se korporativni klijent instalira samo unutar gosta, ili ga politika drži tamo, a vama i dalje treba interni build poslužitelj s hosta. Ako host smije imati vlastiti klijent, učinite to umjesto toga: jedan tunel na hostu uvijek je bolji od dvije mreže plus NAT.

Provjera 1: hostu treba veza kojoj može dodijeliti adresu

Host mora imati sučelje u istom prefiksu u kojem je drugi adapter gosta. Host-only u VirtualBoxu, host-only ili prilagođeni VMnet u VMware Workstationu, interni most ili tap uređaj u QEMU/KVM-u i Internal prekidač u Hyper-V-u svi zadovoljavaju. Gost 192.168.56.2, host 192.168.56.1, prefiks 192.168.56.0/24 raspored je koji koristim u laboratorijima.

QEMU mreža u korisničkom načinu rada (-netdev user, zadani SLIRP pozadinski sustav) i VirtualBox NAT padaju na ovoj provjeri posve. Paketi gosta dolaze do proxy procesa na hostu, pa host nikad ne vidi uređaj koji nosi adrese gosta i nema kamo usmjeriti rutu. Default Switch u Hyper-V-u ista je priča. Ako ping 192.168.56.2 s hosta ne uspije, stanite: nikakva ruta dodana kasnije to neće popraviti.

Provjera 2: gost prosljeđuje i prevodi

Paketi s hosta dolaze s izvorišnom adresom iz host-only mreže i internim odredištem, pa ih gost mora proslijediti i zatim sakriti iza adrese svog tunela. Na Linux gostu to znači prosljeđivanje, par FORWARD accept pravila i source NAT prema 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 dio koji ljudi izostavljaju. Korporativni usmjerivači rijetko znaju da 192.168.56.0/24 postoji; s pravilom interni poslužitelji vide adresu tunela gosta i odgovaraju na nju, a odgovor pronalazi put natrag do gosta.

Windows gost je nespretniji. IPEnableRouter=1 pod SYSTEM\CurrentControlSet\Services\Tcpip\Parameters uključuje prosljeđivanje bez prevođenja, pa radi samo tamo gdje korporativno usmjeravanje već pokazuje natrag na vaš host-only prefiks. Internet Connection Sharing prevodi, ali ponovno numerira zajednički adapter na 192.168.137.1, pa pročitajte adresu koju je stvarno zauzeo prije pisanja host ruta.

Provjera 3: host rute imenuju gosta, ne tunel

Kroz gosta šaljite samo prefikse koje host treba. Na Linuxu je dovoljna jedna ruta po prefiksu i čisto se vraća:

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

Na Windowsu je ekvivalent route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. Ostavite -p dok još testirate, da loša ruta umre pri restartu, i dodajte ga kad put proradi. Ne uklanjajte zadanu rutu hosta osim ako svaka aplikacija na hostu treba koristiti tunel; ako je puni tunel stvarno uvjet, dodajte dvije /1 rute i zadržite izravnu rutu prema mreži hipervizora:

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 Windows hostu provjerite i metriku sučelja. Ruta dodana dok je host-only adapter bio onemogućen ostaje u tablici ali nikad ne nosi promet, a drugi adapter s nižom metrikom može pobijediti u pretraživanju za isti prefiks.

Provjera 4: DNS slijedi rutu, ne zadani smjer tunela

Rute pomiču pakete; razrješivač odlučuje koji nazivi stvaraju pakete. Ograničite korporativni razrješivač na korporativnu zonu umjesto da zamijenite razrješivač hosta i usmjerite ga na DNS poslužitelj do kojeg nova ruta već doseže. Uz systemd-resolved na hostu:

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

Na Windowsu zapis u tablici pravila razrješavanja naziva radi isti posao: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. Ako gost pokreće vlastiti razrješivač na host-only adresi, upotrijebite tu adresu umjesto toga, ali tek nakon što potvrdite da odgovara na 192.168.56.2, a ne na loopback.

Zatim provjerite MTU prije nego što okrivite DNS za spore stranice. Sučelje tunela manje je od 1500-bajtnog sučelja hosta, pa host koji šalje segmente pune veličine s postavljenim DF bitom gubi ih negdje unutar gosta. Klasičan simptom je radni ping i interna web aplikacija koja zastane nakon TLS rukovanja. Stegnite MSS na putu prosljeđivanja u gostu:

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

Provjera 5: provjerite s oba kraja

S hosta traceroute ili tracert na internu adresu treba pokazati 192.168.56.2 kao prvi skok, a ne fizički pristupnik. U gostu promatrajte kako isti pokušaj izlazi: tcpdump -ni any host 10.20.30.40 pokazuje proslijeđeni zahtjev na host-only strani i prevedeni na tunelu. Zahtjev koji izađe, vrati se i ipak ostavi host nijemim upućuje na povratni put.

Dvije greške objašnjavaju većinu toga. Ili tunel gosta ne nosi povratnu rutu za host-only prefiks jer nema NAT pravila, ili host ruta pokazuje na adresu koju gost više ne drži nakon restarta. Ponovno pročitajte adrese s ip -br addr i ip route get umjesto da vjerujete bilješkama iz prošle sesije.

Provjera 6: učinite da preživi restart i nadogradnju hipervizora

Trajno sačuvajte obje polovice: netplan ili NetworkManager konfiguraciju ruta na hostu, route add ... -p na Windowsu i net.ipv4.ip_forward=1 u /etc/sysctl.d/ plus skup pravila vatrozida koji se ponovno učitava u gostu. Snimite snapshot gosta čim se konfiguracija potvrdi, prije nego stigne sljedeće ažuriranje korporativnog klijenta.

Host-only mreže se ponovno numeriraju kad hipervizor ponovno stvori svoje adaptere, što tiho poništava svaku rutu i NAT pravilo izgrađeno na 192.168.56.0/24. Nakon nadogradnje ponovite prve tri provjere po redu; to traje minutu i hvata slučaj u kojem host još ima svoju rutu dok je gost prešao na novu podmrežu.

IPv6 traži vlastiti prolaz. Pravila ip6tables, AAAA zapisi i druga obitelj host ruta ne slijede IPv4 postavke, a korporativna usluga dostupna preko IPv6 izgledat će trajno pokvarena dok IPv4 radi.

Prošlo ili palo, po redu: host može pingati host-only adresu gosta; gost prosljeđuje i radi MASQUERADE prema tunelu; ip route get vraća gosta kao pristupnik za interni prefiks; korporativni nazivi razrješavaju se kroz ograničeni razrješivač; traceroute pokazuje gosta prvim; i istih šest odgovora preživi restart.