Гість Hyper-V втрачає DNS, коли підключається VPN хоста

Гість уранці працював нормально. Потім хост запустив Cisco AnyConnect, і ВМ втратила DNS, довіру домену та спільну теку, хоча всередині нічого не змінювалося. Тунель хоста й мережа гостьової системи — різні шляхи, і підключення одного не переміщує інший. Працюйте зсередини гостьової системи назовні та запишіть те, що бачите, перш ніж щось змінювати.

Що гість ще може бачити

Запишіть адресу, шлюз за замовчуванням і резолвер у ВМ: один раз до підключення хоста і один раз після. Гість, який зберіг адресу й втратив лише розв'язання імен, має проблему з резолвером. Гість, який ніколи не мав маршруту, має проблему зі шляхом, і обидва випадки потребують різної роботи. З хоста їх не розрізнити, тому читання має йти зсередини.

Ці три показники, зняті двічі, — ваша базова лінія. Усе подальше вимірюється відносно них.

Який вихід використовує гість

Hyper-V відповідає на це двома командами: Get-VMSwitch перелічує комутатори, а Get-VMNetworkAdapter -VMName TestVM показує той, до якого підключено гостя. Default Switch — це мережа NAT, якою керує Windows; зовнішній комутатор передає трафік фізичному адаптеру; внутрішній комутатор нічого не несе, доки хтось не додасть NAT або маршрутизатор. VirtualBox подає ті самі три ідеї як NAT, NAT Network і bridged.

Режим визначає, чи тунель хоста взагалі може мати значення. Гість за NAT транслюється WinNAT, а потім пересилається стеком хоста, тож він дотримується таблиці маршрутизації хоста; з клієнтом повного тунелю його трафік — це трафік, що входить в адаптер VPN, і його відкидають, коли клієнт блокує локальну підмережу. Гість, з'єднаний мостом на зовнішньому комутаторі, взагалі не досягає маршрутизації хоста: його кадри виходять безпосередньо з фізичної NIC, тому він обходить і тунель, і політику локальної мережі клієнта.

Спільне використання тунелю хоста з Hyper-V

Якщо гостьовій системі потрібен тунель і вона не може запустити власний клієнт, Windows може надати спільний доступ до VPN-з'єднання. Відкрийте властивості адаптера VPN, перейдіть до «Спільний доступ» і дозвольте іншим мережевим користувачам підключатися через нього. Спрямуйте домашнє мережеве з'єднання на адаптер Hyper-V, vEthernet (Default Switch), потім перевірте новий запит зсередини гостьової системи.

Ставтеся до цієї схеми як до лабораторного рішення, бо вона так поводиться. Її треба застосовувати знову після від'єднання, повторного підключення або перезавантаження хоста. У деяких збірках Windows 11 адаптера взагалі немає у спадному списку, і тоді цей шлях закритий.

Переінсталяція компонента Hyper-V врятувала кілька впертих гостей. Залиште це наостанок і спершу зафіксуйте стан гостьової системи.

Переспрямування портів, коли підмережа фільтрується

VPN хоста, який фільтрує NAT-підмережу гостьової системи, ламає прямий доступ, а не розв'язання імен. ВМ працює, але ssh [email protected] зависає, хоча трансляція гіпервізора все ще працює. Переспрямуйте порти, потрібні для роботи, і підключайтеся натомість до адреси хоста. Рядки Vagrantfile нижче охоплюють SSH і одну службу HTTPS; обидва додаються перед перезавантаженням.

config.vm.network "forwarded_port", guest: 22, host: 22
config.vm.network "forwarded_port", guest: 3443, host: 3443

Розв'язання імен — окреме рішення, і воно заслуговує на власне виправлення. Увімкніть функцію резолвера хоста для цього адаптера NAT, або налаштуйте внутрішній DNS-сервер усередині гостьової системи вручну. Якщо спрямувати гостя на публічний резолвер, перегляд запрацює, а всі внутрішні імена зламаються, що гірше за збій, бо виглядає як успіх. Перевірте ім'я, яке знає лише внутрішній резолвер.

Перевірка, яка скаже, що це спрацювало

Після будь-якої з цих змін виконайте новий запит зсередини гостьової системи при підключеному VPN хоста, а не до нього. Перевірте спільний доступ ще раз після повторного підключення та після перезавантаження, бо виправлення, що переживає лише одне з цього, не є виправленням. Переконайтеся, що список резолверів гостьової системи відповідає мережі, яку її трафік справді використовує. Потім перевірте переспрямування портів з адреси хоста, бо перевірка з гостьової системи нічого не доводить. Зсередини гостьової системи дві перевірки PowerShell охоплюють резолвер і переспрямований порт:

Resolve-DnsName intranet.corp
Test-NetConnection 192.0.2.10 -Port 22

Записуйте кожну зміну комутатора або драйвера разом із кроком її скасування. Посібник Microsoft щодо Hyper-V NAT пояснює, чим насправді є Default Switch, і його варто прочитати перед створенням другої мережі NAT, яка з ним конфліктує.