VMware гостин во режим на мост ја загуби мрежата по OpenVPN

Гостин кој пред еден час беше во мост и беше достапен сега добива истек на време за сѐ, и никој не ги уредил неговите поставки. На домаќинот, интернетот сѐ уште работи низ тунелот. Двата факти заедно упатуваат далеку од VPN и кон хипервизорот, бидејќи домаќинот и гостинот веќе не користат иста патека. Доволен е еден нов виртуелен адаптер за да го предизвика тоа.

Гостинот не се смени, мостот се смени

Инсталирањето на клиентот OpenVPN во Windows додава виртуелен мрежен адаптер на кој услугата се врзува кога ќе се подигне тунел. За оперативниот систем изгледа како обичен интерфејс со состојба на врската и често со сопствени адреси. Тоа е доволно VMware да го третира како кандидат за мост.

VMnet0 стандардно е поставен на Автоматски, што значи дека хипервизорот избира адаптер на домаќинот секогаш кога прави мост. Новоинсталиран виртуелен адаптер влегува во тој збир и ако биде избран, секоја рамка што гостинот ја испраќа оди на тунелски уред наместо на физичкиот порт на прекинувачот.

Зацврстете го мостот или рутирајте го гостинот

Првата гранка е точна кога гостинот треба да биде рамноправен учесник во физичката LAN: престанете да дозволувате мостот да избира и именувајте го адаптерот експлицитно. Втората гранка важи кога гостинот треба да го користи корпоративниот тунел, а во тој случај мост никогаш не бил точниот дизајн, бидејќи гостин во мост не ја наследува VPN рутата на домаќинот.

Одлучете го тоа прво, бидејќи двата одговора водат кон различна работа. Обратен редослед создава точно зацврстен мост поврзан со гостин кој никогаш не требало да биде во мост.

За првата гранка отворете Virtual Network Editor на домаќинот, изберете VMnet0 и заменете Автоматски со физичкиот адаптер. Ако има повеќе адаптери, користете ја листата со автоматски поставки и отстранете ја ознаката од сѐ што никогаш не смее да носи сообраќај на гостинот: уредот OpenVPN TAP или Wintun, како и адаптерите Hyper-V, WSL, Docker и loopback. Оставете означени и жичениот и безжичниот физички адаптер на преносен сметач, инаку гостинот го губи мостот следниот пат кога корисникот ќе го стави во докот.

Три услови што го решаваат изборот

Дали мост воопшто е соодветен зависи од тоа за што е гостинот. Ако гостинот треба да се појави како сопствен домаќин во LAN, со сопствена адреса и сопствена влезна достапност, мостот е точниот модел и зацврстувањето е целата поправка. Ако на гостинот му треба само излезен пристап, мрежа само за домаќинот или NAT е поедноставна и имуна на промени на адаптерот.

Ако гостинот треба да го користи истиот тунел како домаќинот, ниту режимот на мост ниту зацврстен адаптер не помагаат, бидејќи сообраќајот на гостинот никогаш не влегува во одлуката на домаќинот за рутирање. Тој случај бара рутирана или преведена патека на домаќинот, и изборот на адаптер станува неважен.

VMware Player нема уредувач на мрежа во интерфејсот, па домаќин кој извршува само Player има потреба од самостојниот уредувач или инсталација на Workstation за да ги достигне овие поставки. Тоа ограничување понекогаш само го одредува пристапот.

Прочитајте го резултатот од внатрешноста на гостинот

Рестартирајте ја виртуелната мрежна карта или рестартирајте го гостинот, за да побара нов закуп. Потоа прочитајте што навистина добил, а не што домаќинот мисли дека конфигурирал.

ipconfig /all
ip addr
ip route

Прочитајте две полиња во тој излез и засега игнорирајте го остатокот. Излезот треба да биде рутерот на LAN, а описот на адаптерот треба да го наведе уредот VMware Ethernet, а не тунел. Самоопределена адреса во 169.254.0.0/16 значи дека ниту еден DHCP сервер не одговорил, и токму така изгледа мост кон тунелски адаптер од страната на гостинот.

Вреди да се направи уште една разлика пред да смените нешто друго. Гостин што стигнува до рутерот но не до интернетот има работен мост и проблем погоре. Гостин што прима адреса во опсегот на тунелот сѐ уште е поврзан со погрешниот уред. Исклучувањето на TAP адаптерот не е решение за ниту еден од двата случаи, бидејќи услугата OpenVPN го бара.