Host datora VPN sesijas koplietošana ar VMware viesi

Tuneļa adapteris nepievienojas tiltam, un Windows 10 nemaršrutē starp apakštīkliem. Host-only segments ar NAT pārvadā viesi.

Jūsu virtuālā mašīna nevar sasniegt iekšēju sistēmu, kas host datorā darbojas nevainojami, un host dators ir pievienots caur klientu, kuram pieder maršrutēšanas tabula. Virtuālā adaptera savienošana ar tuneli tiltā šķiet acīmredzami un neizdodas divu atsevišķu iemeslu dēļ. Strādā tulkošana segmentā, kas pieder abām mašīnām. Cena ir reāla: katrs viesis zaudē savu identitāti uzņēmuma tīklā.

Divi iemesli, kāpēc tilts nevar darboties

Klienta adapteris parasti nes vienu adresi, bieži /32, un klients pārraksta host datora maršrutus tā, lai parastā izejošā plūsma dotu priekšroku tunelim. Programmas host datorā paklausa šai tabulai un sasniedz privāto sistēmu. Tiltā savienots viesis tabulu vispār nelasa, jo tā kadri iziet caur komutatoru zem IP slāņa.

Tuneļa adaptera ievietošana tiltā teorētiski atrisinātu ceļu, un draiveris to nepieņems. Windows 10 arī pieļauj tikai vienu tilta ierīci un nedod maršrutēšanas lomu, kas ļautu darbstacijai pārsūtīt starp diviem apakštīkliem. Paliek avota tulkošana. Panāciet, ka viesa plūsma izskatās nākam no host datora, un paša host datora lēmumi aizved to tunelī, viesim nevajadzot maršrutu, kura tam nevar būt.

Izveidojiet segmentu, kas pieder host datoram

Virtuālā tīkla redaktorā pievienojiet host-only tīklu, piemēram, VMnet3, prefiksam, kuru nekur citur nemaršrutējat, piemēram, 172.28.90.0/24. Host dators šajā adapterī paņem 172.28.90.1, un viesis pievienojas tam pašam komutatoram. Šajā segmentā izslēdziet hipervizora DHCP, lai to pārvaldītu viens adrešu serviss.

Pirms kaut ko uz tā veidot, pārliecinieties, ka Windows redz saskarni, jo viss risinājums ir atkarīgs no tā, ka šis adapteris ir parasts:

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

host-only adapteris tur parādās kā jebkurš fizisks. Tieši ar to tas atšķiras no tuneļa adaptera, kuram neko nevar pievienot.

Tulkojiet viesa prefiksu

Atveriet paaugstinātu sesiju un tulkojiet prefiksu. Vispirms pārbaudiet, kas jau pastāv, jo konteineru izpildlaiki un hiperviori instalē savus tulkojumus, un nepareizā dzēšana salauž citu produktu.

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

Pēc tam konfigurējiet viesi ar statisku adresi šajā prefiksā, 172.28.90.1 kā tā vārteju un resolvera adresēm, ko tunelis dod host datoram. Tulkošana pārsūta paketes un neiemāca viesim neko par DNS, tāpēc vietējā maršrutētājā atstāts viesis atrisina publiskos vārdus un neizdodas katrā iekšējā.

Pārbaudiet pirmo lēcienu, tad cenu

Pārbaudiet tuvāko robežu pirms programmas pārbaudes. Pēda, kas apstājas pie host datora vārtejas, nozīmē, ka tulkošana nenotiek, bet tā, kas apstājas aiz host datora, nozīmē, ka tunelis ir izslēgts vai pretējā puse atteica tulkoto adresi.

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

Salīdziniet ar paša host datora piekļuvi tam pašam galamērķim, kamēr tunelis ir ieslēgts. Ja host datoram izdodas, bet viesim ne, defekts ir tulkošanā vai viesa vārtejas iestatījumā, nevis savienojumā.

Pēc tam pieņemiet šo maiņu. Uzņēmuma sistēmas tagad redz vienu adresi katram viesim, tāpēc ierīču sertifikāti un katras ierīces stāvokļa pārbaudes nevar tās atšķirt, un dažas politikas to pilnībā aizliedz. Izlemiet arī nomešanas uzvedību, jo tulkotā plūsma tuneļa kļūmes gadījumā var nokrist uz parasto interneta ceļu, ja vien nebloķējat šo prefiksu host datora ugunsmūrī.

Saistītie raksti