Isäntäkoneen VPN-istunnon jakaminen VMware-vieraalle

Virtuaalikoneesi ei tavoita sisäistä järjestelmää, joka toimii isäntäkoneella moitteettomasti, ja isäntäkone on yhdistetty asiakasohjelman kautta, joka omistaa reititystaulun. Virtuaalisovittimen siltaaminen tunneliin vaikuttaa ilmeiseltä ja epäonnistuu kahdesta erillisestä syystä. Toimiva ratkaisu on käännös segmentillä, jonka molemmat koneet omistavat. Hinta on todellinen: jokainen vieras menettää oman identiteettinsä yritysverkossa.

Kaksi syytä, miksi silta ei voi toimia

Asiakasohjelman sovitin kantaa yleensä yhtä osoitetta, usein /32, ja asiakasohjelma kirjoittaa isännän reitit uudelleen niin, että tavallinen lähtevä liikenne suosii tunnelia. Isännän sovellukset tottelevat taulukkoa ja tavoittavat yksityisen järjestelmän. Siltautettu vieras ei lue taulukkoa lainkaan, koska sen kehykset lähtevät kytkimen kautta IP-kerroksen alapuolella.

Tunnelisovittimen laittaminen siltaan ratkaisisi polun teoriassa, eikä ajuri hyväksy sitä. Windows 10 sallii myös vain yhden siltalaitteen eikä anna reititysroolia, joka antaisi työaseman välittää kahden aliverkon välillä. Jäljelle jää lähdekäännös. Saakaa vieraan liikenne näyttämään isännältä tulevalta, ja isännän omat päätökset kuljettavat sen tunneliin ilman, että vieras tarvitsee reittiä, jota sillä ei voi olla.

Luo segmentti, jonka isäntä omistaa

Lisää virtuaaliverkon editorissa host-only-verkko, kuten VMnet3, etuliitteelle, jota et reititä missään muualla, esimerkiksi 172.28.90.0/24. Isäntä ottaa 172.28.90.1:n tuolle sovittimelle ja vieras liittyy samaan kytkimeen. Poista hypervisorin DHCP käytöstä tuolla segmentillä, jotta yksi osoitepalvelu omistaa sen.

Varmista, että Windows näkee liitännän ennen kuin rakennat mitään sen päälle, sillä koko suunnittelu riippuu siitä, että sovitin on tavallinen:

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

host-only-sovitin näkyy siellä kuin mikä tahansa fyysinen. Juuri siinä on ero tunnelisovittimeen, jota ei voi liittää mihinkään.

Käännä vieraan etuliite

Avaa korotettu istunto ja käännä etuliite. Tarkista ensin, mitä on jo olemassa, sillä konttien ajonaikaiset ympäristöt ja hypervisorit asentavat omat käännöksensä, ja väärän poistaminen rikkoo toisen tuotteen.

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

Määritä sitten vieras staattisella osoitteella tuossa etuliitteessä, 172.28.90.1 sen yhdyskäytävänä ja ne selvityspalvelimen osoitteet, jotka tunneli antaa isännälle. Käännös välittää paketteja eikä opeta vieraalle mitään DNS:stä, joten paikalliselle reitittimelle jätetty vieras selvittää julkiset nimet ja epäonnistuu jokaisessa sisäisessä.

Tarkista ensimmäinen hyppy, sitten hinta

Testaa lähin raja ennen sovelluksen testaamista. Isännän yhdyskäytävään pysähtyvä jälki tarkoittaa, ettei käännöstä tapahdu, kun taas isännän taakse pysähtyvä tarkoittaa, että tunneli on alhaalla tai vastapuoli hylkäsi käännetyn osoitteen.

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

Vertaa isännän omaan pääsyyn samaan kohteeseen, kun tunneli on päällä. Jos isäntä onnistuu ja vieras ei, vika on käännöksessä tai vieraan yhdyskäytäväasetuksessa, ei yhteydessä.

Hyväksy sitten vaihtokauppa. Yritysjärjestelmät näkevät nyt yhden osoitteen jokaiselle vieraalle, joten laitevarmenteet ja laitekohtaiset tilantarkistukset eivät voi erottaa niitä, ja jotkin käytännöt kieltävät tämän kokonaan. Päätä myös pudotuskäyttäytyminen, sillä käännetty liikenne voi pudota tavalliselle internetpolulle, kun tunneli pettää, ellet estä tuota etuliitettä isännän palomuurissa.