Partajarea sesiunii VPN a gazdei cu un oaspete VMware

Mașina dumneavoastră virtuală nu ajunge la un sistem intern care funcționează perfect pe gazdă, iar gazda este conectată printr-un client care deține tabela de rutare. Puntea adaptorul virtual către tunel pare evident și eșuează din două motive separate. Ce funcționează este traducerea pe un segment pe care ambele mașini îl dețin. Costul este real: fiecare oaspete își pierde identitatea proprie în rețeaua corporativă.

Două motive pentru care podul nu poate funcționa

Adaptorul clientului poartă de obicei o singură adresă, adesea un /32, iar clientul rescrie rutele gazdei astfel încât traficul obișnuit de ieșire să prefere tunelul. Aplicațiile de pe gazdă ascultă de acea tabelă și ajung la sistemul privat. Un oaspete pus în pod nu citește deloc tabela, pentru că cadrele sale ies printr-un comutator sub stratul IP.

Punerea adaptorului de tunel într-un pod ar rezolva calea teoretic, iar driverul nu va accepta asta. Windows 10 permite și un singur dispozitiv de pod și refuză rolul de rutare care ar lăsa o stație de lucru să transmită între două subrețele. Ce rămâne este traducerea sursei. Faceți traficul oaspetelui să pară că vine de la gazdă, iar deciziile gazdei însăși îl duc în tunel fără ca oaspetele să aibă nevoie de o rută pe care nu o poate avea.

Creați un segment pe care îl deține gazda

În editorul de rețea virtuală, adăugați o rețea doar-gazdă precum VMnet3 pe un prefix pe care nu îl rutați nicăieri altundeva, de exemplu 172.28.90.0/24. Gazda ia 172.28.90.1 pe acel adaptor, iar oaspetele se conectează la același comutator. Dezactivați DHCP-ul hipervizorului pe acel segment, ca un singur serviciu de adrese să îl dețină.

Confirmați că Windows vede interfața înainte de a construi ceva deasupra, pentru că întregul proiect depinde de faptul că acel adaptor este obișnuit:

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

Un adaptor doar-gazdă apare acolo ca orice adaptor fizic. Exact aceasta este diferența față de adaptorul de tunel, care nu poate fi atașat la nimic.

Traduceți prefixul oaspetelui

Deschideți o sesiune cu privilegii ridicate și traduceți prefixul. Verificați mai întâi ce există deja, pentru că mediile de rulare ale containerelor și hipervizorii instalează propriile traduceri, iar ștergerea celei greșite strică alt produs.

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

Apoi configurați oaspetele cu o adresă statică în acel prefix, 172.28.90.1 ca poartă de ieșire și adresele de rezolvare pe care tunelul le dă gazdei. Traducerea transmite pachete și nu învață oaspetele nimic despre DNS, așa că un oaspete lăsat pe routerul local rezolvă nume publice și eșuează pe fiecare nume intern.

Verificați primul salt, apoi costul

Testați cea mai apropiată frontieră înainte de a testa o aplicație. O urmă care se oprește la poarta de ieșire a gazdei înseamnă că traducerea nu are loc, iar una care se oprește dincolo de gazdă înseamnă că tunelul este căzut sau că partea îndepărtată a refuzat adresa tradusă.

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

Comparați cu accesul propriu al gazdei la aceeași destinație cât timp tunelul este activ. Dacă gazda reușește și oaspetele nu, defectul este în traducere sau în setarea porții de ieșire a oaspetelui, nu în conexiune.

Apoi acceptați schimbul. Sistemele corporative văd acum o singură adresă pentru fiecare oaspete, așa că certificatele de dispozitiv și verificările de postură per dispozitiv nu le pot distinge, iar unele politici interzic asta cu desăvârșire. Decideți și comportamentul la cădere, deoarece traficul tradus poate cădea pe calea obișnuită de internet când tunelul eșuează, dacă nu blocați acel prefix în firewall-ul gazdei.