Host VPN-seansi jagamine VMware külalisega

Tunneladapter ei liitu sillaga ja Windows 10 ei marsruudi alamvõrkude vahel. Host-only segment NAT-iga kannab külalist selle asemel.

Teie virtuaalmasin ei jõua sisemise süsteemini, mis töötab hostis laitmatult, ja host on ühendatud kliendi kaudu, mis omab marsruutimistabelit. Virtuaaladapteri sillutamine tunnelisse tundub ilmne ja ebaõnnestub kahel eraldi põhjusel. Töötab tõlkimine segmendil, mida mõlemad masinad omavad. Hind on tegelik: iga külaline kaotab ettevõttevõrgus oma identiteedi.

Kaks põhjust, miks sild ei saa töötada

Kliendi adapter kannab tavaliselt ühte aadressi, sageli /32, ja klient kirjutab hosti marsruudid ümber nii, et tavaline väljuv liiklus eelistab tunnelit. Hostis olevad rakendused kuuletuvad sellele tabelile ja jõuavad privaatsesse süsteemi. Sillatud külaline ei loe tabelit üldse, sest tema kaadrid väljuvad kommutaatori kaudu IP-kihist allpool.

Tunneladapteri sillale panek lahendaks tee teoreetiliselt, kuid draiver ei võta seda vastu. Windows 10 lubab ka ainult ühte silla seadet ja jätab andmata marsruutimisrolli, mis laseks tööjaamal kahe alamvõrgu vahel edasi saata. Alles jääb lähtetõlkimine. Pange külalise liiklus paistma hostist tulevana ja hosti enda otsused kannavad selle tunnelisse, ilma et külaline vajaks marsruuti, mida tal olla ei saa.

Looge segment, mida host omab

Virtuaalvõrgu redaktoris lisage host-only võrk nagu VMnet3 prefiksile, mida te mujal ei marsruudi, näiteks 172.28.90.0/24. Host võtab sellel adapteril 172.28.90.1 ja külaline ühendub sama kommutaatoriga. Lülitage hüperviisori DHCP sellel segmendil välja, et seda omaks üks aadressiteenus.

Kinnitage, et Windows näeb liidest, enne kui selle peale midagi ehitate, sest kogu lahendus sõltub sellest, et see adapter on tavaline:

Get-NetAdapter | Format-Table Name, InterfaceDescription, Status
Get-NetIPAddress -AddressFamily IPv4 | Where-Object PrefixLength -eq 24

host-only adapter ilmub sinna nagu iga füüsiline. Just see on erinevus tunneladapterist, mida ei saa millegi külge kinnitada.

Tõlkige külalise prefiks

Avage kõrgendatud sessioon ja tõlkige prefiks. Kontrollige esmalt, mis juba olemas on, sest konteinerite runtime’id ja hüperviisorid paigaldavad oma tõlked ning vale kustutamine rikub teise toote.

Get-NetNat | Format-Table Name, InternalIPInterfaceAddressPrefix, Active
New-NetNat -Name "LabGuestEgress" -InternalIPInterfaceAddressPrefix 172.28.90.0/24

Seejärel seadistage külaline selle prefiksi staatilise aadressiga, 172.28.90.1 selle lüüsina ja resolveri aadressidega, mille tunnel hostile annab. Tõlkimine edastab pakette ega õpeta külalisele DNS-ist midagi, seega kohalikku ruuterisse jäetud külaline lahendab avalikke nimesid ja ebaõnnestub iga sisemise puhul.

Kontrollige esimest hüpet, siis hinda

Testige lähimat piiri enne rakenduse testimist. Hostis asuvas lüüsis peatuv jälg tähendab, et tõlkimist ei toimu, samas kui hostist kaugemal peatuv tähendab, et tunnel on maas või kaugpool lükkas tõlgitud aadressi tagasi.

tracert -d 172.20.31.10
nslookup intranet.corp.example
Get-NetNatSession -NatName "LabGuestEgress"

Võrrelge hosti enda juurdepääsuga samale sihtkohale, kui tunnel töötab. Kui hostil õnnestub ja külalisel mitte, on viga tõlkimises või külalise lüüsi seadistuses, mitte ühenduses.

Seejärel leppige vahetusega. Ettevõtte süsteemid näevad nüüd igale külalisele ühte aadressi, seega seadme sertifikaadid ja seadmepõhised seisundikontrollid ei suuda neid eristada ning mõned poliitikad keelavad selle täielikult. Otsustage ka väljalangemise käitumine, sest tõlgitud liiklus võib tunneli rikke korral langeda tavalisele internetiteele, kui te seda prefiksit hosti tulemüüris ei blokeeri.

Seotud artiklid