VPN блокує локальну мережу в Windows: маршрут чи політика клієнта?

Принтер, NAS або машина розробника на власному столі перестають відповідати тієї миті, коли підключається робочий VPN. Іноді одна команда маршруту виправляє це за секунди; іноді той самий маршрут правильний, а пакети все одно зникають, і це означає, що ви дивитеся на іншу проблему зі схожим симптомом. Рішення зводиться до трьох питань, і задавати їх у неправильному порядку — ось чому люди проводять цілий вечір, видаляючи й знову додаючи маршрути.

Три питання перед будь-якою командою

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

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

Питання перше: маршрут, фільтр чи ім'я

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

route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetric

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

Перевіряйте окремо за адресою і за іменем. Якщо ping 192.168.1.50 відповідає, а net view 192.168.1.50 ні, таблиця маршрутизації ніколи не була проблемою: тунель змінив резолвер, і локальне ім'я більше не розв'язується. Додавати для цього маршрут — марна робота.

Питання друге: чи дозволяє шлюз доступ до локальної мережі?

Комерційний клієнт встановлює більше, ніж маршрути. Під час підключення він отримує політику, і ця політика може містити явний дозвіл локальної мережі. У розгортаннях Cisco IPsec групова політика несе налаштування split-tunneling і окремий прапорець доступу до локальної мережі; прапорець у клієнті — це запит, який шлюз може відхилити. У AnyConnect профіль керує списками включення й виключення split та тим самим дозволом. У Windows RRAS відповідниками є параметр шлюзу за замовчуванням у профілі плюс статичні маршрути, які призначає сервер.

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

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

Питання третє: який напрямок вам потрібен?

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

route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -p

Друга форма закріплює один пристрій, і це те, що потрібно, коли одна адреса — уся вимога. Еквівалент netsh записує те саме рішення за іменем інтерфейсу, а не за індексом:

netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistent

Команди маршруту завершуються помилкою Параметр задано неправильно, коли адреса й маска не узгоджуються, наприклад адреса хоста з маскою /24. Для маршруту підмережі використовуйте адресу мережі, а для одного хоста — маску хоста.

Вхідний трафік інший. Сервер VNC або SSH на тій самій машині стає недоступним, коли відповіді на вхідне з'єднання виходять через шлюз VPN і ніколи не повертаються. Перевірте, що слухає служба, перш ніж чіпати маршрути:

netstat -ano | findstr :5900

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

Застосуйте найменшу відповідну зміну

Інша поширена дія — зняти прапорець «Використовувати шлюз за замовчуванням у віддаленій мережі» у додаткових властивостях IPv4. Це залишає інтернет-трафік локальним, але робить дві речі одразу: VPN перестає бути шляхом за замовчуванням, і клієнт перестає отримувати маршрути для віддаленої мережі, зокрема multicast. Зніміть прапорець, і віддалена мережа зникне, якщо тільки сервер не проштовхує конкретні віддалені префікси, потрібні кожному клієнту.

Ця асиметрія визначає порядок роботи. Якщо віддалена сторона має залишатися повністю доступною, проштовхуйте віддалені підмережі з сервера і не чіпайте локальний маршрут за замовчуванням. Якщо сервер змінити не можна, додайте постійний маршрут до віддаленого префікса через адресу, яку видав тунель, і перевірте за допомогою route print, що префікс указує на інтерфейс VPN, а маршрут за замовчуванням досі вказує на фізичний шлюз.

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