Чому підключенню «точка — сайт» потрібен маршрутизований шлюз Azure VPN

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

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

Що насправді робить шлюз на основі політик

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

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

Чому пулу клієнтів потрібен цей інтерфейс

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

Пул береться з діапазону, який ви задаєте, і шлюз виділяє з нього. Якщо цей діапазон перетинається з локальною мережею або з піринговою віртуальною мережею, конфлікт виявиться лише після підключення клієнта, а це поганий момент для його виявлення. Зарезервуйте пул до початку міграції.

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

Тип фіксується під час створення

Microsoft зазначає, що шлюз віртуальної мережі не можна після розгортання змінити між шлюзом на основі політик і маршрутизованим. Немає ні команди перетворення, ні перемикача в порталі. Створення другого шлюзу в тій самій підмережі теж не обхідний шлях, оскільки Azure дозволяє один шлюз на віртуальну мережу. Тому міграція — це видалити, перебудувати й підключити заново.

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

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

Шлюз живе в підмережі з назвою GatewaySubnet, і лише один шлюз її займає. Добір розміру цієї підмережі належить до підготовки, бо більшому SKU потрібно більше адрес, а підмережу не можна зменшити потім. Запишіть поточні налаштування між сайтами, спільний ключ, шлюз локальної мережі та чинні маршрути, перш ніж щось чіпати. Потім розглядайте вікно як простій, бо тунель між сайтами залишається вимкненим, доки не буде налаштоване нове підключення.

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

Чого заміна не виправляє

Друге обмеження належить партнеру, а не Azure. Локальний пристрій на основі політик може досягти лише тієї віртуальної мережі, до якої він підключений, і не може проходити до інших локальних мереж або інших віртуальних мереж через той самий шлюз. Заміна боку Azure не змінює того, що партнер може вибрати.

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

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

Перевіряйте кожну можливість окремо. Спершу стан тунелю між сайтами й один запит від хоста до хоста, потім підключення «точка — сайт» і один приватний ресурс, потім будь-який шлях проходження, який заявляє проєкт. Зелений статус шлюзу доводить лише те, що асоціація безпеки піднялася, і нічого більше. Тримайте перевірки в цьому порядку, щоб збій указував на етап, який його вніс.

Після будь-якої зміни топології повторно створіть клієнтські пакети й тримайте пул осторонь від кожного локального та пірингового діапазону. Обмеження й відмінності SKU зібрано в довіднику з налаштувань Azure VPN Gateway.