IPsec через частную WAN: границы политик SRX, которые нужно проверить

Частная WAN может нести внешние пакеты туннеля IPsec, поэтому адреса партнёра не обязаны быть публичными интернет-адресами. Меняются путь, по которому идут эти внешние пакеты, и разрешения на интерфейсе, который их принимает. На SRX внешний путь управления, привязка интерфейса туннеля и политика транслируемого трафика — три отдельных объекта. Поиск неисправности в одном, когда два других настроены неверно, — обычная причина, по которой туннель остаётся лежать.

Сначала зафиксируйте внешний путь IKE

Запишите четыре значения, прежде чем трогать политику: адрес партнёра, локальный интерфейс, принимающий IKE, контекст маршрутизации, достигающий партнёра, и маршрут, выбирающий этот интерфейс. Пакеты IKE адресованы самому SRX, поэтому им нужно разрешение host-inbound в принимающей зоне, а не политика транслируемого трафика. Частный адрес WAN не отменяет это требование, поскольку пакет всё равно завершается на устройстве.

Проверьте установленное состояние с помощью show security ike sa и конфигурацию с помощью show configuration security ike. Первая показывает, существует ли фаза 1; вторая показывает, что устройство считает правильным.

Привяжите интерфейс туннеля к правильной политике

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

Читайте фактические привязки, а не старую схему: show configuration security ipsec vpn для настройки привязки к интерфейсу и show configuration security policies для правил, ссылающихся на зону туннеля.

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

Держите маршрут к партнёру в underlay

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

Проверьте это с помощью show route 198.51.100.10, подставив реальный адрес партнёра, и подтвердите, что следующий хоп — не интерфейс туннеля.

Проверяйте управление и сервис по порядку

Двигайтесь вверх: состояние фазы 1, состояние фазы 2, затем реальный поток приложения. show security ipsec sa перечисляет ассоциации безопасности, а show security flow session destination-prefix 10.60.0.0/16 показывает, создаются ли транслируемые сеансы для защищённой сети.

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

Запишите вместе маршрут к партнёру, разрешение host-inbound, привязку туннеля, внутренний маршрут и политику приложения. Эти пять записей показывают, какой слой будет отвечать за будущий сбой, не полагаясь на метку порта.