Двум активным туннелям IPsec по-прежнему нужен план обратного пути

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

Нарисуйте четыре шлюза, прежде чем рисовать маршрут

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

Эта таблица и есть проект. Всё после неё — вопрос, согласны ли устройства с таблицей.

Как выбирается прямой путь

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

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

Что на самом деле нужно обратному пути

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

Подтвердите реализованное двустороннее поведение или напишите явную политику, которая держит нужные границы согласованными. Догадка здесь обнаруживается во время сбоя, людьми, которым это не нравится.

Где трансляция решает за вас

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

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

Пройдите приёмку по порядку

Проверяйте в этом порядке и записывайте адреса на каждом шаге: новое соединение на пути A и его обратный путь, то же на пути B, затем потеря одного провайдера, затем восстановление. Для каждого результата отметьте, какие установившиеся потоки сдвинулись, каким пришлось переподключиться и куда потом ушли новые потоки. Сначала запишите ожидаемое значение, затем сравните его с захватом. Два установившихся туннеля ничего из этого не доказывают.

Проект завершён, когда написанная вами таблица совпадает с тем, что показывает захват, а не когда подняты оба туннеля.