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-сесія значно раніше, ніж як зламаний застосунок.

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

Схожі статті