Site-to-Site VPN між AWS і Azure: спершу напишіть зворотний маршрут
З’єднаний тунель між хмарами нічого не доводить, доки кожна підмережа навантаження не маршрутизує до віддаленого префікса. Пройдіть план по порядку, потім перевірте сервіс.
Тунель підніметься. Зазвичай так і буває, бо IKE потрібні лише збіжні пропозиції та доступна адреса партнера. А потім відмовляє зворотний шлях: навантаження в AWS надсилає пакети в тунель, але на боці Azure ніхто не знає, як відповісти на 10.10.0.0/16, або маршрут Azure лежить у таблиці, яку підмережа навантаження не використовує. Напишіть план маршрутів до того, як торкатися будь-якої консолі, і тунель стане найнуднішою частиною роботи.
Крок 1: заморозьте план адрес
Працюйте з конкретними значеннями. Навантаження в AWS розташоване на 10.10.1.20 всередині 10.10.0.0/16 і потребує TCP 443 до сервісу Azure на 10.20.1.30 всередині 10.20.0.0/16. Діапазони не повинні перетинатися, а приймальний тест — це пара сервісів, не тунель.
Запишіть ці чотири факти раніше за все інше, бо кожен наступний крок перевіряється за ними.
Крок 2: назвіть шлюз, якому належить кожен кінець
AWS Site-to-Site VPN може завершуватися на віртуальному приватному шлюзі або на транзитному шлюзі, і це різні власники маршрутизації. Azure пропонує керований VPN Gateway і окремо пристрої на базі ВМ, які клієнти ведуть самі. Запишіть, яка пара у вас, бо наступний крок відрізняється в кожній комбінації.
Для керованого шлюзу не копіюйте маршрут, що вказує на гадану адресу приватного пристрою. Для пристрою не припускайте, що поширення маршрутів у хмарі налаштовує гостьову операційну систему, бо це не так.
Помилка тут дає план, який виглядає повним, і надсилає пакети на адресу, що ніколи не відповідає.
Крок 3: напишіть маршрут, який реально використовує кожне навантаження
Кожна межа нижче — окремий пошук, і маршрут в одній із них не є маршрутом для пакета. Заповніть таблицю власними значеннями до того, як тунель запрацює.
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
У AWS таблицю маршрутів підмережі навантаження оновлюєте ви, навіть коли BGP або тунель у порядку; огляд маршрутизації вважає це частиною з’єднання. У Azure таблиця маршрутів, визначених користувачем, пов’язується з підмережею, а не з віртуальною мережею, тому перевіряйте чинний маршрут на NIC навантаження, а не в панелі VNet.
Керований шлюз Azure може вивчити віддалений префікс через поширення шлюзу, а UDR може скасувати це рішення. Додавайте UDR, коли є причина, а не рефлекторно. Якщо додаєте, спрямуйте його на наступний перехід, який шлюз публікує для шляху VPN, замість вигадувати адресу пристрою. Потім перечитайте чинні маршрути на NIC, бо рішення ухвалюється саме там.
Крок 4: узгодьте обсяг
Для BGP порівняйте, що оголошує кожна сторона, з тим, що інша сторона справді вивчила, префікс за префіксом. Для статичної маршрутизації порівняйте налаштовані віддалені діапазони з маршрутами навантаження, записаними на кроці 3.
Згода IKE щодо криптографії не доводить, що якась сторона вивчила 10.10.0.0/16 або 10.20.0.0/16. Два тунелі можуть бути підняті, поки одна сторона оголошує один /24 замість запланованого /16. Перевіряйте префікс у таблиці маршрутизації, а не в стані тунелю. Невідповідність з’явиться пізніше як одна робоча підмережа і одна, що ніколи не відповідає.
Крок 5: перевірте сервіс із реального джерела
Дозвольте передбачуваний потік у групах безпеки та мережевих ACL AWS, у NSG Azure і в будь-якому фільтрі пристрою на шляху. Потім відкрийте одне з’єднання з 10.10.1.20 на схвалену адресу й порт сервісу та підтвердьте, що відповідь повертається до того самого джерела.
І групи безпеки хмари, і NSG зберігають стан, тому відхилений зворотний пакет — це симптом маршрутизації, а не правило, яке ви забули написати у зворотному напрямку.
Ping з будь-якого шлюзу нічого не вирішує. ICMP на адресу шлюзу тренує шлях площини керування, а не переданий TCP-сервіс, потрібний навантаженню.
Відкат і записи
Запишіть власників маршрутів поруч з ідентифікаторами тунелю й збережіть таблиці маршрутів до зміни. Якщо зміну треба зняти, видаліть маршрути навантаження до розбирання тунелю, щоб жодна підмережа не залишилася вказувати на наступний перехід, якого більше немає.
Тоді подальше перенесення підмережі або підключення spoke має одне визначене місце для оновлення, замість робочого тунелю, що несе провину за маршрут, яким він ніколи не володів.