Leiða umferð hýsisins í gegnum VPN í VM: sex prófanir

Sex prófanir, framkvæmdar í röð, ákvarða hvort VM geti verið VPN-gátt fyrir eigin hýsil. Hypervisor gerir ekkert af þessu fyrir þig: gesturinn á tunnilinn, hýsillinn á leið, og netið þar á milli er venjuleg leiðarstýring. Ég held þessum lista því að sleppa einu skrefi gefur alltaf sama einkenni, þögn, þar sem hýsillinn pingar gestinn glaður og nær engu innra.

Byrjaðu á ástæðunni. Annaðhvort er fyrirtækjaskjáþyrillinn aðeins settur upp inni í gestinum, eða stefnan heldur honum þar, og þú þarft samt innri byggingarþjóninn frá hýsilnum. Ef hýsillinn má hafa eigin skjáþyril skaltu gera það í staðinn: einn tunnill á hýsilnum vinnur alltaf á tveimur netum plús NAT.

Prófun 1: hýsillinn þarf tengingu sem hann getur gefið tölu

Hýsillinn verður að eiga viðmót í sama forskeyti og annar millistykki gestanna. Host-only í VirtualBox, host-only eða sérsniðið VMnet í VMware Workstation, innri brú eða tap-tæki í QEMU/KVM og Internal rofi í Hyper-V standast öll. Gestur 192.168.56.2, hýsill 192.168.56.1, forskeyti 192.168.56.0/24 er uppsetningin sem ég nota í rannsóknarstofum.

QEMU-net í notendaham (-netdev user, sjálfgefni SLIRP-bakendinn) og NAT VirtualBox falla algjörlega á þessari prófun. Pakkar gestanna ná í milliþjónustu á hýsilnum, þannig að hýsillinn sér aldrei tæki sem ber tölur gestanna og hefur ekkert til að beina leið að. Default Switch Hyper-V er sama saga. Ef ping 192.168.56.2 frá hýsilnum mistekst skaltu stoppa: engin leið sem bætt er við síðar lagar það.

Prófun 2: gesturinn endursendir og þýðir

Pakkar frá hýsilnum koma með upprunatölu úr host-only netinu og innri áfangastað, svo gesturinn verður að endursenda þá og fela þá síðan bak við tunniltöluna sína. Á Linux-gesti þýðir það endursendingu, FORWARD accept-par og source NAT í átt að tunnilnum:

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

MASQUERADE-reglan er sá hluti sem fólk sleppir. Fyrirtækjabeinar vita sjaldan að 192.168.56.0/24 er til; með reglunni sjá innri netþjónar tunniltölu gestanna og svara henni, og svarið finnur leið sína til baka til gestanna.

Windows-gestur er klaufalegri. IPEnableRouter=1 undir SYSTEM\CurrentControlSet\Services\Tcpip\Parameters kveikir á endursendingu án þýðingar, svo það virkar aðeins þar sem fyrirtækjaleiðarstýring bendir þegar til baka á host-only forskeytið þitt. Internet Connection Sharing þýðir, en endurnúmerar sameiginlega millistykkinn í 192.168.137.1, svo lestu töluna sem hann tók í raun áður en þú skrifar leiðir hýsisins.

Prófun 3: leiðir hýsisins nefna gestinn, ekki tunnilinn

Sendu aðeins forskeytin sem hýsillinn þarf í gegnum gestinn. Á Linux er ein leið á hvert forskeyti nóg og hún snýst hreint við:

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

Á Windows er hliðstæðan route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. Láttu -p vera úti á meðan þú prófar, svo slæm leið deyi við endurræsingu, og bættu því við þegar leiðin virkar. Ekki fjarlægja sjálfgefnu leið hýsisins nema hvert forrit á hýsilnum eigi að nota tunnilinn; ef fullur tunnill er raunverulega krafan skaltu bæta við tveimur /1 leiðum og halda beinu leiðinni að neti hypervisorsins:

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

