Ndarja e sesionit VPN të hostit me një mysafir VMware

Makina juaj virtuale nuk arrin një sistem të brendshëm që punon përsosur në host, dhe hosti është i lidhur përmes një klienti që zotëron tabelën e rrugëzimit. Ura e përshtatësit virtual drejt tunelit duket e qartë dhe dështon për dy arsye të ndara. Ajo që funksionon është përkthimi në një segment që të dyja makinat e zotërojnë. Kostoja është reale: çdo mysafir humbet identitetin e vet në rrjetin e korporatës.

Dy arsye pse ura nuk mund të funksionojë

Përshtatësi i klientit zakonisht mban një adresë të vetme, shpesh një /32, dhe klienti i rishkruan rrugët e hostit, kështu që trafiku i zakonshëm në dalje preferon tunelin. Aplikacionet në host i binden asaj tablele dhe arrijnë sistemin privat. Një mysafir i urëzuar nuk e lexon tabelën fare, sepse kornizat e tij dalin përmes një komutatori nën shtresën IP.

Vendosja e përshtatësit të tunelit në një urë do ta zgjidhte rrugën në teori, dhe drejtuesi nuk do ta pranojë. Windows 10 gjithashtu lejon vetëm një pajisje ure dhe nuk e jep rolin e rrugëzimit që do të lejonte një stacion pune të përçojë mes dy nënrrjetave. Ajo që mbetet është përkthimi i burimit. Bëj që trafiku i mysafirit të duket se vjen nga hosti, dhe vendimet e vetë hostit e çojnë atë në tunel pa pasur mysafiri nevojë për një rrugë që nuk mund ta ketë.

Krijoni një segment që e zotëron hosti

Në redaktuesin e rrjetit virtual, shtoni një rrjet vetëm-host si VMnet3 mbi një prefiks që nuk e bëni rrugëzim askund tjetër, për shembull 172.28.90.0/24. Hosti merr 172.28.90.1 në atë përshtatës dhe mysafiri lidhet me të njëjtin komutator. Çaktivizoni DHCP-në e hipervizorit në atë segment, që ta zotërojë një shërbim i vetëm adresash.

Konfirmoni se Windows e sheh ndërfaqen përpara se të ndërtoni diçka mbi të, sepse i gjithë projekti varet nga fakti që ai përshtatës të jetë i zakonshëm:

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

Një përshtatës vetëm-host shfaqet atje si çdo përshtatës fizik. Pikërisht ky është dallimi nga përshtatësi i tunelit, i cili nuk mund të lidhet me asgjë.

Përktheni prefiksin e mysafirit

Hapni një sesion të ngritur dhe përktheni prefiksin. Kontrolloni së pari çfarë ekziston tashmë, sepse mjediset e ekzekutimit të kontejnerëve dhe hipervizorët instalojnë përkthimet e tyre dhe fshirja e gabuar prish një produkt tjetër.

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

Më pas konfiguroni mysafirin me një adresë statike në atë prefiks, 172.28.90.1 si portën e tij dhe adresat e zgjidhësit që tuneli i jep hostit. Përkthimi përcjell paketa dhe nuk i mëson asgjë mysafirit për DNS, prandaj një mysafir i lënë në ruterin lokal zgjidh emrat publikë dhe dështon në çdo emër të brendshëm.

Kontrolloni kërcimin e parë, pastaj koston

Provoni kufirin më të afërt përpara se të provoni një aplikacion. Një gjurmë që ndalon te porta e hostit do të thotë se përkthimi nuk po ndodh, ndërsa një që ndalon përtej hostit do të thotë se tuneli ka rënë ose ana e largët refuzoi adresën e përkthyer.

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

Krahasojeni me aksesin e vetë hostit në të njëjtin destinacion, ndërsa tuneli është lart. Nëse hosti ia del dhe mysafiri jo, defekti është në përkthim ose në cilësimin e portës së mysafirit, jo në lidhje.

Më pas pranoni shkëmbimin. Sistemet e korporatës tani shohin një adresë të vetme për çdo mysafir, kështu që certifikatat e pajisjeve dhe kontrollet e gjendjes për pajisje nuk mund t’i dallojnë, dhe disa politika e ndalojnë këtë plotësisht. Vendosni edhe sjelljen e rënies, sepse trafiku i përkthyer mund të bjerë në rrugën e zakonshme të internetit kur tuneli dështon, nëse nuk e bllokoni atë prefiks në firewall-in e hostit.