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, прив'язку тунелю, внутрішній маршрут і політику застосунку. Ці п'ять записів показують, який шар відповідатиме за майбутній збій, не покладаючись на мітку порту.