Клиенты VPN блокируются общедоступным профилем брандмауэра Windows

Туннель поднят, шлюз отвечает на ping, а файловый ресурс всё равно отваливается по тайм-ауту. Такое сочетание редко бывает проблемой маршрутизации: Windows поместил подсеть адаптера VPN в общедоступный профиль, и каждое разрешающее правило, написанное для частного или доменного профиля, так и не применилось. Я встречал это и на ноутбуках, которые спокойно достают офис, и на серверах RRAS, которые обслуживают всех остальных клиентов, и починка короткая, как только вы назовёте задействованный профиль. Вот порядок, в котором я работаю, с проверкой, которая говорит, когда остановиться перед следующим шагом.

Определите, по какому профилю трафик приходит на самом деле

У брандмауэра Windows нет единого глобального режима. Каждый подключённый интерфейс несёт категорию, и входящие пакеты фильтруются по категории того интерфейса, через который приходят, поэтому именно профиль адаптера VPN решает, что может достать клиент в туннеле, а не Wi-Fi- или Ethernet-адаптер рядом. Прочитайте оба факта, прежде чем что-либо менять:

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory, IPv4Connectivity
Get-NetFirewallProfile -Name Public | Select-Object Name, Enabled, DefaultInboundAction

При обычной установке OpenVPN или WireGuard адаптер VPN появляется как неопознанная сеть и попадает в общедоступный профиль — значение по умолчанию для любой сети, которую Windows не может классифицировать: ни один контроллер домена не ответил через неё, и ни один профиль шлюза не совпал. Имя интерфейса здесь ни на что не влияет, поэтому назвать адаптер «VPN» или «Corp» ничего не изменит. DomainAuthenticated требует машину, введённую в домен , которой этот интерфейс действительно позволяет достать контроллер домена; раздельный туннель, несущий только одну подсеть, этому требованию не удовлетворит.

Если нужное правило уже ограничено пулом VPN и уже применяется к категории, которую вы только что прочитали, остановитесь здесь: фильтрация — не ваш уровень, и следующее место для проверки — конфигурация службы. Эта проверка занимает десять секунд и экономит час правки правил. Названия категорий и то, что каждая покрывает, описаны в справочной документации Get-NetConnectionProfile.

Убедитесь, что дело в фильтрации, а не в маршрутизации, прежде чем править правила

Ping — слабый тест. ICMP может проходить, пока порт службы отбрасывается, и узел может отвечать из локальной сети, отказывая в том же запросе через туннель. Проверьте порт, который нужен клиенту, с самого клиента:

Test-NetConnection 10.8.0.1 -Port 445
Test-NetConnection 10.8.0.1 -Port 3389 -InformationLevel Detailed

Если проверка порта не проходит, разделите два уровня. Неисправность туннеля или маршрута обычно выглядит как полное отсутствие ответа от адреса шлюза, тогда как отбрасывание брандмауэром показывает шлюз, который отвечает, и порт службы, который не отвечает. На сервере Windows, публикующем пул через RRAS, выполните ту же проверку с клиента и прочитайте профиль самого сервера: интерфейс RAS может оказаться в категории, входящие правила которой никогда не упоминают диапазон клиентов, и поэтому машина обслуживает свою локальную сеть и отказывает каждому клиенту в туннеле.

Когда результат всё ещё неоднозначен, запишите в журнал отбрасывания для задействованного профиля и прочитайте их:

Set-NetFirewallProfile -Name Public -LogBlocked True `
  -LogFileName "$env:systemroot\system32\LogFiles\Firewall\pfirewall.log"

Записи, где адрес и порт клиента указаны с DROP, убедительны, и они же говорят, какого правила не хватало. Журнал, в котором ничего нет, а SYN клиента так и не появляется, указывает выше узла, поэтому вернитесь к туннелю, правилу NAT или маршруту пула, прежде чем трогать ещё один объект брандмауэра.

Ограничьте одно входящее правило пулом клиентов

Починка — одно входящее разрешающее правило, удалённый адрес которого — пул, а не весь мир. Из сеанса с повышенными правами:

New-NetFirewallRule -DisplayName "VPN clients - SMB 445" `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 `
  -RemoteAddress 10.8.0.0/24 -Profile Public

Когда служба — один двоичный файл, предпочтите правило, ограниченное программой, с -Program вместо списка портов; так исключение привязано и к процессу, и к диапазону источников.

Выбор профиля — это место, где ту же ошибку делают в обратную сторону. -Profile Public достаточно, когда адаптер общедоступный и остаётся общедоступным. -Profile Any оправдано, когда служба должна работать независимо от того, как Windows классифицирует адаптер, но только пока удалённая область сохраняется. Что никогда не оправдано — это -RemoteAddress Any в общедоступном профиле: такое правило следует за ноутбуком в каждую сеть кафе и отеля, к которой он подключается, и открывает порт всякому, кто делит эту подсеть.

Запишите пул рядом с правилом. -RemoteAddress 10.8.0.0/24 тихо перестаёт совпадать в тот день, когда пул VPN перенумеровывают, и сбой выглядит точно как исходная ошибка, поэтому стоит второго дня. Называйте правила по службе и диапазону источников, держите их вместе с -Group, и перечитывайте их всякий раз, когда меняется определение пула. Реестр правил, который можно просмотреть на одном экране, лучше правильного правила, которое никто не может найти.

Меняйте категорию только тогда, когда категория и есть решение

Переключение интерфейса в частный тоже работает, и это неверное значение по умолчанию. Частный профиль несёт длинный список встроенных разрешающих правил, охватывающих общий доступ к файлам и принтерам, обнаружение сети, удалённый рабочий стол и, в зависимости от базовой политики, ещё больше, поэтому переклассификация адаптера VPN включает их все сразу для каждого клиента в туннеле. Одно ограниченное правило даёт одну службу одному диапазону. На ноутбуке, который заходит и в недоверенные сети, эта разница не косметическая.

Бывают случаи, когда классификация действительно неверна: постоянно включённый или межсайтовый туннель, несущий офисную подсеть, — доверенная инфраструктура, и пометить этот адаптер частным — законный проектный выбор, сделанный один раз политикой, а не под каждую заявку. Когда вы это делаете, делайте это явно:

Set-NetConnectionProfile -InterfaceAlias "OpenVPN TAP-Windows6" -NetworkCategory Private

На управляемом устройстве сначала проверьте, владеет ли параметром групповая политика или базовая линия MDM. Если владеет, локальное изменение откатывается при следующем обновлении, а gpresult /h назовёт политику, которая им владеет; исправляйте там, а не на конечной точке.

Проверьте с обеих сторон и оставьте след

Проверьте поток, о котором сообщил пользователь, с клиента, после изменения:

Test-NetConnection 10.8.0.1 -Port 445
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallAddressFilter | Select-Object RemoteAddress
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort

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

Прежде чем считать дело сделанным:

• Профиль, указанный в правиле, — это профиль того интерфейса, через который приходит трафик.
• Удалённая область — это пул VPN, и этот пул соответствует тому, что сервер фактически выдаёт.
• Ни одно добавленное вами правило не использует -RemoteAddress Any в общедоступном профиле.
• Ничего не отключали, чтобы тест прошёл, и каждое изменение категории фиксирует, кто его одобрил.