Ноутбук роздає свій Wi-Fi, хост без скарг переглядає сайти через тунель, а планшет у цьому спільному доступі нічого не досягає. Хост перестав бути лише клієнтом у ту мить, коли ввімкнули спільний доступ: тепер це маршрутизатор, і перенаправлені пакети зустрічають інший набір правил. Те, що працює на хості, нічого не каже про пристрій за ним. Запустіть перевірки з нижчого клієнта, і ця різниця перестане бути теоретичною.

Успіх хоста нічого не доводить

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

Багато клієнтів пересилають лише трафік хоста і більше нічого, тому перегляньте розділ про спільний доступ у документації клієнта, а не покладайтеся на те, що тунель маршрутизуватиме за планшет. Видимий симптом — пристрій, який підключається, отримує адресу і потім зазнає невдачі на першому запиті. Клієнт, який відмовляється пересилати, на хості все ще виглядає цілком здоровим.

Який адаптер спільний, який обслуговує клієнтів

Запишіть обидва адаптери, бо вони мають різні адреси й різні фільтри, а зміна на неправильному пояснює багато заплутаних результатів. Хост спільного доступу зазвичай займає фіксовану адресу на нижньому боці й запускає там невелику службу DHCP і DNS. Windows тримає пересилання за адаптером, а не глобально, тому стан треба читати інтерфейс за інтерфейсом.

Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name,InterfaceIndex,LinkSpeed
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias,IPAddress,PrefixLength
Get-NetIPInterface | Select-Object InterfaceAlias,Forwarding,ConnectionState
Get-NetConnectionProfile

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

Пересилання, трансляція та фільтрування

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

Дальній стороні може знадобитися й зворотний маршрут для спільної підмережі — діапазон, якого сервер VPN ніколи не бачив. Там, де клієнт транслює, сервер бачить лише адресу тунелю, і зворотний маршрут не потрібен. Там, де він не транслює, власник шлюзу має навмисно додати цей маршрут, і це запит на зміну, а не налаштування клієнта.

Виконуйте перевірки на клієнті, а не на хості

Кожну перевірку виконуйте на клієнті, який збоїть, а не на хості, який працює. Тримайте адресу виходу, відповідь резолвера й тест програми в одній сесії, бо результати, зібрані з різницею в годину, нічого не кажуть про те, як поєднуються всі три.

Resolve-DnsName intranet.example.net -Type A
Resolve-DnsName intranet.example.net -Type AAAA
Invoke-RestMethod https://api.ipify.org
Test-NetConnection intranet.example.net -Port 443 -InformationLevel Detailed

Порівняйте адресу виходу з власною адресою хоста й зауважте, чи збігаються вони. Інша відповідь означає, що перенаправлений шлях обходить тунель, а це питання політики з власником, а не швидке виправлення. Збіжна відповідь поруч із збійною програмою переносить роботу на розв’язання імен або на політику дальньої сторони. Не зупиняйтеся й на результаті IPv4: спільний доступ може пройти всі перевірки IPv4, тоді як IPv6 виходить через інший вихід, тож повторіть перевірки імен і виходу із записом AAAA та докладним тестом з’єднання.

На керованій машині підтвердьте, що спільний доступ узагалі дозволений, бо відкриття доступу іншому пристрою — це адміністративне рішення, а не перемикач зручності. Після будь-якої підтримуваної зміни повторіть перевірки під час повторного підключення і ще раз під час збою. Чисте повторне підключення хоста не відновлює перенаправлений маршрут, який клієнт ніколи не підтримував.

Схожі статті