Два локальных адреса VPN: два партнёра Azure, а не один

На схеме два интернет-канала в филиале и один шлюз VPN в Azure, поэтому шлюз локальной сети получает оба публичных адреса. Выглядит аккуратно и работает не так, как подразумевает схема. Каждое локальное устройство VPN — это отдельные партнёрские отношения, и проект Microsoft для нескольких устройств даёт каждому свой ресурс шлюза локальной сети и своё подключение. Добавление второго адреса к одному ресурсу не создаёт второго партнёра. Оно создаёт ресурс, который не описывает правильно ни одно из двух устройств.

Миф: один шлюз, два адреса

Шлюз локальной сети — это описание удалённого партнёра: одна публичная конечная точка и частные префиксы за ней. Нет поддерживаемого способа заставить этот ресурс означать «любое из этих двух устройств».

Та же путаница встречается и в обратную сторону, где два публичных IP-адреса Azure читаются как доказательство существования двух шлюзов Azure.

Сначала посчитайте объекты, затем туннели

Возьмите два независимо управляемых локальных устройства, каждое со своим публичным адресом и доступом к одним и тем же частным сетям, плюс один шлюз Azure на основе маршрутизации в режиме активный-активный. У шлюза Azure два активных экземпляра с отдельными публичными IP-адресами. Каждое локальное устройство подключается к обоим экземплярам. Это полная сетка, и количество объектов следует из неё, а не из схемы.

Арифметика достаточно коротка, чтобы вставить её в проектный документ:

2 on-premises VPN devices
2 local network gateway resources
2 connection resources
4 IPsec tunnels in the complete 2 x 2 mesh

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

Что добавляет активный-активный режим на стороне Azure

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

Шлюз в режиме пассивного ожидания — вполне допустимый проект; он просто даёт другое количество туннелей.

BGP делает оба пути пригодными к использованию

Для проекта с несколькими устройствами оба локальных устройства запускают BGP. Дайте каждому уникальный адрес партнёра BGP и объявляйте одни и те же предусмотренные частные префиксы по соответствующим путям. Частные префиксы определяют защищённые сети, а публичные адреса определяют, где заканчиваются зашифрованные транспортные соединения. Путаница между этими двумя даёт проект, в котором все туннели подняты, а маршруты неверны.

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

Выбор на основе потока — это не объединение пропускной способности

Azure выбирает путь для каждого потока с помощью хеша по адресам и портам потока. В установившемся состоянии пакеты данного потока TCP или UDP обычно идут через один и тот же туннель, а локальная сторона может выбрать другой туннель для обратного направления. Поэтому два устройства и четыре туннеля повышают доступность, а не скорость одной передачи. Когда слайд поставщика обещает агрегацию, он описывает другую функцию или недоразумение.

Тестируйте с параллельными потоками, если хотите увидеть распределение путей, и с одним потоком, если хотите увидеть предел.

Какую избыточность вы на самом деле убрали

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

Ожидайте задержек обнаружения и сходимости и ожидайте, что некоторые существующие сеансы завершатся.