Á Windows-hýsli skaltu líka athuga mælikvarða viðmótsins. Leið sem bætt var við meðan host-only millistykkið var óvirkt verður eftir í töflunni en ber aldrei umferð, og annar millistykki með lægri mælikvarða getur unnið uppflettinguna fyrir sama forskeyti.

Prófun 4: DNS fylgir leiðinni, ekki sjálfgefnu stillingu tunnilsins

Leiðir hreyfa pakka; uppflettirinn ákveður hvaða nöfn búa til pakka. Takmarkaðu fyrirtækjauppflettirinn við fyrirtækjasvæðið í stað þess að skipta út uppfletti hýsisins, og beindu honum að DNS-þjóni sem nýja leiðin nær þegar til. Með systemd-resolved á hýsilnum:

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

Á Windows gerir færsla í stefnutöflu nafnupplausnar sama gagn: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. Ef gesturinn keyrir eigin uppfletti á host-only tölunni skaltu nota þá tölu í staðinn, en aðeins eftir að hafa staðfest að hún svari á 192.168.56.2 og ekki á loopback.

Athugaðu síðan MTU áður en þú kennir DNS um hægar síður. Tunnilviðmótið er minna en 1500 bæta viðmót hýsisins, svo hýsill sem sendir fullstærðar hluta með DF-bitanum kveiktum sér þá látna falla einhvers staðar inni í gestinum. Klassiskt einkenni er ping sem virkar og innra vefforrit sem stöðvast eftir TLS-handabandið. Herðu MSS á endursendingarleið gestanna:

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

Prófun 5: staðfestu frá báðum endum

Frá hýsilnum ætti traceroute eða tracert að innri tölu að sýna 192.168.56.2 sem fyrsta hopp, ekki líkamlegu gáttina. Í gestinum skaltu fylgjast með sömu tilraun fara út: tcpdump -ni any host 10.20.30.40 sýnir endursenda beiðnina á host-only hliðinni og þýddu á tunnilnum. Beiðni sem fer út, kemur til baka og lætur hýsilinn samt þegja bendir á bakleiðina.

Tvö mistök útskýra mest af þessu. Annaðhvort ber tunnill gestanna enga bakleið fyrir host-only forskeytið því NAT-reglan vantar, eða leið hýsisins bendir á tölu sem gesturinn hefur ekki lengur eftir endurræsingu. Lestu tölurnar aftur með ip -br addr og ip route get í stað þess að treysta athugasemdum frá síðasta fundi.

Prófun 6: gerðu það að standast endurræsingu og uppfærslu hypervisors

Haltu báðum helmingunum varanlega: netplan- eða NetworkManager-leiðastillingu á hýsilnum, route add ... -p á Windows og net.ipv4.ip_forward=1 í /etc/sysctl.d/ auk reglusetts fyrir eldvegg sem hleðst aftur í gestinum. Taktu snapshot af gestinum um leið og stillingin er staðfest, áður en næsta uppfærsla fyrirtækjaskjáþyrilsins kemur.

Host-only net eru endurnúmeruð þegar hypervisor býr til millistykki sín að nýju, sem gerir hljóðlega ógilt hverja leið og NAT-reglu sem byggð er á 192.168.56.0/24. Eftir uppfærslu skaltu endurtaka fyrstu þrjár prófanirnar í röð; það tekur eina mínútu og grípur tilfellið þar sem hýsillinn hefur enn leiðina sína á meðan gesturinn hefur flutt á nýtt undirnet.

IPv6 þarf eigin umferð. Reglur ip6tables, AAAA-færslur og önnur leiðarfjölskylda hýsisins fylgja ekki IPv4-uppsetningunni, og fyrirtækjaþjónusta sem næst yfir IPv6 mun virðast varanlega biluð á meðan IPv4 virkar.

Staðist eða ekki, í röð: hýsillinn getur pingað host-only tölu gestanna; gesturinn endursendir og gerir MASQUERADE í átt að tunnilnum; ip route get skilar gestinum sem gátt fyrir innra forskeytið; fyrirtækjanöfn leysast með takmarkaða uppflettinum; traceroute sýnir gestinn fyrstan; og sömu sex svörin standast endurræsingu.