Ping работает только в одну сторону: почему Windows отбрасывает эхо сервера

Ваш клиент пингует сервер, сервер не может пинговать клиент, и туннель в обоих этих утверждениях явно переносит пакеты. Отличается не путь, а первый пакет каждого теста: один — это ответ на поток, который Windows уже отслеживает, другой — новый входящий запрос, который не пропустило ни одно правило. Это различие объясняет большинство отчётов об одностороннем ping и прямо указывает на правило, которое нужно написать. Два теста в противоположных направлениях разделяют случаи примерно за минуту.

Два направления, два разных решения

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

Когда сервер отправляет запрос первым, никакое состояние ему не соответствует. Windows рассматривает пакет как новое входящее соединение и спрашивает входящую политику, которая по умолчанию ничего не предусматривает для запросов эха из произвольных источников.

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

Следите за пакетом, пока он не исчезнет

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

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

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

Ограничьте одно правило вместо открытия ICMP

Определите адаптер и его текущую категорию, прежде чем что-то писать, потому что оба появятся в области, которую вы собираетесь задать. Этот псевдоним — имя интерфейса Windows, которое не обязательно совпадает с именем импортированного профиля VPN. Команды ниже перечисляют, что существует, а затем показывают предварительный просмотр ограниченного правила, не применяя его.

Get-NetConnectionProfile
Get-NetAdapter | Where-Object Status -eq 'Up'
New-NetFirewallRule -DisplayName "VPN server echo" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -RemoteAddress 10.63.0.1 -InterfaceAlias "Office VPN" -Profile Private -Action Allow -WhatIf

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

Что правило не покрывает

Эхо IPv6 — другой протокол с другим типом сообщения, поэтому правило ICMPv4 ничего о нём не говорит, а туннелю, несущему оба семейства, нужно своё правило для второго. Это правило не открывает и ничего другого: RDP, общий доступ к файлам и любая другая служба по-прежнему зависят от своей политики. В этом весь смысл ограничения одного узкого правила вместо включения широкого разрешения ICMP. Широкое разрешение — это простое исправление и то, что живёт дольше всего, потому что потом его никто не замечает.

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

Читайте результат в правильном направлении

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

Get-NetFirewallRule -DisplayName "VPN server echo" | Get-NetFirewallAddressFilter
ping 10.63.4.17
ping -6 fd00:63::17

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