A gazdagép VPN-munkamenetének megosztása VMware-vendéggel

A virtuális gép nem ér el egy belső rendszert, amely a gazdagépen tökéletesen működik, a gazdagép pedig egy olyan kliensen keresztül csatlakozik, amely birtokolja az útválasztási táblát. A virtuális adapter áthidalása az alagútba kézenfekvőnek tűnik, és két külön okból vall kudarcot. Az működik, ha olyan szegmensen fordítunk, amelyet mindkét gép birtokol. Az ár valódi: minden vendég elveszíti saját identitását a vállalati hálózaton.

Két ok, amiért a híd nem működhet

A kliens adaptere általában egy címet hordoz, gyakran egy /32-t, és a kliens átírja a gazdagép útvonalait, hogy a szokásos kimenő forgalom az alagutat részesítse előnyben. A gazdagépen futó alkalmazások engedelmeskednek ennek a táblának, és elérik a magánrendszert. Az áthidalt vendég egyáltalán nem olvassa a táblát, mert a keretei az IP-réteg alatti kapcsolón keresztül lépnek ki.

Az alagút-adapter hídba helyezése elvileg megoldaná az útvonalat, és az illesztőprogram nem fogadja el. A Windows 10 is csak egy híd-eszközt engedélyez, és megtagadja azt az útválasztási szerepet, amely lehetővé tenné egy munkaállomásnak, hogy két alhálózat között továbbítson. Ami marad, az a forrásfordítás. Tegye úgy, hogy a vendég forgalma a gazdagépről érkezőnek tűnjön, és a gazdagép saját döntései viszik be az alagútba, anélkül hogy a vendégnek olyan útvonalra lenne szüksége, amely nem lehet.

Hozzon létre egy szegmenst, amelyet a gazdagép birtokol

A virtuális hálózat szerkesztőjében adjon hozzá egy host-only hálózatot, például a VMnet3-at olyan előtagra, amelyet sehol máshol nem irányít, például 172.28.90.0/24. A gazdagép ezen az adapteren a 172.28.90.1-et veszi fel, a vendég pedig ugyanahhoz a kapcsolóhoz csatlakozik. Tiltsa le a hipervizor DHCP-jét ezen a szegmensen, hogy egyetlen címkezelő szolgáltatás birtokolja.

Erősítse meg, hogy a Windows látja az interfészt, mielőtt bármit ráépítene, mert az egész terv azon múlik, hogy ez az adapter közönséges:

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

Egy host-only adapter úgy jelenik meg ott, mint bármely fizikai. Pontosan ez a különbség az alagút-adapterhez képest, amelyet semmihez nem lehet csatolni.

Fordítsa le a vendég előtagját

Nyisson emelt szintű munkamenetet, és fordítsa le az előtagot. Először vizsgálja meg, mi létezik már, mert a konténer-futtatókörnyezetek és a hipervizorok saját fordításaikat telepítik, és a rossz törlése egy másik terméket tör el.

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

Ezután állítsa be a vendéget statikus címmel ebben az előtagban, a 172.28.90.1-et átjárójaként, és azokkal a feloldócímekkel, amelyeket az alagút a gazdagépnek ad. A fordítás továbbítja a csomagokat, és semmit nem tanít meg a vendégnek a DNS-ről, ezért a helyi routeren hagyott vendég feloldja a nyilvános neveket, és minden belső néven elbukik.

Ellenőrizze az első ugrást, aztán az árat

Tesztelje a legközelebbi határt egy alkalmazás tesztelése előtt. A gazdagép átjárójánál megálló nyom azt jelenti, hogy nem történik fordítás, míg a gazdagépen túl megálló azt, hogy az alagút áll, vagy a túloldal elutasította a lefordított címet.

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

Hasonlítsa össze a gazdagép saját hozzáférésével ugyanahhoz a célhoz, amíg az alagút fennáll. Ha a gazdagép sikerrel jár, a vendég nem, a hiba a fordításban vagy a vendég átjáróbeállításában van, nem a kapcsolatban.

Aztán fogadja el a cserét. A vállalati rendszerek most egy címet látnak minden vendéghez, így az eszköztanúsítványok és az eszközönkénti állapotellenőrzések nem tudják megkülönböztetni őket, és egyes irányelvek ezt egyenesen tiltják. Döntse el a kiesési viselkedést is, mert a lefordított forgalom az alagút meghibásodásakor a szokásos internetes útvonalra eshet, hacsak nem blokkolja ezt az előtagot a gazdagép tűzfalán.