Rrugëtimi i trafikut të hostit përmes një VPN në një VM: gjashtë kontrolle

Gjashtë kontrolle, të kryera me radhë, vendosin nëse një VM mund të shërbejë si portë VPN për hostin e vetë. Hipervizori nuk bën asgjë nga kjo për ju: tuneli i përket mysafirit, rruga i përket hostit, dhe rrjeti midis tyre është rrugëtim i zakonshëm. E mbaj listën sepse kalimi i një hapi gjithmonë jep të njëjtin simptomë, heshtjen, kur hosti e pingon mysafirin me gëzim dhe nuk arrin asgjë të brendshme.

Filloni nga arsyeja. Ose klienti korporativ instalohet vetëm brenda mysafirit, ose politika e mban atje, dhe ju ende ju duhet serveri i ndërtimit të brendshëm nga hosti. Nëse hostit i lejohet klienti i vet, bëni atë në vend të kësaj: një tunel në host fiton gjithmonë dy rrjete plus një NAT.

Kontrolli 1: hostit i duhet një lidhje të cilës mund t'i japë adresë

Hosti duhet të ketë një ndërfaqe në të njëjtin prefiks si përshtatësi i dytë i mysafirit. Host-only në VirtualBox, host-only ose një VMnet e personalizuar në VMware Workstation, një urë e brendshme ose pajisje tap në QEMU/KVM dhe një çelës Internal në Hyper-V të gjitha kualifikohen. Mysafir 192.168.56.2, host 192.168.56.1, prefiks 192.168.56.0/24 është skema që përdor në laboratorë.

Rrjeti QEMU në modalitetin e përdoruesit (-netdev user, backend-i SLIRP i parazgjedhur) dhe NAT i VirtualBox dështojnë plotësisht në këtë kontroll. Paketat e mysafirit arrijnë në një proces proxy në host, kështu që hosti nuk sheh kurrë një pajisje që mban adresat e mysafirit dhe nuk ka ku të drejtojë një rrugë. Default Switch i Hyper-V është e njëjta histori. Nëse ping 192.168.56.2 nga hosti dështon, ndaloni: asnjë rrugë e shtuar më vonë nuk e rregullon atë.

Kontrolli 2: mysafiri përcjell dhe përkthen

Paketat nga hosti vijnë me një adresë burimore host-only dhe një destinacion të brendshëm, prandaj mysafiri duhet t'i përcjellë dhe më pas t'i fshehë pas adresës së tunelit të vet. Në një mysafir Linux kjo do të thotë përcjellje, një çift FORWARD accept dhe source NAT drejt tunelit:

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

Rregulli MASQUERADE është pjesa që njerëzit e lënë jashtë. Ruterat korporativë rrallë e dinë se 192.168.56.0/24 ekziston; me rregullin, serverët e brendshëm shohin adresën e tunelit të mysafirit dhe i përgjigjen asaj, dhe përgjigja gjen rrugën përsëri te mysafiri.

Një mysafir Windows është më i ngathët. IPEnableRouter=1 nën SYSTEM\CurrentControlSet\Services\Tcpip\Parameters ndez përcjelljen pa përkthim, prandaj funksionon vetëm atje ku rrugëtimi korporativ tashmë tregon përsëri drejt prefiksit tuaj host-only. Internet Connection Sharing përkthen, por e rinumëron përshtatësin e përbashkët në 192.168.137.1, prandaj lexoni adresën që mori në të vërtetë përpara se të shkruani rrugët e hostit.

Kontrolli 3: rrugët e hostit emërtojnë mysafirin, jo tunelin

Dërgoni përmes mysafirit vetëm prefikset që i nevojiten hostit. Në Linux mjafton një rrugë për prefiks dhe ajo kthehet pastër:

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

Në Windows ekuivalenti është route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. Lëreni -p jashtë ndërsa testoni, që një rrugë e keqe të vdesë në rinisje, dhe shtojeni kur rruga funksionon. Mos e hiqni rrugën e parazgjedhur të hostit, përveçse nëse çdo aplikacion në host duhet ta përdorë tunelin; nëse tuneli i plotë është vërtet kërkesa, shtoni dy rrugët /1 dhe mbani rrugën e drejtpërdrejtë drejt rrjetit të hipervizorit:

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

