VPN между площадками: какое направление действительно требует правила?

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

Обратный трафик с состоянием меняет число

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

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

Где экран видит расшифрованные пакеты

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

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

Асимметричная маршрутизация ломает допущение

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

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

Проверьте оба направления с реальными адресами источника

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

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

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

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