Локальний і віддалений CIDR у AWS VPN: яка сторона яка?

Ви відкриваєте параметри Site-to-Site VPN, бачите два поля CIDR із позначками локальне й віддалене і тягнетеся до адреси, яку вважаєте локальною: VPC. Це протилежність тому, що має на увазі API. У параметрах з'єднання LocalIpv4NetworkCidr називає бік клієнтського шлюзу, а RemoteIpv4NetworkCidr бік AWS, бо з'єднання будується від клієнтського шлюзу. Консоль ніколи не каже цього вголос, і ніщо не відхиляє правдоподібну заміну.

Почніть із виклику API, а не з підпису в консолі

Прочитайте довідник параметрів з'єднання один раз повністю і зауважте, що кожен параметр написано з погляду клієнтського шлюзу. Це не випадковість найменування. Тунель описано так, як його бачить пристрій, що завершує його на вашому боці, тому локальне означає мережу за вашим шлюзом, а віддалене — мережу за шлюзом AWS. І поля IPv4, і поля IPv6 підкоряються тому самому правилу.

Напишіть дві позначки на стікері, перш ніж щось вводити: бік клієнта, бік AWS. Потім зіставте з ними свої адреси.

Розібраний приклад із ролями

Припустімо, локальний префікс — 10.20.0.0/16, а префікс VPC — 10.60.0.0/16. Параметри читаються саме так, як підказують ролі, а локальний діапазон стоїть у локальному полі:

{
  "LocalIpv4NetworkCidr": "10.20.0.0/16",
  "RemoteIpv4NetworkCidr": "10.60.0.0/16"
}

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

Повторіть вправу на папері в термінології партнера, з обома CIDR і обома позначками, перш ніж торкатися будь-якого пристрою.

Типові значення — не проєкт

Той самий довідник указує 0.0.0.0/0 як значення за замовчуванням для обох полів IPv4, з аналогічними значеннями для IPv6. Якщо ви бачите такі значення в наявному з'єднанні, це означає, що поле ніколи не звужували, а не що налаштовано вихід в інтернет. Розподіл маршрутів, таблиця маршрутів підмережі та засоби безпеки й далі вирішують, який трафік справді може пройти; значення CIDR лише описують, які діапазони тунель готовий вибирати.

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

Партнерський пристрій використовує інший погляд

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

Читайте довідку полів пристрою, а не назви його полів. Виробники використовують ті самі два слова для трьох різних понять.

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

Змінюйте параметри як зміну, а не як документацію

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

Після зміни перевірте з боку AWS і з боку партнера: джерело в кожному діапазоні досягає призначення в іншому, в обох напрямках. Один ping з одного боку доводить лише один селектор.

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