A VMware hídmódú vendég OpenVPN után elvesztette a hálózatát

Egy vendég, amely egy órával ezelőtt még hídmódban volt és elérhető volt, most mindenre időtúllépést ad, és senki nem szerkesztette a beállításait. A gazdagépen az internet továbbra is működik az alagúton keresztül. A két tény együtt a VPN-től elfelé és a hipervizor felé mutat, mert a gazdagép és a vendég már nem ugyanazt az útvonalat használja. Ehhez egyetlen új virtuális adapter is elég.

A vendég nem változott, a híd igen

Az OpenVPN kliens Windowsos telepítése hozzáad egy virtuális hálózati adaptert, amelyhez a szolgáltatás csatlakozik, amikor az alagút felépül. Az operációs rendszer számára úgy néz ki, mint egy közönséges interfész kapcsolatállapottal és gyakran saját címekkel. Ez elég ahhoz, hogy a VMware hídjelöltként kezelje.

A VMnet0 alapértelmezés szerint Automatikus, ami azt jelenti, hogy a hipervizor minden hidazásnál kiválaszt egy gazdagép-adaptert. Egy frissen telepített virtuális adapter bekerül ebbe a halmazba, és ha kiválasztják, a vendég által kibocsátott minden keret egy alagúteszközre megy a fizikai kapcsolóport helyett.

A híd rögzítése vagy a vendég útválasztása

Az első ág akkor a helyes, amikor a vendégnek a fizikai LAN egyenrangú tagjának kell lennie: ne engedje, hogy a híd válasszon, és nevezze meg az adaptert kifejezetten. A második ág akkor érvényes, amikor a vendégnek a vállalati alagutat kell használnia, és ilyenkor a híd soha nem volt helyes tervezés, mert a hídmódú vendég nem örökli a gazdagép VPN-útvonalát.

Ezt először döntse el, mert a két válasz különböző munkához vezet. A sorrend megfordítása helyesen rögzített hidat eredményez, amely olyan vendéghez kapcsolódik, amelyet soha nem kellett volna hidazni.

Az első ághoz nyissa meg a Virtual Network Editort a gazdagépen, válassza a VMnet0-t, és cserélje az Automatikust a fizikai adapterre. Ha több adapter van, használja az automatikus beállítások listáját, és törölje a jelölést mindenről, aminek soha nem szabad vendégforgalmat hordoznia: az OpenVPN TAP vagy Wintun eszköz, valamint a Hyper-V, WSL, Docker és loopback adapterek. Hagyja bejelölve a huzalos és a vezeték nélküli fizikai adaptert is egy laptopon, különben a vendég elveszti a hidat, amikor a felhasználó legközelebb dokkol.

Három feltétel, amely eldönti a választást

Az, hogy egy híd egyáltalán megfelelő-e, attól függ, mire való a vendég. Ha a vendégnek saját gazdagépként kell megjelennie a LAN-on, saját címével és saját bejövő elérhetőségével, a híd a helyes modell, és a rögzítés jelenti a teljes megoldást. Ha a vendégnek csak kimenő hozzáférésre van szüksége, a csak gazdagépes vagy NAT-hálózat egyszerűbb, és immunis az adaptercserékre.

Ha a vendégnek ugyanazt az alagutat kell használnia, mint a gazdagépnek, sem a hídmód, sem a rögzített adapter nem segít, mert a vendég forgalma soha nem kerül be a gazdagép útválasztási döntésébe. Az ilyen eset útvonalon irányított vagy lefordított útvonalat igényel a gazdagépen, és az adapter választása lényegtelenné válik.

A VMware Player felületén nincs hálózatszerkesztő, ezért a csak Playert futtató gazdagépnek a különálló szerkesztőre vagy egy Workstation-telepítésre van szüksége, hogy elérje ezeket a beállításokat. Ez a korlát néha maga dönti el a megközelítést.

Olvassa le az eredményt a vendégen belülről

Indítsa újra a virtuális hálózati kártyát, vagy indítsa újra a vendéget, hogy újra bérletet kérjen. Ezután olvassa le, mit kapott valójában, és ne azt, amit a gazdagép hisz beállítottnak.

ipconfig /all
ip addr
ip route

Ebben a kimenetben olvasson két mezőt, a többit egyelőre hagyja figyelmen kívül. Az átjárónak a LAN-routernek kell lennie, és az adapter leírásának a VMware Ethernet-eszközt kell megneveznie, nem egy alagutat. Az 169.254.0.0/16 tartományban önmagának adott cím azt jelenti, hogy egyetlen DHCP-kiszolgáló sem válaszolt, és pontosan így néz ki egy alagútadapterre épülő híd a vendég oldaláról.

Még egy különbségtétel megéri, mielőtt bármi mást módosítana. Az a vendég, amely eléri a routert, de az internetet nem, működő híddal és felfelé jelentkező problémával rendelkezik. Az a vendég, amely az alagút tartományában kap címet, még mindig a rossz eszközhöz kapcsolódik. A TAP-adapter letiltása egyik esetre sem megoldás, mert az OpenVPN szolgáltatásnak szüksége van rá.