Два шлюза 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 может упростить обнаружение, но он не является синонимом непрерывного состояния, и доступность в любом случае остаётся проектом.