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 непередбачуваною.