Jo firtuele masine berikt gjin yntern systeem dat perfekt op de host wurket, en de host is ferbûn fia in klant dy’t de rûtelearringstabel besit. De firtuele adapter nei de tunnel oerbrêgje liket foar de hân lizzend en mislearret om twa aparte redenen. Wat wurket is oersetting op in segmint dat beide masinen besitte. De priis is echt: elke gast ferliest syn eigen identiteit op it bedriuwsnetwurk.

Twa redenen wêrom’t de brêge net wurkje kin

De adapter fan de klant draacht meastentiids ien adres, faak in /32, en de klant skriuwt de rûtes fan de host oer sadat gewoan útgeand ferkear de tunnel foarkar jout. Tapassings op de host hearrichje dy tabel en berikke it partikuliere systeem. In oerbrêge gast lêst de tabel hielendal net, om’t syn frames fia in skeakel ûnder de IP-laach fuortgeane.

De tunneladapter yn in brêge pleatse soe it paad teoretysk oplosse, en de stjoerder sil it net akseptearje. Windows 10 tastiet ek mar ien brêge-apparaat en ûnthâldt de rûtelearringrol dy’t in wurkstasjon tusken twa subnetten trochjaan litte soe. Wat oerbliuwt is boarnoersetting. Lit it ferkear fan de gast lykje as komt it fan de host, en de eigen besluten fan de host drage it de tunnel yn sûnder dat de gast in rûte nedich hat dy’t er net hawwe kin.

Meitsje in segmint dat de host besit

Yn de bewurker foar firtuele netwurk, foegje in host-only netwurk ta lykas VMnet3 op in foarheaksel dêr’t jo nearne oars rûtelet, bygelyks 172.28.90.0/24. De host nimt 172.28.90.1 op dy adapter en de gast ferbynt mei deselde skeakel. Skeakelje de DHCP fan de hypervisor op dat segmint út, sadat ien adrestsjinst it besit.

Befêstigje dat Windows de ynterface sjocht foar’t jo dêr eat op bouwe, want it hiele ûntwerp hinget derfan ôf dat dy adapter gewoan is:

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

In host-only adapter ferskynt dêr as elk fysyk eksimplaar. Krekt dat is it ferskil mei de tunneladapter, dy’t nearne oan fêst makke wurde kin.

Set it foarheaksel fan de gast oer

Iepenje in sessy mei ferhege rjochten en set it foarheaksel oer. Kontrolearje earst wat al bestiet, want container-runtimes en hypervisors ynstallearje har eigen oersettings en it ferkearde wiskje brekt in oar produkt.

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

Konfigurearje de gast dan mei in statysk adres yn dat foarheaksel, 172.28.90.1 as syn gateway en de resolveradressen dy’t de tunnel de host jout. Oersetting stjoert pakketten troch en leart de gast neat oer DNS, dus in gast dy’t op de lokale router efterbleaun is, lost publike nammen op en mislearret op elk yntern.

Kontrolearje de earste hop, dan de priis

Test de tichtstbye grins foar’t jo in tapassing testen. In spoar dat by de gateway fan de host stopt, betsjut dat oersetting net bart, wylst ien dat foarby de host stopt betsjut dat de tunnel del is of dat de fiere kant it oersetten adres wegere.

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

Fergelykje mei de eigen tagong fan de host ta deselde bestimming wylst de tunnel oan is. As de host slagget en de gast net, leit de flater yn de oersetting of yn de gateway-ynstelling fan de gast, net yn de ferbining.

Akseptearje dan de ruil. Bedriuwssystemen sjogge no ien adres foar elke gast, dus apparaatsertifikaten en posture-kontrôles per apparaat kinne se net ûnderskiede, en guon beliedsregels ferbiede dit folslein. Beslis ek it dropgedrach, want oersetten ferkear kin by it mislearjen fan de tunnel trochfalle nei it gewoane ynternetpaad, útsein as jo dat foarheaksel by de firewall fan de host blokkearje.

Relatearre artikelen