Gost v načinu mostu VMware je po OpenVPN izgubil omrežje

Gost, ki je bil pred uro v mostu in dosegljiv, zdaj pri vsem čaka na časovno omejitev, in nihče ni urejal njegovih nastavitev. Na gostitelju internet še vedno deluje skozi tunel. Obe dejstvi skupaj kažeta stran od VPN in proti hipervizorju, ker gostitelj in gost ne uporabljata več iste poti. Za to zadostuje en sam nov navidezni vmesnik.

Gost se ni spremenil, most se je

Namestitev odjemalca OpenVPN v sistemu Windows doda navidezni omrežni vmesnik, na katerega se storitev veže, ko se tunel dvigne. Za operacijski sistem je videti kot običajen vmesnik s stanjem povezave in pogosto z lastnimi naslovi. To zadostuje, da ga VMware obravnava kot kandidata za most.

VMnet0 je privzeto nastavljen na Samodejno, kar pomeni, da hipervizor vsakič ob mostenju izbere vmesnik gostitelja. Na novo nameščen navidezni vmesnik se pridruži tej skupini, in če je izbran, gre vsak okvir, ki ga gost pošlje, v tunelsko napravo namesto v fizična vrata stikala.

Pripnite most ali usmerite gosta

Prva veja je prava, ko naj bi bil gost enakovreden član fizičnega LAN: prenehajte pustiti mostu, da izbira, in vmesnik izrecno poimenujte. Druga veja velja, ko naj bi gost uporabljal korporativni tunel, in v tem primeru most nikoli ni bil pravilna zasnova, ker mosteni gost ne podeduje VPN poti gostitelja.

Odločite se o tem najprej, ker oba odgovora vodita v različno delo. Če vrstni red obrnete, dobite pravilno pripet most, pritrjen na gosta, ki ne bi smel biti nikoli mosten.

Za prvo vejo odprite Virtual Network Editor na gostitelju, izberite VMnet0 in zamenjajte Samodejno s fizičnim vmesnikom. Če je vmesnikov več, uporabite seznam samodejnih nastavitev in odstranite kljukico pri vsem, kar ne sme nikoli prenašati prometa gosta: naprava OpenVPN TAP ali Wintun ter vmesniki Hyper-V, WSL, Docker in loopback. Na prenosniku pustite označena tako žični kot brezžični fizični vmesnik, sicer gost izgubi most ob naslednjem priklopu v postajo.

Trije pogoji, ki odločijo izbiro

Ali je most sploh primeren, je odvisno od tega, čemu je gost namenjen. Če se mora gost v LAN pojaviti kot samostojen gostitelj z lastnim naslovom in lastno vhodno dosegljivostjo, je most pravilen model in pripenjanje je celotna rešitev. Če gost potrebuje le odhodni dostop, je omrežje samo za gostitelja ali NAT preprostejše in odporno na menjave vmesnikov.

Če mora gost uporabljati isti tunel kot gostitelj, ne pomaga ne mostni način ne pripet vmesnik, ker promet gosta nikoli ne vstopi v odločitev gostitelja o usmerjanju. Tak primer potrebuje na gostitelju usmerjeno ali prevedeno pot, izbira vmesnika pa postane nepomembna.

VMware Player nima v vmesniku urejevalnika omrežja, zato gostitelj, ki ima samo Player, potrebuje samostojni urejevalnik ali namestitev Workstation, da doseže te nastavitve. Ta omejitev včasih sama odloči o pristopu.

Preberite rezultat znotraj gosta

Znova zaženite navidezno omrežno kartico ali gosta, da znova zaprosi za zakup. Nato preberite, kaj je dejansko prejel, in ne, kaj gostitelj misli, da je nastavil.

ipconfig /all
ip addr
ip route

V tem izpisu preberite dve polji, ostalo pa za zdaj prezrite. Prehod bi moral biti usmerjevalnik LAN, opis vmesnika pa bi moral navesti napravo VMware Ethernet in ne tunela. Samodejno dodeljen naslov v 169.254.0.0/16 pomeni, da se ni odzval noben strežnik DHCP, in prav tako je videti most na tunelski vmesnik z gostove strani.

Preden spremenite kar koli drugega, je vredno narediti še eno razlikovanje. Gost, ki doseže usmerjevalnik, ne pa interneta, ima delujoč most in težavo višje po toku. Gost, ki prejme naslov v obsegu tunela, je še vedno priključen na napačno napravo. Onemogočanje vmesnika TAP ni rešitev za nobenega od obeh primerov, ker storitev OpenVPN potrebuje vmesnik.