Ping через VPN: почему правила для эхо-ответа промахиваются мимо обратного пути

Отправьте ping на хост через VPN, и запрос уходит с одним типом ICMP, а возвращается с другим — этого достаточно, чтобы запутать любое правило, написанное в терминах портов. В эхо-обмене нет порта службы назначения, который можно скопировать в правило возврата, а фильтр, ожидающий симметрии, отбросит ответ, пока запрос проходит беспрепятственно. Исправление начинается с чтения пакета таким, какой он есть на самом деле, а затем с решения, какая граница на пути принимает решение. Обычно работают два уровня, а третий молча отбрасывает ответ. Разделы ниже разводят их в том порядке, в котором пакет встречает их.

Пакет меняет тип, а не порт

Эхо-запрос — это ICMP типа 8, кода 0, он несёт идентификатор и порядковый номер. Ответ — типа 0, кода 0, с тем же идентификатором и последовательностью, а концы IP переставлены. Эти поля определяет RFC 792, и именно идентификатор позволяет отправителю сопоставлять ответы со своими запросами.

То, чего нет, не менее важно: нет заголовка TCP или UDP, значит, нет и порта, который нужно разрешить. Правило, которое называет порт для эхо-ответа, описывает пакет, которого никогда не будет. Это самая частая ошибка в заявках на ping через VPN. Правило выглядит конкретным, не применяется ни к чему и оставляет сбой ровно там, где он был.

Пакет определяют три контекста

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

У этих трёх контекстов разные цепочки правил и разные счётчики, и именно их слияние в один — причина того, что «брандмауэр разрешает ICMP» всё равно может дать неудачный ping. Внешний туннель — четвёртый контекст: разрешение слушателя VPN не разрешает автоматически декапсулированный внутренний запрос, а внутреннее разрешение ничего не говорит о том, поднят ли внешний туннель.

Фильтры с состоянием и без состояния обрабатывают ответ по-разному

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

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

Ограничьте то, что разрешаете. Разрешить любой эхо-ответ откуда угодно — не то же самое, что завершить связь с состоянием, и номер типа не удостоверяет отправителя.

Трансляция меняет и идентификатор

Если трансляция источника намеренная, кортеж на дальнем конце не совпадает с отправленным клиентом. NAT может транслировать идентификатор ICMP-запроса вместе с адресами, поэтому требование, чтобы один и тот же номер был с обеих сторон, порождает ложное несоответствие.

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

Не сливайте ошибки ICMP с политикой эха

Сообщение «требуется фрагментация», используемое обнаружением MTU пути, не является эхо-ответом, и его полезная нагрузка цитирует пакет, который его вызвал. Разрешение только для эха, молча отбрасывающее эти ошибки, превращает проблему размера в зависшее соединение, что противоположно полезности.

Та же осторожность относится к семействам адресов. ICMPv6 использует другие типы сообщений и несёт существенные функции, которых нет у IPv4, поэтому копировать эти номера в правило IPv6 просто неправильно.

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