UDR в Azure к VPN-шлюзу: одно назначение, а не весь исходящий трафик

Направьте один префикс Azure на VPN-шлюз, не перемещая весь исходящий трафик. Прочитайте действующие маршруты, привяжите подсеть нагрузки и завершите обратный путь.

Вы добавляете определяемый пользователем маршрут для одного внешнего префикса, направляете его на VPN-шлюз, а трафик всё равно уходит через интернет-путь Azure. Или уходит правильно, но ответ никогда не возвращается. Оба результата происходят из одной ошибки: считать следующий хоп в Azure всем проектом. Таблица маршрутов решает только, какой выход пакет выберет внутри Azure. Что происходит с ним после туннеля и как возвращается ответ — это вторая половина, которую нужно построить.

Следующий хоп — это шлюз, а не IP-адрес устройства

UDR отправляет подходящий префикс типу следующего хопа, и VirtualNetworkGateway — это тип, а не адрес. Люди вставляют частный IP-адрес шлюза в маршрут VirtualAppliance и потом удивляются, почему ничего не совпадает, ведь этот тип ожидает сетевую карту или внутренний балансировщик нагрузки. Документация Microsoft по маршрутизации также ограничивает следующий хоп шлюза виртуальной сетью, шлюз которой является VPN-шлюзом. ExpressRoute, Route Server и хаб Virtual WAN этой опцией не адресуются.

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

Прочитайте действующий маршрут, прежде чем что-то менять

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

Сначала посмотрите на действующую таблицу, затем решите, добавляете вы маршрут или заменяете:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

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

Пишите маршрут под реальный префикс и подсеть

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

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

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

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

Завершите локальную половину, иначе поток умрёт там

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

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

Селекторы и списки разрешений отделены от всего этого. Выбор следующего хопа в Azure не расширяет селекторы трафика VPN и не меняет список разрешённых источников внешнего сервиса.

Проверяйте по источнику, который видит назначение

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

Транзит через выбранный префикс — куда более узкое изменение, чем принудительное туннелирование. Держите его узким, и откат — это удаление одного маршрута.

Похожие статьи