Гість VMware у режимі мосту втратив мережу після OpenVPN

Новий адаптер TAP змінив, до якої мережевої карти хоста VMware будує міст. Вирішіть між закріпленням VMnet0 і маршрутизацією гостя, а потім прочитайте результат усередині VM.

Гість, який годину тому був у мосту і був доступний, тепер отримує тайм-аут на все, і ніхто не змінював його налаштувань. На хості інтернет і далі працює через тунель. Ці два факти разом указують геть від 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 він потрібен.

Схожі статті