VPN подключен, но нет пинга к серверу: настройка Брандмауэра Windows для чайников

Обновлено: 27.08.2026 · Официальная документация ↗

Диагностика проблемы с доступностью сервера через VPN

Удаленный сотрудник успешно подключился к офисному VPN (WireGuard, OpenVPN, L2TP), статус подключения показывает «Подключено», однако при попытке проверить доступность офисного сервера возникает сбой.

Характерные признаки неполадки:

Тестовое действие	Результат в консоли	Вывод
`ping 192.168.1.10` (IP сервера)	«Превышен интервал ожидания для запроса» (Request timed out)	Пакеты блокируются межсетевым экраном на конечном сервере или отсутствует маршрут.
`ping 192.168.1.1` (VPN-шлюз)	Ответ от 192.168.1.1: число байт=32 время=15мс TTL=64	Сам VPN-туннель работает исправно, маршрутизация до шлюза присутствует.
Подключение по RDP / SMB	«Не удается подключиться к удаленному компьютеру»	Брандмауэр Windows на сервере блокирует весь входящий трафик из чужой VPN-подсети.

Пошаговое решение проблемы на стороне сервера Windows

Разрешение входящих эхо-запросов ICMPv4 (Ping) в Брандмауэре:

По умолчанию Windows Server блокирует все входящие пинги из других подсетей. Разрешим их одной командой в PowerShell от имени Администратора:

# Разрешить входящий Ping для всех профилей сети:
netsh advfirewall firewall add rule name="ICMPV4_ALLOW_PING" protocol=icmpv4:8,any dir=in action=allow

# Либо через современный командлет PowerShell:
New-NetFirewallRule -DisplayName "Allow ICMPv4-In (Ping)" -Protocol ICMPv4 -IcmpType 8 -Direction Inbound -Action Allow -Enabled True

Проверка типа сетевого профиля (Private vs Public):
Если Windows определила ваше сетевое или VPN-подключение как Общедоступная сеть (Public), брандмауэр автоматически блокирует сетевой доступ к файлам и портам. Переключите статус в «Частная»:
```
# Смотрим список сетей:
Get-NetConnectionProfile

# Меняем статус профиля на Private:
Set-NetConnectionProfile -InterfaceAlias "Ethernet" -NetworkCategory Private
```
Разрешение доступа к файлам и службам из VPN-подсети:
Если VPN выдает клиентам адреса вида 10.8.0.X, а сервер находится в 192.168.1.10, откройте порт SMB (445) и RDP (3389) для удаленной подсети:
```
New-NetFirewallRule -DisplayName "Allow SMB from VPN" -Direction Inbound -Protocol TCP -LocalPort 445 -RemoteAddress 10.8.0.0/24 -Action Allow
```
Проверка маршрута по умолчанию на стороне клиента:
Если на клиенте не включен шлюз в удаленной сети, добавьте статический маршрут до офисной сети в консоли Windows (от имени Администратора):
```
route add 192.168.1.0 mask 255.255.255.0 10.8.0.1 -p
```

Обратите внимание: Некоторые сторонние антивирусы (Kaspersky, ESET) имеют собственный встроенный сетевой экран, перехватывающий правила Брандмауэра Windows. Проверьте настройки защиты сети в самом антивирусе.

💡 Практика специалистов: При развертывании OpenVPN или WireGuard всегда включайте маскарадинг (NAT) на стороне VPN-сервера для входящего трафика в офисный сегмент, если не хотите перенастраивать таблицы маршрутизации на всех серверах локальной сети.

Частые вопросы (FAQ)

Почему через VPN пингуется шлюз 192.168.1.1, но не пингуется сервер 192.168.1.50?

Шлюз (роутер) по умолчанию отвечает на ICMP-запросы из любого интерфейса, а операционная система Windows на сервере 192.168.1.50 по умолчанию блокирует ICMP-трафик из подсетей, отличных от ее собственной.

Безопасно ли разрешать входящий Ping на сервере?

Да, разрешение входящего ICMPv4 Type 8 внутри частной офисной и VPN сети является стандартной практикой системного администрирования для мониторинга доступности хостов.

Что делать, если в статусе VPN адаптера написано 'Неопознанная сеть'?

Это штатное поведение виртуального адаптера при отсутствии назначенного DNS-суффикса домена или шлюза по умолчанию. Переключение профиля в 'Private' через PowerShell решает проблему блокировок.

Как проверить доступность конкретного TCP-порта сервера без утилиты ping?

Используйте встроенную команду PowerShell: `Test-NetConnection 192.168.1.10 -Port 3389` (или порт 445). Значение `TcpTestSucceeded : True` подтверждает доступность службы.