Junos Dual-WAN IPsec VPN: сопоставление исходного пути с нужным шлюзом

Две линии WAN на площадку выглядят как резервирование, пока не попытаешься доказать, какую пару адресов реально использовал конкретный поток. На SRX один шлюз IKE несёт один внешний интерфейс и один локальный адрес; список удалённых кандидатов не создаёт второй локальный источник. Поэтому разбор начинается с матрицы пар, а не с конфигурации: Junos спокойно зафиксирует проект, покрывающий лишь половину задуманных комбинаций. Я столкнулся с этим на двух SRX345s: резервный туннель поднялся чисто и всё равно уронил сессию при возврате.

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

Составьте карту пар до того, как трогать CLI

Если площадка A может выходить из A1 или A2, а площадка B может принимать на B1 или B2, у вас четыре внешние пары адресов. Большинству проектов две из них нужны постоянно, а остальные две считаются опциональными. Запишите матрицу и отметьте каждую строку, потому что каждая обещанная строка позже стоит шлюза, туннельного интерфейса и решения о маршрутизации.

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

Один шлюз на локальный источник, а не на удалённую площадку

Список удалённых адресов принадлежит шлюзу, как и локальный источник. справочник по шлюзам IKE держит удалённые адреса, внешний интерфейс, локальный адрес и обнаружение мёртвого партнёра как отдельные настройки, и в этом весь смысл: два локальных источника означают два шлюза на двух устройствах st0. Делить между ними политику IKE нормально; оставить один шлюз и надеяться, что он сам выберет другой источник, — нет.

set security ike policy IKE-P1 mode main
set security ike gateway GW-A1 ike-policy IKE-P1
set security ike gateway GW-A1 address 198.51.100.20
set security ike gateway GW-A1 address 198.51.100.21
set security ike gateway GW-A1 external-interface ge-0/0/0
set security ike gateway GW-A1 local-address 203.0.113.10
set security ike gateway GW-A1 version v2-only
set security ike gateway GW-A2 ike-policy IKE-P1
set security ike gateway GW-A2 address 198.51.100.20
set security ike gateway GW-A2 external-interface ge-0/0/3
set security ike gateway GW-A2 local-address 192.0.2.10
set security ike gateway GW-A2 version v2-only

Затем подключите туннели и дайте удалённому префиксу два next hop, по одному на туннель:

set interfaces st0 unit 1 family inet
set interfaces st0 unit 2 family inet
set security ipsec policy IPSEC-P1 perfect-forward-secrecy keys group14
set security ipsec vpn VPN-A1 bind-interface st0.1
set security ipsec vpn VPN-A1 ike gateway GW-A1 ipsec-policy IPSEC-P1
set security ipsec vpn VPN-A2 bind-interface st0.2
set security ipsec vpn VPN-A2 ike gateway GW-A2 ipsec-policy IPSEC-P1
set routing-options static route 10.20.0.0/16 qualified-next-hop st0.1 preference 10
set routing-options static route 10.20.0.0/16 qualified-next-hop st0.2 preference 20

Может ли один шлюз держать две инструкции типа address, зависит от версии и от того, какой процесс IKE выполняется на устройстве. Более старый Junos на базе kmd принимает один удалённый адрес на шлюз; новые сборки поддерживают несколько кандидатов, но добавляют свои ограничения, а кластеры высокой доступности — частое место, где эта поддержка сужается. Проверьте примечания к выпуску для вашей точной сборки, прежде чем копировать это со старого шасси.

Подтвердите, какая ассоциация пронесла пакет

Две SA и два туннеля не говорят, какой из них передал сессию. Спросите устройство напрямую и сравните поля с парой, которую задумывали:

show security ike sa detail
show security ipsec sa detail
show security flow session destination-prefix 10.20.1.0/24
show interfaces st0.1 | match packets

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

Дайте каждому виду отказа собственный детектор

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

set security ike gateway GW-A1 dead-peer-detection interval 10
set security ike gateway GW-A1 dead-peer-detection threshold 3
set security ipsec vpn VPN-A1 vpn-monitor source-interface st0.1
set security ipsec vpn VPN-A1 vpn-monitor destination-ip 10.20.0.1

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

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

Переадресуйте одну линию, не трогая другую

Когда провайдер выдаёт новый блок, меняйте одну связку за раз. Обновите address или local-address на обоих партнёрах для этой пары, сделайте commit и очищайте только затронутые ассоциации по индексу, а не все SA на устройстве. Глобальная очистка снесёт и здоровый туннель и превратит окно обслуживания в простой.

Сохраните один неудачный поток и детали его сессии как доказательство, прежде чем что-то чистить, а затем повторите проверки выше на новой паре адресов. Возврат линии — это решение о маршрутизации, поэтому относитесь к возврату как к отдельному проверенному шагу, а не предполагайте, что старое предпочтение вернётся само.

Закройте изменение коротким чек-листом

Проект туннеля с двумя WAN готов, когда вы можете назвать пару за каждой сессией, а не когда обе SA подняты. Пройдите список ниже на том устройстве, которое вы действительно меняли:

• У каждой обещанной пары есть шлюз, устройство st0 и запись маршрута.
• Каждый туннель видели несущим пакеты, а не просто держащим SA.
• Оба конца согласны насчёт обнаружения и того, какая сторона восстанавливает предпочтение.
• Обратный путь каждой пары записан рядом с её прямым путём.

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