VMware tiltā savienotais viesis pēc OpenVPN zaudēja tīklu

Viesis, kas pirms stundas bija tiltā un bija sasniedzams, tagad visam saņem taimautu, un neviens nav rediģējis tā iestatījumus. Resursdatorā internets joprojām darbojas caur tuneli. Abi fakti kopā vērš prom no VPN un uz hipervizoru, jo resursdators un viesis vairs neizmanto vienu un to pašu ceļu. Ar vienu jaunu virtuālo adapteri ir gana, lai to izraisītu.

Viesis nemainījās, mainījās tilts

OpenVPN klienta instalēšana sistēmā Windows pievieno virtuālo tīkla adapteri, kuram pakalpojums pieslēdzas, kad veidojas tunelis. Operētājsistēmai tas izskatās kā parasta saskarne ar saites stāvokli un bieži ar savām adresēm. Ar to pietiek, lai VMware to uzskatītu par tilta kandidātu.

VMnet0 pēc noklusējuma ir iestatīts uz Automātiski, kas nozīmē, ka hipervizors katru reizi veidojot tiltu izvēlas resursdatora adapteri. Tikko instalēts virtuālais adapters iekļūst šajā kopā, un, ja tas tiek izvēlēts, katrs viesa raidītais kadrs dodas uz tuneļa ierīci, nevis uz fizisko komutatora portu.

Piespraudiet tiltu vai maršrutējiet viesi

Pirmā atzars ir pareizais, ja viesim jābūt līdzvērtīgam fiziskā LAN dalībniekam: pārtrauciet ļaut tiltam izvēlēties un skaidri nosauciet adapteri. Otrais atzars attiecas uz gadījumu, kad viesim jāizmanto uzņēmuma tunelis, un tad tilts nekad nav bijis pareizais risinājums, jo tiltā savienots viesis nemanto resursdatora VPN maršrutu.

Izlemiet to vispirms, jo abas atbildes ved uz atšķirīgu darbu. Apgriežot secību, tiek iegūts pareizi piesprausts tilts, kas pievienots viesim, kuru nekad nevajadzēja savienot ar tiltu.

Pirmajam atzaram atveriet Virtual Network Editor resursdatorā, atlasiet VMnet0 un aizstājiet Automātiski ar fizisko adapteri. Ja ir vairāki adapteri, izmantojiet automātisko iestatījumu sarakstu un noņemiet atzīmi no visa, kam nekad nav jāpārvadā viesa trafiks: OpenVPN TAP vai Wintun ierīce, kā arī Hyper-V, WSL, Docker un loopback adapteri. Portatīvajā datorā atstājiet atzīmētus gan vadu, gan bezvadu fizisko adapteri, citādi viesis zaudēs tiltu nākamreiz, kad lietotājs to pievienos dokam.

Trīs nosacījumi, kas izšķir izvēli

Tas, vai tilts vispār ir piemērots, atkarīgs no tā, kam viesis paredzēts. Ja viesim jāparādās kā atsevišķam resursdatoram LAN tīklā ar savu adresi un savu ienākošo sasniedzamību, tilts ir pareizais modelis un piespraušana ir viss labojums. Ja viesim nepieciešama tikai izejošā piekļuve, tīkls tikai resursdatoram vai NAT ir vienkāršāks un noturīgs pret adapteru maiņu.

Ja viesim jāizmanto tas pats tunelis kā resursdatoram, nepalīdz ne tilta režīms, ne piesprausts adapters, jo viesa trafiks nekad neiekļūst resursdatora maršrutēšanas lēmumā. Šim gadījumam resursdatorā vajadzīgs maršrutēts vai tulkots ceļš, un adaptera izvēle kļūst nebūtiska.

VMware Player saskarnē nav tīkla redaktora, tāpēc resursdatoram, kurā darbojas tikai Player, ir vajadzīgs atsevišķs redaktors vai Workstation instalācija, lai piekļūtu šiem iestatījumiem. Šis ierobežojums dažkārt pats nosaka pieeju.

Nolasiet rezultātu viesa iekšienē

Restartējiet virtuālo tīkla karti vai restartējiet viesi, lai tas atkal pieprasītu nomu. Pēc tam nolasiet, ko tas patiešām saņēma, nevis to, ko resursdators domā esam konfigurējis.

ipconfig /all
ip addr
ip route

Šajā izvadē nolasiet divus laukus, bet pārējo pagaidām ignorējiet. Vārtejai jābūt LAN maršrutētājam, un adaptera aprakstā jānorāda VMware Ethernet ierīce, nevis tunelis. Pašpiešķirta adrese 169.254.0.0/16 nozīmē, ka neviens DHCP serveris neatbildēja, un tieši tā tilts uz tuneļa adapteri izskatās no viesa puses.

Pirms kaut ko citu mainīt, ir vērts izdarīt vēl vienu atšķirību. Viesim, kas sasniedz maršrutētāju, bet ne internetu, ir strādājošs tilts un problēma augšpusē. Viesis, kas saņem adresi tuneļa diapazonā, joprojām ir pievienots nepareizajai ierīcei. TAP adaptera atspējošana nav risinājums nevienam no šiem gadījumiem, jo OpenVPN pakalpojumam tas ir vajadzīgs.