AWS Client VPN або bastion для доступу до VPC з peering

Один endpoint Client VPN може дістатися VPC, який з'єднаний peering з його пов'язаним VPC, і для законності цього bastion не потрібен. Вибір, який варто зробити, — де трафік змінює власника: маршрут endpoint, що потрапляє в підмережу асоціації та перетинає peering-з'єднання, або хост у VPC з peering, який завершує сеанс. Обидва шляхи працюють і відмовляють у різних місцях, тому рішення про володіння та аудит, а не про те, що дозволяє AWS. Ось як я вибираю між ними, і чотири записи, які роблять маршрутизований шлях робочим.

Два шляхи, один endpoint, різні власники

На маршрутизованому шляху трафік клієнта досягає endpoint, перекладається в адресу мережевого інтерфейсу Client VPN у підмережі асоціації та залишає цю підмережу через peering-з'єднання з A до B. VPC B не завершує жодного VPN-сеансу; він бачить звичайний трафік із VPC A, тому його зворотний маршрут указує на VPC A, а не на пул клієнтів.

На шляху через bastion клієнт спершу досягає хоста. Bastion у A все ще залишає останній перехід за peering-з'єднанням, тож робота peering залишається, а сеанс додається. Bastion у B також потребує шляху від клієнта, і коли цей шлях — той самий маршрут endpoint, ви отримуєте маршрутизовану схему плюс один перехід. Bastion прибирає роботу лише тоді, коли він уже існує, уже схвалений, і тому, що за ним, потрібна межа сеансу, а не межа мережі.

Чотири записи роблять маршрутизований шлях робочим

AWS документує цей сценарій на сторінці Client VPN how-it-works, і на практиці все зводиться до чотирьох записів, якими володіють дві або три команди. Діапазони наведені для прикладу; діапазон із peering має бути унікальним, а зворотний діапазон має відповідати вашому плану.

Маршрут і дозвіл — різні засоби контролю. Правильний маршрут endpoint без відповідного правила авторизації нічого не дає клієнту; правило авторизації для адресата, який endpoint не може маршрутизувати, дає йому чорну діру. Обидва мають називати той самий діапазон.

Маршрут endpoint указує на підмережу у власному VPC endpoint, ніколи на peering-з'єднання. Таблиці маршрутів VPC указують на peering-з'єднання, ніколи на інстанс або інтерфейс. Копіювання значення між ними зберігається без заперечень і нічого не маршрутизує.

Оскільки підмережа асоціації перекладає джерело клієнта, B має маршрутизувати назад до VPC A, а не до пулу клієнтів. Надсилання клієнтського діапазону через peering-з'єднання виглядає симетрично, проходить перевірку і тихо відмовляє, бо B ніколи не бачить пакета з клієнтським джерелом.

Групи безпеки та останній метр дозволу

Маршрутизація приносить пакети в B; рішення ухвалює все ще B. Для активного peering-з'єднання в тому самому регіоні група безпеки в B може посилатися на групу, застосовану до асоціації Client VPN, що тримає правило вузьким і переживає зміну адрес. Там, де посилання на групу неможливе, дозвольте діапазон підмережі асоціації явно замість розширення до 0.0.0.0/0, яке перетворює помилку маршрутизації на незрозумілий тайм-аут.

Потім перевірте те, чого маршрутизація ніколи не торкається: мережеві ACL на обох підмережах, список дозволених або аудиторію токена застосунку, і DNS. Peering не копіює приватні хост-зони, тож ноутбук може тримати робочий маршрут до адреси, яку не може розв'язати, а peering-з'єднання не додає довіри сертифікату. Спрямуйте endpoint на резолвер, який відповідає за B, і потім підтвердьте, що приватне ім'я та сертифікат збігаються.

Коли bastion — чесна відповідь

Я тримаю три тригери для свідомого вибору bastion. VPC з peering належить команді, яка не додасть зворотний маршрут для вашого діапазону або не прийме посилання на групу. Доступ має затверджуватися або записуватися для кожного сеансу, а застосунок не може нести це сам. Або останній перехід має залишитися всередині B, бо сервіс розв'язується лише там, а його TLS-ідентичність прив'язана до внутрішнього імені.

Ніщо з цього не обходить того, що peering не транзитивний. Нетранзитивність обмежує те, що можуть робити ресурси в B: вони не можуть використовувати A як транзит до третього VPC, з яким A з'єднаний peering. Це ніколи не означало, що користувач VPN не може напряму досягти VPC з peering, а bastion, збудований в обхід цього хибного прочитання, — хост, який латають без причини.

Зворотна помилка з часом коштує дорожче: пропустіть кожну команду через єдиний наявний bastion, а потім виявіть, що його група безпеки, таблиця маршрутів і вікно оновлень — це виробнича залежність. Запишіть, якому тригеру служить хост, і виведіть його з експлуатації, коли тригер зникне.

Transit Gateway і кілька асоціацій змінюють арифметику

Якщо endpoint підключено безпосередньо до Transit Gateway, а не до підмережі, модель змінюється: клієнти більше не перекладаються в адресу інтерфейсу в підмережі асоціації, і таблиці маршрутів шлюзу мають нести клієнтський діапазон плюс підключення, що веде до VPC з peering. У масштабі це чистіше, але робота переїжджає з чотирьох записів у таблиці маршрутів шлюзу.

Кілька асоціацій множать перевірки. Маршрут endpoint належить endpoint, але кожній підмережі асоціації потрібна таблиця маршрутів із справжнім наступним переходом peering. Сеанс може пройти через одну асоціацію, поки інша не має зворотного шляху, тож перевіряйте кожну.

Порядок перевірки, який швидко знаходить поломку

Виконуйте їх по черзі; кожен крок може пройти, поки наступний відмовляє, а тайм-аут клієнта майже ніколи не каже, що саме зламалося.

1. Розв'яжіть ім'я застосунку з клієнта та перевірте, що адреса в межах діапазону з peering.
2. Підключіться, потім прочитайте журнал з'єднань endpoint для асоціації, яка завершила сеанс.
3. У цій підмережі асоціації підтвердьте, що таблиця маршрутів спрямовує діапазон із peering на активне peering-з'єднання.
4. У підмережі ресурсів у B підтвердьте зворотний запис для діапазону інтерфейсу та відповідні правила групи.
5. Перевірте одну дозволену операцію та один ресурс, який має лишитися недоступним; другий ловить залишки налагодження.
6. Підключайтеся заново після кожної зміни маршруту split-tunnel, бо працюючий тунель не прийме новий набір маршрутів.

Два симптоми варто запам'ятати. SYN, що досягає B без відповіді, майже завжди відсутній зворотний маршрут. З'єднання, яке завершується і потім скидається, зазвичай група, ACL або застосунок. Жоден не з'являється в журналі endpoint як причина, тож тримайте чотири записи з власником поруч із кожним.

Якщо жоден із трьох тригерів не діє, завершіть маршрутизований шлях і запишіть ці чотири записи. Якщо діє один, тримайте bastion лише для цієї межі й залиште маршрут endpoint сервісам, яким не потрібен сеанс перед ними.