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 ён патрэбны.