Чи потрібен підключеному через peering Azure VNet власний VPN-шлюз?
Підключеному через peering VNet може знадобитися шлюз VPN хаба з підтримуваним SKU і однією настановою в кожному напрямку peering. Перевіряйте чинні маршрути, а не стан peering.
З'являється новий spoke VNet, у hub уже є робочий site-to-site шлюз, і очевидне питання — чи потрібно платити за другий шлюз. Зазвичай ні: транзит шлюза дозволяє spoke використовувати шлюз hub через peering. Чи це працюватиме, вирішують три умови, і жодної з них не видно на значку стану peering. Підключення через peering і дозвіл використовувати чужий шлюз — це різні налаштування, тому дві VM, які вже пінгують одна одну, нічого не доводять щодо шляху VPN.
Перша умова: шлюз і його відсутність у spoke
Azure підтримує транзит шлюза для SKU VPN Gateway, крім Basic, і його можуть нести як регіональний, так і глобальний peering. Spoke використовує шлюз, яким не володіє, тому свого мати не може: якщо в spoke вже є шлюз або вже вибрано варіант віддаленого шлюзу, потрібне налаштування транзиту буде недоступним або неефективним. Перевірте це до того, як щось налагоджувати, бо неактивний прапорець — це симптом, а не несправність. Спершу прочитайте SKU і наявний шлюз, а потім подивіться налаштування peering.
Не видаляйте наявний шлюз spoke, щоб з'явився варіант, доки не дізнаєтеся, що від нього залежить. Порядок міграції важливіший за прапорець.
Друга умова: одне налаштування в кожному напрямку peering
Peering — це два об'єкти, по одному на кожному VNet, і налаштування транзиту розташовані на різних боках цієї пари. Peering hub у бік spoke має дозволяти шлюзу hub обслуговувати spoke; peering spoke у бік hub має приймати шлюз hub. Посібник Microsoft із транзиту шлюза називає їх за напрямком, і це єдиний спосіб тримати їх правильно:
| Peering direction | What to enable |
|---|---|
| Hub → spoke | Allow gateway transit on the hub's peering |
| Spoke → hub | Use remote gateways on the spoke's peering |
Елемент керування з міткою remote змінює значення залежно від того, peering якого VNet ви редагуєте, тому читайте напрямок, а не слово. Налаштуйте обидві сторони, збережіть і переконайтеся, що peering повідомляє про підключення в обох місцях.
Третя умова: адресний простір і межі дозволів
Транзит не може зробити так, щоб той самий префікс призначення означав дві мережі, тому діапазони hub, spoke і локальної мережі мають не перетинатися, перш ніж щось із цього запрацює. VNet також можуть бути в різних передплатах або різних орендарях; це не заборона, але ідентичності, яка створює чи оновлює кожен peering, потрібні відповідні дозволи в цій мережі. Зміни між передплатами часто зазнають невдачі через дозволи, і помилку легко прочитати неправильно як проблему топології.
Запишіть діапазони й власників до зміни. Здогадки щодо будь-чого з цього дають peering, який підключається і нічого не маршрутизує.
Перевіряйте за ефективними маршрутами, а не за станом peering
Подивіться на ефективні маршрути на мережевому інтерфейсі робочого навантаження spoke і знайдіть фактичний префікс локальної мережі. Перевірте таблицю маршрутів підмережі та чи вимкнено поширення маршрутів шлюза, бо маршрут, визначений користувачем, або пристрій перевірки може перекрити шлях, який пропонують прапорці peering. Потім підтвердьте зворотний напрямок: локальна мережа має знати, як досягти префікса spoke через з'єднання site-to-site — або через вивчені оголошення, або через явний маршрут і відповідний запис захищеної мережі на пристрої клієнта. Якщо префікс відсутній з будь-якого боку, змінювати треба не прапорці peering.
Перевірте одну службу з робочого навантаження spoke і простежте за відповіддю. Тест зі шлюзу VPN або з VM у hub використовує інший префікс джерела та інший шлях.
Якщо топологія обслуговує і клієнтів точка-сайт, окремо перевірте їхні встановлені маршрути. Клієнтські пакети Windows можуть потребувати повторного створення після зміни топології, і це завдання маршрутизації на боці клієнта, а не доказ того, що спільне використання шлюза не вдалося.
Чого не дає спільне використання шлюза
Транзит шлюза — це зручність маршрутизації, а не авторизація. Групи безпеки мережі, локальні фільтри та правила на рівні служби досі вирішують, чого може досягти робоче навантаження spoke, тому ввімкніть конкретну службу від джерела до призначення замість того, щоб припускати, що спільний тунель дозволяє все за ним.
Peering також не є транзитивним так, як люди сподіваються. Додавання ще одного spoke або приватної кінцевої точки вносить власні вимоги до маршрутизації та доступу, які наявне налаштування транзиту не покриває.