Host VPN sesijos bendrinimas su VMware svečiu

Tunelio adapteris neprisijungia prie tilto, o Windows 10 nemaršrutizuoja tarp potinkių. Host-only segmentas su NAT neša svečią.

Jūsų virtualioji mašina nepasiekia vidinės sistemos, kuri hoste veikia nepriekaištingai, o hostas prijungtas per klientą, kuris valdo maršrutizavimo lentelę. Virtualiojo adapterio sujungimas su tuneliu tiltu atrodo akivaizdu ir žlunga dėl dviejų atskirų priežasčių. Veikia vertimas segmente, kurį valdo abi mašinos. Kaina reali: kiekvienas svečias praranda savo tapatybę įmonės tinkle.

Dvi priežastys, kodėl tiltas negali veikti

Kliento adapteris paprastai turi vieną adresą, dažnai /32, o klientas perrašo hosto maršrutus taip, kad įprastas išeinantis srautas teiktų pirmenybę tuneliui. Hoste esančios programos paklūsta tai lentelei ir pasiekia privačią sistemą. Tiltu sujungtas svečias lentelės visai neskaito, nes jo kadrai išeina per komutatorių žemiau IP sluoksnio.

Tunelio adapterio įdėjimas į tiltą teoriškai išspręstų kelią, bet tvarkyklė to nepriims. Windows 10 taip pat leidžia tik vieną tilto įrenginį ir nesuteikia maršrutizavimo vaidmens, kuris leistų darbo stočiai persiųsti tarp dviejų potinkių. Lieka šaltinio vertimas. Padarykite, kad svečio srautas atrodytų ateinantis iš hosto, ir paties hosto sprendimai nuneša jį į tunelį, svečiui nereikia maršruto, kurio jis negali turėti.

Sukurkite segmentą, kurį valdo hostas

Virtualiojo tinklo redaktoriuje pridėkite host-only tinklą, pavyzdžiui VMnet3, prie prefikso, kurio niekur kitur nemaršrutizuojate, pavyzdžiui 172.28.90.0/24. Hostas tame adapteryje paima 172.28.90.1, o svečias jungiasi prie to paties komutatoriaus. Išjunkite hipervizoriaus DHCP tame segmente, kad jį valdytų viena adresų tarnyba.

Prieš ką nors ant jo statydami įsitikinkite, kad Windows mato sąsają, nes visas sprendimas priklauso nuo to, kad tas adapteris būtų įprastas:

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

host-only adapteris ten rodomas kaip bet kuris fizinis. Būtent tuo jis skiriasi nuo tunelio adapterio, kurio nieko negalima prijungti.

Išverskite svečio prefiksą

Atidarykite sesiją su padidintomis teisėmis ir išverskite prefiksą. Pirmiausia patikrinkite, kas jau yra, nes konteinerių vykdymo aplinkos ir hipervizoriai įdiegia savo vertimus, o netinkamo ištrynimas sugadina kitą produktą.

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

Tada sukonfigūruokite svečią su statiniu adresu tame prefikse, 172.28.90.1 kaip jo tinklų sietuvu ir resolverio adresais, kuriuos tunelis duoda hostui. Vertimas persiunčia paketus ir nieko neišmoko svečio apie DNS, todėl vietiniame maršrutizatoriuje paliktas svečias išsprendžia viešus vardus ir nepavyksta kiekviename vidiniame.

Patikrinkite pirmąjį šuolį, tada kainą

Išbandykite artimiausią ribą prieš bandydami programą. Pėdsakas, kuris sustoja ties hosto tinklų sietuvu, reiškia, kad vertimas nevyksta, o tas, kuris sustoja už hosto, reiškia, kad tunelis neveikia arba kita pusė atmetė išverstą adresą.

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

Palyginkite su paties hosto prieiga prie to paties tikslo, kol tunelis veikia. Jei hostui pavyksta, o svečiui ne, gedimas yra vertime arba svečio tinklų sietuvo nustatyme, o ne ryšyje.

Tada priimkite šiuos mainus. Įmonės sistemos dabar mato vieną adresą kiekvienam svečiui, todėl įrenginių sertifikatai ir kiekvieno įrenginio būsenos patikros negali jų atskirti, o kai kurios politikos tai tiesiog draudžia. Nuspręskite ir išmetimo elgseną, nes išverstas srautas gali nukristi į įprastą interneto kelią, kai tunelis sugenda, jei neužblokuosite to prefikso hosto užkardoje.

Susiję straipsniai