Почему подключению «точка — сайт» нужен маршрутизируемый шлюз Azure VPN

Шлюз на основе политик строит туннель IPsec, выбираемый селекторами трафика, и у него нет интерфейса, которому можно передать клиентские маршруты. Подключение «точка — сайт» — это функция маршрутизации: шлюз владеет пулом клиентских адресов и устанавливает в виртуальной сети маршруты к этим клиентам. Именно из-за этого несоответствия портал не показывает никакого варианта его добавить. Ничто в существующем шлюзе нельзя переключить, чтобы создать интерфейс, поэтому изменение — это замена, а не правка конфигурации.

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

Что на самом деле делает шлюз на основе политик

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

Маршрутизируемый шлюз работает наоборот: он предоставляет туннельный интерфейс, а маршруты решают, что в него попадает. Подключение «точка — сайт» и любой проект, где меняется набор партнёров, зависят от существования этого интерфейса.

Почему пулу клиентов нужен этот интерфейс

Когда ноутбук подключается, шлюз назначает ему адрес из пула «точка — сайт». Затем виртуальной сети нужен маршрут, говорящий, что этот адрес доступен через шлюз. Без туннельного интерфейса не к чему привязать этот маршрут.

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

Тип тоже не является настройкой для отдельного подключения. У одного шлюза один тип, и каждое его подключение ведёт себя соответственно, поэтому смешанному проекту нужен второй шлюз, а не второе подключение.

Тип фиксируется при создании

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

Это также включает решение о SKU в ту же сборку. Переход на больший SKU позже — ещё одна замена шлюза с ещё одним простоем.

Один шлюз, одна GatewaySubnet

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

Порядок перестройки, который ограничивает простой: создайте маршрутизируемый шлюз, заново создайте подключение между сайтами к тому же шлюзу локальной сети, подтвердите туннель и один запрос от хоста к хосту, и только затем добавьте «точка — сайт» и сгенерируйте новый клиентский пакет.

Что замена не исправляет

Второе ограничение относится к партнёру, а не к Azure. Локальное устройство на основе политик может достичь только той виртуальной сети, к которой оно подключено, и не может проходить в другие локальные сети или другие виртуальные сети через тот же шлюз. Замена стороны Azure не меняет того, что партнёр может выбрать.

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

Порядок операций и проверок

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

После любого изменения топологии заново создайте клиентские пакеты и держите пул в стороне от каждого локального и пирингового диапазона. Ограничения и различия SKU собраны в справочнике по параметрам Azure VPN Gateway.