Në një host Windows, kontrolloni edhe metrikën e ndërfaqes. Një rrugë e shtuar ndërsa përshtatësi host-only ishte i çaktivizuar mbetet në tabelë por nuk mbart kurrë trafik, dhe një përshtatës i dytë me metrikë më të ulët mund të fitojë kërkimin për të njëjtin prefiks.

Kontrolli 4: DNS ndjek rrugën, jo parazgjedhjen e tunelit

Rrugët lëvizin paketat; zgjidhësi vendos cilat emra prodhojnë paketa. Kufizoni zgjidhësin korporativ në zonën korporative në vend që të zëvendësoni zgjidhësin e hostit, dhe drejtojeni atë në një server DNS që rruga e re tashmë e arrin. Me systemd-resolved në host:

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

Në Windows një hyrje në tabelën e politikës së zgjidhjes së emrave bën të njëjtën punë: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. Nëse mysafiri drejton zgjidhësin e vet në adresën host-only, përdorni atë adresë, por vetëm pasi të konfirmoni se përgjigjet në 192.168.56.2 dhe jo në loopback.

Pastaj kontrolloni MTU përpara se t'i vini fajin DNS për faqe të ngadalta. Ndërfaqja e tunelit është më e vogël se ndërfaqja 1500 bajt e hostit, prandaj një host që dërgon segmente me madhësi të plotë me bitin DF të ndezur i sheh ato të hidhen diku brenda mysafirit. Simptoma klasike është një ping që funksionon dhe një aplikacion web i brendshëm që ngec pas shtrëngimit të duarve TLS. Shtrëngoni MSS në rrugën e përcjelljes të mysafirit:

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

Kontrolli 5: verifikoni nga të dy skajet

Nga hosti, traceroute ose tracert drejt një adrese të brendshme duhet të tregojë 192.168.56.2 si hopin e parë, jo portën fizike. Në mysafir, shikoni të njëjtin përpjekje duke dalë: tcpdump -ni any host 10.20.30.40 tregon kërkesën e përcjellë në anën host-only dhe atë të përkthyer në tunel. Një kërkesë që del, kthehet dhe megjithatë e lë hostin heshtur tregon rrugën e kthimit.

Dy dështime shpjegojnë pjesën më të madhe të kësaj. Ose tuneli i mysafirit nuk mbart rrugë kthimi për prefiksin host-only sepse mungon rregulli NAT, ose rruga e hostit tregon një adresë që mysafiri nuk e ka më pas një rinisjeje. Rilexoni adresat me ip -br addr dhe ip route get në vend që t'u besoni shënimeve të sesionit të kaluar.

Kontrolli 6: bëni që t'i mbijetojë një rinisjeje dhe një përditësimi të hipervizorit

Mbajini të dyja gjysmat të përhershme: konfigurimin e rrugëve netplan ose NetworkManager në host, route add ... -p në Windows dhe net.ipv4.ip_forward=1 në /etc/sysctl.d/ plus një grup rregullash të murit të zjarrit që ringarkohet në mysafir. Bëni një snapshot të mysafirit sapo konfigurimi verifikohet, përpara se të vijë përditësimi tjetër i klientit korporativ.

Rrjetet host-only rinumërohen kur një hipervizor i rikrijon përshtatësit e vet, gjë që heshtazi zhvleftëson çdo rrugë dhe rregull NAT të ndërtuar mbi 192.168.56.0/24. Pas një përditësimi, përsëritni tre kontrollet e para me radhë; kjo kushton një minutë dhe kap rastin kur hosti e ka ende rrugën e vet ndërsa mysafiri është zhvendosur në një nënrrjet të ri.

IPv6 kërkon kalimin e vet. Rregullat ip6tables, regjistrimet AAAA dhe një familje e dytë rrugësh të hostit nuk ndjekin konfigurimin IPv4, dhe një shërbim korporativ i aksesueshëm përmes IPv6 do të duket përgjithmonë i prishur ndërsa IPv4 funksionon.

Kaluar apo jo, me radhë: hosti mund ta pingojë adresën host-only të mysafirit; mysafiri përcjell dhe bën MASQUERADE drejt tunelit; ip route get e kthen mysafirin si portë për prefiksin e brendshëm; emrat korporativë zgjidhen përmes zgjidhësit të kufizuar; traceroute e tregon mysafirin i pari; dhe të njëjtat gjashtë përgjigje i mbijetojnë një rinisjeje.