AWS Client VPN чи Site-to-Site: перевірте, хто відкриває з'єднання

Це вирішують чотири перевірки, і жодна з них не є назвою протоколу. Хто відкриває з'єднання, що автентифікує AWS, як з'єднання приєднується до вашої мережі та які маршрутизація й політика йдуть із ним. Дайте відповіді по порядку, і вибір продукту зазвичай робиться сам собою; дайте їх після того, як уже купили проєкт, і ви будете захищати тунель, який вирішує не ту половину проблеми. Жодна з чотирьох не просить вас вибрати шифр, тому проєкт, що починається з протоколу, зазвичай є ознакою того, що вимоги ніколи не були записані.

Кожну перевірку проводьте щодо фактичної кінцевої точки, клієнта й родини адрес, які ви плануєте використовувати, а не щодо категорії. Керовані VPN-продукти відрізняються від будівельних блоків OpenVPN і IPsec, на які вони схожі.

По-перше, хто відкриває з'єднання

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

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

По-друге, що автентифікує AWS

У Client VPN AWS автентифікує налаштовану ідентичність клієнта або користувача: сертифікати, каталог або федеративну ідентичність, залежно від налаштування. У Site-to-Site VPN AWS автентифікує ідентичність партнера шлюзу. Ця різниця не косметична. Одна модель масштабується додаванням користувачів і відкликанням їхніх облікових даних; інша — довірою до всього, що стоїть за одним шлюзом.

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

По-третє, як з'єднання приєднується

Client VPN приєднується через асоціації підмереж VPC або підтримуване пряме приєднання до Transit Gateway. Site-to-Site VPN приєднується до цілі AWS VPN, зазвичай віртуального приватного шлюзу або Transit Gateway. Посібник з архітектури Client VPN документує варіант Transit Gateway, і його наявність не перетворює сесію ноутбука на шлюз філії та не скасовує описаних вище автентифікації й авторизації клієнта.

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

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

Client VPN приносить керування клієнтськими з'єднаннями та правила авторизації для цільових мереж, які ви дозволяєте. Підключеному користувачеві все ще потрібні передбачений маршрут до кінцевої точки, правило авторизації, що його дозволяє, і доступ, якого вимагає сам ресурс. Site-to-Site VPN маршрутизує між мережами, представленими клієнтським шлюзом, використовуючи підтримувані статичні маршрути або BGP залежно від проєкту, тож окремим машинам за маршрутизатором філії не потрібен кожній свій клієнтський вхід.

Не виводьте непідтримувану поведінку з категорії в жодному напрямку. VPN віддаленого доступу не є універсально нездатними передавати зворотний трафік або підтримувати шлюзові схеми, і IPsec не блокується NAT автоматично — AWS документує проходження NAT і вимоги до клієнтського шлюзу, а реальне обмеження — це підтримувана конфігурація шлюзу. Перевірте обмеження для своєї кінцевої точки, перш ніж вимагати з'єднань, ініційованих у бік клієнтів, або пересилати LAN за однією сесією. Така сама обережність стосується родин адрес: кінцева точка, що працює через IPv4, не означає шлях IPv6, тож підтвердьте родину, про яку ваш клієнт або шлюз справді домовлятиметься.

Site-to-Site VPN дає два тунелі на з'єднання, і ця надмірність є завданням проєктування, а не функцією, яку можна припускати. Робота клієнтського шлюзу, перемикання маршрутів у разі відмови та покриття тестами мають бути сплановані; порівняння однієї сесії ноутбука з абстрактним VPN-сервером нічого не доводить ні про одне з них.

Де зустрічаються два проєкти

Сервіси не виключають один одного, і звичайна виробнича форма використовує обидва: працівники на Client VPN, мережі філій на Site-to-Site, з явними маршрутами та політикою доступу між пунктами призначення, яким потрібно спілкуватися. Таблиця — це підсумок чотирьох перевірок, а не заміна їхнього виконання.

Одне, чого не замінює жоден із двох продуктів: TLS до застосунку, вимога шифрування якого сягає далі кінцевої точки VPN. Якщо ваша сфера відповідності закінчується на застосунку, тунель — це транспорт, а сертифікат усе ще є засобом контролю.

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