EC2 у зонах доступності: перевірте маршрутизацію перед VPN
Два екземпляри EC2 в одному VPC уже спільно використовують приватну маршрутизацію між зонами. Перевірте таблиці підмереж і правила доступу, перш ніж додавати ще один тунель.
Перш ніж встановлювати програмне забезпечення VPN між двома екземплярами EC2, дайте відповідь на одне питання: чи вони в одному VPC? Якщо так, приватний шлях уже існує, і розміщення в різних зонах цього не змінює. Більша частина роботи в цій ситуації — підтвердити, яку таблицю маршрутів насправді використовує кожна підмережа, а потім з'ясувати, чи збій узагалі був проблемою маршрутизації. Тунель зазвичай є неправильною відповіддю на це конкретне питання.
Перевірка 1: той самий VPC чи різні VPC
VPC є регіональним і охоплює зони доступності, тоді як кожна підмережа належить рівно одній зоні. Два екземпляри в різних зонах одного VPC усе ще перебувають у тому самому домені приватної маршрутизації.
Різні VPC ніколи не отримують приватний маршрут лише тому, що вони використовують спільний регіон або мітку зони. Такий випадок потребує підтримуваного з'єднання та власної роботи з маршрутами й дозволами, що є окремим рішенням.
Перевірка 2: що кажуть таблиці маршрутів підмереж
Запишіть схему з реальними значеннями. VPC з адресою 10.60.0.0/16 з підмережами 10.60.1.0/24 і 10.60.2.0/24 дає екземплярам 10.60.1.10 і 10.60.2.20 шлях через локальний маршрут VPC.
Потім перегляньте таблиці, пов'язані з обома підмережами, а не лише ту, яку ви знайшли першою. Конкретніший маршрут перевірки або пристрою може перекрити базовий, а ціль локального маршруту сама може бути замінена в новіших конфігураціях. Локальний маршрут, видимий десь у консолі, не доводить, що його використовують обидва робочі навантаження.
Використовуйте ті приватні адреси й імена, які VPC справді призначає. Приватна адреса не обов'язково має починатися з 10, а вигадування її з пам'яті — це спосіб поставити неправильний діагноз робочому середовищу.
Перевірка 3: маршрутизація чи авторизація
Маршрутизація лише доставляє пакет до мережевого інтерфейсу цілі. Група безпеки цілі все ще має допустити джерело й службу, правила вихідного трафіку джерела мають дозволяти запит, а будь-який мережевий ACL має дозволяти обидва напрямки, бо ACL не зберігають стан.
За цим стоять гостьовий брандмауер, прив'язка слухача й власна ідентичність застосунку. Кожен із них може відхилити запит, який маршрутизація доставила бездоганно.
Приймання має бути реальною операцією застосунку. Успішний ping не дає доступу до застосунку й не доводить, що ім'я TLS і облікові дані правильні, а заблокований ping не доводить, що всі приватні служби недоступні.
Перевірка 4: чи справді потрібне окреме з'єднання
VPN усе ще може входити до проєкту, але з зазначеної причини: підключити цей VPC до офісу, допустити ноутбуки або виконати вимогу накладної мережі. Ця причина відрізняється від звичайного обміну даними в межах одного VPC.
Пам'ятайте й про те, чим VPC не є. Це не розширення домашнього сегмента Ethernet. Застосунку, який залежить від виявлення широкомовленням, потрібна окрема вимога для оцінки. Це прогалина в проєктуванні, а не помилка маршрутизації.
Перевірка 5: питання шифрування
Приватна адреса й правило дозволу нічого не кажуть про криптографічний захист на рівні застосунку. Якщо дані потребують захисту від краю до краю, він походить із протоколу й моделі ідентичності, які служба справді підтримує.
Тримайте твердження про мережевий і прикладний рівні окремо в проєктній нотатці, бо їх поєднання — це спосіб, яким огляд зрештою стверджує захист, якого ніхто не впровадив.
Що записати
Запишіть обидва ідентифікатори підмереж, таблицю маршрутів, пов'язану з кожною, посилання на групи безпеки й операцію застосунку, яку ви перевірили. Це чотири факти, і вони вирішують більшість майбутніх суперечок про цей шлях.
Саме розміщення в зоні ніколи не каже вам додати VPN і ніколи не пояснює, чому приватний запит завершився невдачею.