Блокирует ли межсетевой экран VPN? Пошаговая проверка

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

Этап 1: подтвердите сервер и транспорт

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

Устаревшая запись DNS отправляет клиент на узел, который никогда не отвечал. Это ещё одна неисправность, имитирующая фильтр, и на её исключение уходит один запрос.

Запишите оба значения в заявку. Каждое последующее сравнение использует их, а заявка без них начинает расследование заново.

Этап 2: докажите путь одним контролируемым сравнением

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

Сначала завершите любой законный вход в сеть, потому что captive-портал выглядит как блокировка, пока не завершён.

Проверяйте порт, который вы действительно используете, и относитесь к результату TCP как к информации только о TCP.

Resolve-DnsName vpn.corp.example
tracert -h 8 -w 500 vpn.corp.example
Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed

Успешное рукопожатие TCP на порту 443 означает, что там ответил прослушиватель. Оно ничего не говорит о прослушивателе UDP на 51820 и о том, завершились ли переговоры.

Этап 3: прочитайте события безопасности на момент сбоя

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

Собирайте состояние профиля и последние события с машины, которая отказала, а не с соседнего узла.

Сравните время события со временем вашей попытки теста, потому что совпадающее имя правила с другой отметкой времени — случайность.

Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, LogBlocked
Get-NetFirewallRule -Enabled True -Direction Outbound | Where-Object DisplayName -match 'VPN'
Get-WinEvent -LogName 'Microsoft-Windows-Windows Firewall With Advanced Security/Firewall' -MaxEvents 20

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

Этап 4: проверьте пересылку после поднятия туннеля

Межсетевой экран может разрешить сеанс и всё равно отклонить всё, чего сеанс хочет достичь. Sysctl пересылки, правила NAT и обратные маршруты стоят после аутентификации, и широкое исключение для порта VPN не исправляет ни одного из них. Проверьте отдельно один внутренний адрес назначения и один интернет-адрес, потому что они обычно отказывают по разным причинам. Если внутренние имена отказывают, а адреса работают, посмотрите на проталкиваемый DNS раньше любого правила.

Выполните три проверки ниже на сервере, пока клиент подключён и пытается выполнить сбойный запрос.

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

sysctl net.ipv4.ip_forward
nft list ruleset | grep -n -E 'forward|masquerade'
tcpdump -ni tun0 -c 10

Когда пакеты приходят на туннель и ничего не уходит к адресату, подозреваемый — пересылка или NAT. Когда не приходит ничего, сеанс поднят, но клиент не отправляет, и смотреть нужно в таблицу маршрутов клиента.

Проверьте исправление и уберите то, что не помогло

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

Запустите те же три команды снова и сравните их с выводами, сохранёнными до изменения.

Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed
tracert -h 8 -w 500 vpn.corp.example
Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match 'VPN' | Select-Object DisplayName, Action

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