VMware-pontigita gasto perdis sian reton post OpenVPN

Gasto, kiu antaŭ unu horo estis pontigita kaj atingebla, nun elĉerpas la tempon pri ĉio, kaj neniu redaktis ĝiajn agordojn. En la gastiganto, la interreto ankoraŭ funkcias tra la tunelo. La du faktoj kune montras for de la VPN kaj al la hipervizoro, ĉar la gastiganto kaj la gasto ne plu uzas la saman vojon. Unu nova virtuala adaptilo sufiĉas por kaŭzi tion.

La gasto ne ŝanĝiĝis, la ponto ŝanĝiĝis

Instalo de la OpenVPN-kliento en Windows aldonas virtualan retan adaptilon, al kiu la servo ligiĝas kiam tunelo leviĝas. Por la operaciumo ĝi aspektas kiel ordinara interfaco kun ligstato kaj ofte propraj adresoj. Tio sufiĉas por ke VMware traktu ĝin kiel pontkandidaton.

VMnet0 estas defaŭlte agordita al Aŭtomata, kio signifas, ke la hipervizoro elektas gastigan adaptilon ĉiufoje kiam ĝi pontas. Ĵus instalita virtuala adaptilo aliĝas al tiu grupo, kaj se ĝi estas elektita, ĉiu kadro, kiun la gasto elsendas, iras al tunela aparato anstataŭ al la fizika komutilpordo.

Fiksu la ponton aŭ enkursigu la gaston

La unua branĉo estas la ĝusta kiam la gasto devas esti samrangula membro de la fizika LAN: ĉesu lasi la ponton elekti, kaj nomu la adaptilon eksplicite. La dua branĉo validas kiam la gasto devas uzi la entreprenan tunnelon, kaj tiuokaze ponto neniam estis la ĝusta dezajno, ĉar pontigita gasto ne heredas la VPN-vojon de la gastiganto.

Decidu tion unue, ĉar la du respondoj kondukas al malsama laboro. Inversigi la ordon produktas ĝuste fiksitan ponton ligitan al gasto, kiu neniam devintus esti pontigita.

Por la unua branĉo, malfermu la Virtual Network Editor en la gastiganto, elektu VMnet0 kaj anstataŭigu Aŭtomata per la fizika adaptilo. Se ekzistas pluraj adaptiloj, uzu la liston de aŭtomataj agordoj kaj forigu la markon ĉe ĉio, kio neniam rajtas porti gastan trafikon: la aparato OpenVPN TAP aŭ Wintun, kune kun la adaptiloj Hyper-V, WSL, Docker kaj loopback. Lasu markitaj kaj la dratan kaj la sendratan fizikan adaptilon en tekkomputilo, alie la gasto perdos sian ponton la venontan fojon kiam la uzanto konektos ĝin al doko.

Tri kondiĉoj, kiuj decidas la elekton

Ĉu ponto entute taŭgas, dependas de tio, por kio la gasto estas. Se la gasto devas aperi kiel propra gastiganto en la LAN, kun propra adreso kaj propra enira atingeblo, la ponto estas la ĝusta modelo kaj la fiksado estas la tuta ripeto. Se la gasto bezonas nur eliran aliron, reto nur por la gastiganto aŭ NAT estas pli simpla kaj imuna al adaptilaj ŝanĝoj.

Se la gasto devas uzi la saman tunnelon kiel la gastiganto, nek ponta reĝimo nek fiksita adaptilo helpas, ĉar la trafiko de la gasto neniam eniras la enkursigan decidon de la gastiganto. Tiu kazo bezonas enkursigitan aŭ tradukitan vojon en la gastiganto, kaj la elekto de adaptilo fariĝas sensignifa.

VMware Player havas neniun retan redaktilon en sia interfaco, do gastiganto, kiu rulas nur Player, bezonas la memstaran redaktilon aŭ Workstation-instalaĵon por atingi ĉi tiujn agordojn. Tiu limigo foje mem decidas la aliron.

Legu la rezulton de interne de la gasto

Restartigu la virtualan retkarton, aŭ restartigu la gaston, por ke ĝi denove petu luon. Poste legu, kion ĝi efektive ricevis, ne kion la gastiganto kredas esti agordinta.

ipconfig /all
ip addr
ip route

Legu du kampojn en tiu eligo kaj ignoru la ceteron por nun. La kluzo devas esti la LAN-enkursigilo, kaj la adaptila priskribo devas nomi la VMware Ethernet-aparaton anstataŭ tunnelon. Mematribuita adreso ene de 169.254.0.0/16 signifas, ke neniu DHCP-servilo respondis, kaj tiel aspektas ponto sur tunela adaptilo de la flanko de la gasto.

Ankoraŭ unu distingo indas antaŭ ol ŝanĝi ion alian. Gasto, kiu atingas la enkursigilon sed ne la interreton, havas funkciantan ponton kaj problemon pli supre. Gasto, kiu ricevas adreson en la tunela gamo, ankoraŭ estas ligita al la malĝusta aparato. Malŝalti la TAP-adaptilon ne estas solvo por neniu el la du kazoj, ĉar la OpenVPN-servo bezonas ĝin.