Два шлюзи IPsec без спільної IP: що насправді робить перемикання під час відмови

Вимкніть шлюз A посеред наради і подивіться, як за хвилину тунель повертається через B; з'єднання працює, відеодзвінок, можливо, ні. Це чесна картина холодного перемикання між двома IPsec-шлюзами з незалежними адресами. Клієнт знову вибирає кінцеву точку і будує нові відносини, що відновлює доступність без перенесення криптографічного стану старого сеансу. Якщо простежити послідовність, стає зрозуміло, які обіцянки проєкт здатен виконати.

Задаймо сцену: дві адреси, жодного плаваючого IP

Шлюз A відповідає за однією доступною адресою, а шлюз B — за іншою. У клієнта є схвалений спосіб вибрати B, коли A зникає, і немає спільної зовнішньої адреси, на яку претендують обидва шлюзи. У цьому проєкті віртуальний IP означає саме цю спільну точку входу, а не внутрішню адресу, призначену клієнту віддаленого доступу.

Це визначення важливе, бо дві ідеї плутаються в заявках, і виправлення однієї не є виправленням іншої. Звіт про те, що спільний вхід не пішов за шлюзом, описує один проєкт. Звіт про те, що ноутбук втратив внутрішню адресу, описує оренду клієнта. Різні власники, різні журнали, різні ремонти.

Пройдімо відмову: виявити, потім вибрати знову

Спершу щось помічає, що A перестав відповідати. Це може бути виявлення мертвого партнера на рівні тунелю, протокол маршрутизації, що відкликає шлях, або тайм-аут застосунку, який зрештою змушує перепідключитися. Кожен має іншу шкалу часу, і найповільніший зазвичай визначає, скільки чекають користувачі.

Потім клієнт вибирає B через будь-який механізм, який підтримує розгортання: другий налаштований віддалений вузол, ім'я DNS, розв'язане в здорову адресу, або маршрутизацію, яка тепер віддає перевагу іншому шляху. Вибір — це крок політики, і він має існувати до відмови, інакше станеться випадково.

Що B може і чого не може успадкувати

B може ділити з A шаблон конфігурації, центр сертифікації та політику автентифікації. Він не може успадкувати живі асоціації безпеки. Ключі сеансу, індекси параметрів безпеки та стан послідовності належать відносинам, які встановили A і клієнт, і в B немає жодного з них.

Перенесення цього стану між шлюзами — справжня інженерна проблема, тому документація strongSwan щодо високої доступності трактує її як кластерний проєкт, а не як прапорець конфігурації. Конкретний кластерний рецепт не є загальною відповіддю для хмарної мережі, і його копіювання без підтримної інфраструктури купує складність замість безперервності.

Встановлення нових відносин

Коли B вибрано, клієнт виконує новий обмін IKE: нові значення nonce, нові значення Diffie-Hellman, нові ідентифікатори для виникаючих асоціацій. Автентифікація знову відбувається на B. Якщо проєкт спирається на машинні облікові дані, перепідключення може відбуватися без нагляду; якщо потрібен людський фактор, хтось має бути присутнім, щоб перемикання завершилося.

Визначте цей користувацький досвід до збою, а не під час нього. Скажіть прямо, що робитиме клієнт, як довго він намагатиметься і що покаже, коли здасться, бо різниця між хвилиною перепідключення та дзвінком у підтримку зазвичай полягає в документації та перевіреному профілі.

Збереження тієї самої внутрішньої адреси допомагає застосункам, які очікують стабільної локальної ідентичності, і не зберігає їхні сеанси. Прив'язки NAT спливають, з'єднання TCP скидаються, і все, що має власний тайм-аут, самостійно вирішує, чи повторювати спробу.

Два тунелі паралельно — це інший проєкт

Запуск обох тунелів одночасно — допустимий шаблон, коли його підтримують обидва шлюзи та проєкт маршрутизації. Тоді вибір маршруту вибирає активний шлях, і зворотний шлях має збігатися, інакше трафік виходить через один шлюз і повертається через інший без стану, який би його зіставив.

Перекривні політики тунелів самі по собі не створюють упорядкованого перемикання. Вони створюють двох кандидатів, і щось має детерміновано вирішити між ними: метрика маршрутизації, пріоритет політики або явна перевага в клієнті.

Яку б форму ви не обрали, запишіть контракт: як виявляється відмова, як вибирається альтернатива, яка автентифікація їй потрібна і скільки, як очікується, триватиме перепідключення. Спільна IP може спростити виявлення, але вона не є синонімом безперервного стану, і доступність у будь-якому разі є проєктом.