Маршрутизація трафіку між двома філіями через VPN-шлюз Azure
Два підключення «сайт — сайт» на одному VPN-шлюзі Azure можуть пропускати трафік філій, але лише коли обидва кінці вивчають префікс і існує зворотний шлях у LAN.
Дві філії можуть обмінюватися трафіком через VPN-шлюз Azure без будь-якого прямого тунелю між ними. Кожна філія відкриває підключення «сайт — сайт» до того самого шлюзу, і шлюз передає вивчені префікси між двома підключеннями. Працює це не завдяки другому тунелю, а завдяки обміну маршрутами: філія A має вивчити префікс філії B, а B — префікс A. Пройдіть перевірки нижче по порядку і зупиніться на першій невдалій, бо кожен наступний крок залежить від неї.
Передумови, перш ніж щось налаштовувати
Чотири умови вирішують, чи може ця схема взагалі працювати. Шлюз має бути заснований на маршрутах і працювати на SKU з підтримкою BGP, на обох підключеннях має бути ввімкнено BGP, адресні простори філій не повинні перекриватися, і жодна сторона не повинна покладатися на NAT, щоб приховати свій реальний префікс.
Плануйте ASN усвідомлено. Задокументоване значення за замовчуванням в Azure — 65515, і кожному маршрутизатору філії потрібен власний приватний ASN, що не конфліктує зі шлюзом чи іншою філією. Повторне використання значення за замовчуванням без перевірки наявної конфігурації шлюзу — це спосіб, яким шлях AS згодом відхиляється.
Також переконайтеся, що ви не очікуєте поведінки пірингу VNet. Шлюз обмінюється маршрутами між двома налаштованими підключеннями; він не робить довільні піринги транзитивними. Якщо третя мережа має досягти обох філій, їй потрібне власне підключення або власний шлях маршруту, а не припущення, що шлюз розподілить трафік. Запишіть цю межу до першого вікна змін, бо це те проєктне рішення, до якого люди повертаються, коли згодом додається новий сайт.
Налаштовуйте в цьому порядку
Кожен крок має спостережуваний результат, тому не рухайтеся далі, доки він не з'явиться.
- Увімкніть BGP на шлюзі віртуальної мережі та запишіть його ASN і адресу партнера.
- Створіть локальний мережевий шлюз для кожної філії з її реальним адресним простором, її ASN і адресою партнера BGP.
- Створіть кожне підключення «сайт — сайт» і ввімкніть BGP на самому підключенні.
- Налаштуйте маршрутизатор філії на піринг з адресою шлюзу, яку призначив Azure, а не з публічною кінцевою точкою IKE шлюзу за припущенням.
Четвертий крок — місце, де застрягає більшість спроб. Адреса партнера BGP, яку повідомляє Azure, — це та, яку маршрутизатор філії має використовувати як сусіда, і це не завжди адреса, яку люди очікують побачити на схемі тунелю.
Анонсуйте сам префікс філії, наприклад 10.10.0.0/16 з A і 10.20.0.0/16 з B. Не анонсуйте маршрут за замовчуванням чи широкий агрегат, щоб закрити відсутню конкретну мережу; прогалина згодом повертається тихою чорною дірою.
Перевірте обмін маршрутами на обох кінцях
Стан підключення — це не перевірка. IPsec може бути піднятий на обох підключеннях, поки між ними не проходить жоден префікс. Прочитайте партнерів BGP шлюзу та його вивчені маршрути, потім підтвердьте, що маршрут у бік іншої філії відображається як придатний шлях.
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
Префікс, наявний у таблиці BGP, усе ще може програти рішення про пересилання статичному маршруту або конкретнішому префіксу. Перевіряйте вибраний маршрут, а не лише отриманий.
Прослідкуйте зворотний шлях на боці LAN
Це та частина, яка виглядає правильно в Azure і відмовляє на місці. Хост у філії A надсилає свій пакет маршрутизатору VPN філії A, лише якщо цей маршрутизатор є його шлюзом за замовчуванням або якщо хост чи його шлюз має маршрут до префікса B. Те саме має бути істинним і в зворотному напрямку.
Якщо окремий магістральний комутатор є шлюзом за замовчуванням у LAN, йому потрібен маршрут у бік іншої філії, що вказує на маршрутизатор VPN. Без нього запит надходить, а відповідь виходить інтернет-шляхом, і користувач бачить з'єднання, яке відкривається і потім зависає.
Не вдавайтеся до групи безпеки мережі в підмережі шлюзу, щоб це виправити. Ця підмережа має власні вимоги, і NSG там не є підтримуваною заміною політики на боці філії. Фільтрація має бути на міжмережевих екранах філій і на самих робочих навантаженнях, де правила можуть переглядати їхні власники. Перенесення цих правил до NSG підмережі також ховає їх від команди, яка відлагоджуватиме наступний збій.
Дозвольте операцію, а потім доведіть її забороненим тестом
Вивчений маршрут — це не дозвіл. Дозвольте джерело, призначення та службу, які вам справді потрібні, через міжмережеві екрани філій і політику кінцевої точки, а решту залиште забороненою.
Перевірте зі звичайного робочого навантаження в філії A до реальної служби в філії B, підтвердьте відповідь, потім спробуйте операцію, яка має залишитися забороненою. Трафік, який генерує сам пристрій VPN, може використовувати іншу адресу джерела й оминати етап маршрутизації в LAN, тож успішний ping з маршрутизатора доводить менше, ніж здається.
Завершіть, записавши чотири факти: обміняні префікси, використовувані ASN, зворотний шлях LAN для кожної сторони й політику, що допускає службу. Якщо одного з них бракує, налаштування працює до першої зміни, а потім ніхто не може пояснити чому.