VMware'i sillatud külalisel kadus pärast OpenVPN-i võrk

Külaline, mis tund aega tagasi oli sillatud ja kättesaadav, saab nüüd kõigel ajapiirangu, ja keegi ei muutnud selle seadeid. Hostis töötab internet tunnelis endiselt. Need kaks fakti koos osutavad VPN-ist eemale ja hüperviisori poole, sest host ja külaline ei kasuta enam sama teed. Ühest uuest virtuaalsest adapterist piisab selle esilekutsumiseks.

Külaline ei muutunud, sild muutus

OpenVPN-i kliendi paigaldamine Windowsi lisab virtuaalse võrguaadapteri, millega teenus tunnelit avades liitub. Operatsioonisüsteemi jaoks näeb see välja nagu tavaline liides, millel on lingi olek ja sageli ka oma aadressid. Sellest piisab, et VMware käsitleks seda silla kandidaadina.

VMnet0 on vaikimisi seatud valikule Automaatne, mis tähendab, et hüperviisor valib silla loomisel hosti adapteri. Värskelt paigaldatud virtuaalne adapter liitub selle hulka, ja kui see valitakse, läheb iga külalise saadetud kaader tunneliseadmele, mitte füüsilise kommutaatori pordile.

Kinnitage sild või marsruutige külaline

Esimene haru on õige siis, kui külaline peab olema füüsilise LAN-i võrdne liige: lõpetage silla valiku tegemine ja nimetage adapter selgesõnaliselt. Teine haru kehtib siis, kui külaline peab kasutama ettevõtte tunnelit, ja sel juhul ei olnud sild kunagi õige lahendus, sest sillatud külaline ei päri hosti VPN-i marsruuti.

Otsustage see kõigepealt, sest kaks vastust viivad erineva tööni. Järjekorra ümberpööramine annab korrektselt kinnitatud silla, mis on kinnitatud külalisele, mida ei oleks tohtinud kunagi sillata.

Esimese haru jaoks avage hostis virtuaalse võrgu redaktor, valige VMnet0 ja asendage Automaatne füüsilise adapteriga. Kui adaptereid on mitu, kasutage automaatsete seadete loendit ja eemaldage linnuke kõigelt, mis ei tohi kunagi külalise liiklust kanda: OpenVPN-i TAP- või Wintun-seade ning Hyper-V, WSL, Dockeri ja loopback-adapterid. Jätke sülearvutis märgituks nii juhtmega kui ka juhtmevaba füüsiline adapter, muidu kaotab külaline silla järgmisel korral, kui kasutaja selle dokki paneb.

Kolm tingimust, mis valiku otsustavad

Kas sild üldse sobib, sõltub sellest, milleks külaline mõeldud on. Kui külaline peab LAN-is paistma omaette hostina, oma aadressi ja oma sissetuleva kättesaadavusega, on sild õige mudel ja kinnitamine on kogu lahendus. Kui külaline vajab ainult väljuvat juurdepääsu, on ainult hosti võrk või NAT lihtsam ja adapterivahetuse suhtes immuunne.

Kui külaline peab kasutama sama tunnelit kui host, ei aita ei sillatud režiim ega kinnitatud adapter, sest külalise liiklus ei jõua kunagi hosti marsruutimisotsusesse. See juhtum vajab hostis marsruuditud või tõlgitud teed ja adapteri valik muutub tähtsusetuks.

VMware Playeril ei ole liideses võrguredaktorit, seega vajab host, kus töötab ainult Player, nende seadeteni jõudmiseks eraldiseisvat redaktorit või Workstationi paigaldust. See piirang otsustab mõnikord lähenemisviisi ise.

Lugege tulemust külalise seest

Taaskäivitage virtuaalne võrgukaart või taaskäivitage külaline, et see taotleks uuesti rendilepingut. Seejärel lugege, mille see tegelikult sai, mitte seda, mida host arvab end seadistanud olevat.

ipconfig /all
ip addr
ip route

Lugege sellest väljundist kahte välja ja ignoreerige ülejäänut esialgu. Lüüs peaks olema LAN-i ruuter ja adapteri kirjeldus peaks nimetama VMware Etherneti seadet, mitte tunnelit. Isemääratud aadress vahemikus 169.254.0.0/16 tähendab, et ükski DHCP-server ei vastanud, ja just nii näeb tunneliseadmele ehitatud sild külalise poolelt välja.

Enne kui midagi muud muudate, tasub teha veel üks vahe. Külaline, mis jõuab ruuterini, kuid mitte internetti, omab töötavat silda ja probleemi ülesvoolu. Külaline, mis saab aadressi tunnivahemikus, on endiselt vale seadme küljes. TAP-adapteri keelamine ei ole kummagi juhtumi lahendus, sest OpenVPN-i teenus vajab seda.