Oaspetele în punte VMware și-a pierdut rețeaua după OpenVPN

Un oaspete care acum o oră era în punte și era accesibil acum dă timeout la tot, și nimeni nu i-a editat setările. Pe gazdă, internetul funcționează în continuare prin tunel. Cele două fapte împreună indică departe de VPN și către hipervizor, pentru că gazda și oaspetele nu mai folosesc aceeași cale. Un singur adaptor virtual nou este suficient pentru a provoca asta.

Oaspetele nu s-a schimbat, puntea da

Instalarea clientului OpenVPN pe Windows adaugă un adaptor de rețea virtual la care serviciul se leagă atunci când se ridică un tunel. Pentru sistemul de operare arată ca o interfață obișnuită, cu o stare a legăturii și adesea cu adrese proprii. Asta este suficient pentru ca VMware să îl trateze ca pe un candidat la punte.

VMnet0 este setat implicit pe Automat, ceea ce înseamnă că hipervizorul alege un adaptor al gazdei de fiecare dată când face punte. Un adaptor virtual proaspăt instalat intră în acea grupă, iar dacă este ales, fiecare cadru emis de oaspete merge către un dispozitiv de tunel în loc de portul fizic al comutatorului.

Fixați puntea sau rutați oaspetele

Prima ramură este cea corectă atunci când oaspetele trebuie să fie un partener egal în LAN-ul fizic: opriți lăsarea punții să aleagă și numiți adaptorul în mod explicit. A doua ramură se aplică atunci când oaspetele trebuie să folosească tunelul corporativ, iar în acel caz o punte nu a fost niciodată proiectul corect, pentru că un oaspete în punte nu moștenește ruta VPN a gazdei.

Decideți asta mai întâi, pentru că cele două răspunsuri duc la muncă diferită. Inversarea ordinii produce o punte fixată corect, atașată unui oaspete care nu ar fi trebuit niciodată pus în punte.

Pentru prima ramură, deschideți Virtual Network Editor pe gazdă, selectați VMnet0 și înlocuiți Automat cu adaptorul fizic. Dacă există mai multe adaptoare, folosiți lista de setări automate și debifați tot ce nu trebuie să transporte niciodată traficul oaspetelui: dispozitivul OpenVPN TAP sau Wintun, plus adaptoarele Hyper-V, WSL, Docker și loopback. Lăsați bifate atât adaptorul fizic cu cablu, cât și cel wireless pe un laptop, altfel oaspetele își pierde puntea data viitoare când utilizatorul îl conectează la dock.

Trei condiții care decid alegerea

Dacă o punte este chiar potrivită depinde de scopul oaspetelui. Dacă oaspetele trebuie să apară ca gazdă proprie în LAN, cu adresă proprie și accesibilitate de intrare proprie, puntea este modelul corect și fixarea este întreaga remediere. Dacă oaspetele are nevoie doar de acces de ieșire, o rețea numai pentru gazdă sau NAT este mai simplă și imună la schimbările de adaptor.

Dacă oaspetele trebuie să folosească același tunel ca gazda, nu ajută nici modul punte, nici un adaptor fixat, pentru că traficul oaspetelui nu intră niciodată în decizia de rutare a gazdei. Acel caz are nevoie de o cale rutată sau tradusă pe gazdă, iar alegerea adaptorului devine irelevantă.

VMware Player nu are editor de rețea în interfața sa, așa că o gazdă care rulează doar Player are nevoie de editorul autonom sau de o instalare Workstation pentru a ajunge la aceste setări. Această constrângere decide uneori abordarea de una singură.

Citiți rezultatul din interiorul oaspetelui

Reporniți placa de rețea virtuală, sau reporniți oaspetele, ca să ceară din nou un lease. Apoi citiți ce a primit de fapt, nu ce crede gazda că a configurat.

ipconfig /all
ip addr
ip route

Citiți două câmpuri din acea ieșire și ignorați restul deocamdată. Gateway-ul ar trebui să fie routerul LAN-ului, iar descrierea adaptorului ar trebui să numească dispozitivul Ethernet VMware, nu un tunel. O adresă auto-atribuită în 169.254.0.0/16 înseamnă că niciun server DHCP nu a răspuns, și exact așa arată o punte pe un adaptor de tunel din partea oaspetelui.

Mai merită făcută o distincție înainte de a schimba orice altceva. Un oaspete care ajunge la router dar nu la internet are o punte funcțională și o problemă în amonte. Un oaspete care primește o adresă în intervalul tunelului este încă atașat de dispozitivul greșit. Dezactivarea adaptorului TAP nu este o soluție pentru niciunul dintre cele două cazuri, pentru că serviciul OpenVPN are nevoie de el.