Отказоустойчивое переключение VPN: когда обратный путь остаётся в старом туннеле

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

Сначала запишите маршруты на обоих концах; вид с одной площадки не покажет асимметричный путь. Это ещё и шаг, который чаще всего пропускают под давлением времени.

Запишите маршруты обеих площадок до теста

Для каждого защищённого префикса запишите основной маршрут, резервный маршрут и предпочтение, выбирающее между ними. Укажите LAN-шлюз за каждой конечной точкой VPN, потому что конечная точка редко бывает последним прыжком.

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

Сделайте это на обеих площадках. Резерв, предпочитаемый с одной стороны и игнорируемый с другой, создаёт ровно ту асимметрию, которую вы пытаетесь избежать.

Наблюдайте запросы и ответы на каждой фазе

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

Если запросы смещаются, а ответы нет, проверьте маршрут удалённой площадки к префиксу клиента и её предпочтение резерва. Это решение о маршрутизации, а не отказ туннеля.

После теста верните исходное состояние и убедитесь, что основной путь снова предпочтителен. Восстановленный основной путь без предпочтения — это незавершённый дизайн переключения.

Управляйте состоянием сессии при смене шлюза

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

Сохраняйте стабильную адресацию там, где этого требует приложение. Дизайн переключения, меняющий адрес источника для каждой сессии, — это проектный выбор, и его следует записать. Этот выбор определяет, насколько сильно пользователи замечают перерыв.

Тестируйте приложение, которое держит долгую сессию, а не только новый запрос.

Верните основной путь и проверьте на дрожание

Убедитесь, что объявления маршрутов или предпочтения стабилизируются без колебаний. Дрожащий основной путь может мешать сильнее, чем явный отказ, потому что каждый переход сбрасывает состояние.

Держите администрирование шлюза доступным через путь восстановления, чтобы сам тест не запер вас снаружи. Записывайте фазы, наблюдаемые пути и время восстановления; именно эта запись делает следующее переключение предсказуемым. Заметки strongSwan о пересылке полезны, когда конечные точки — хосты Linux.