AWS Client VPN із розділеним тунелем: які маршрути публікувати

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

Прапорець розділеного тунелю — не список призначень

AWS описує розділений тунель як додавання маршрутів кінцевої точки до таблиці маршрутів клієнта під час встановлення з'єднання. Маршрут до приватної VPC обмежує тунель цим призначенням; усе інше йде звичайним шляхом клієнта. Типовий маршрут — це інша інструкція з іншим ефектом, тому документація щодо розділеного тунелю застерігає від публікації 0.0.0.0/0 на кінцевій точці, налаштованій для цього режиму: це зазвичай ламає зв'язність, а не розширює її. Таблиця маршрутів кінцевої точки — це політика, а таблиця маршрутів клієнта — результат, який можна переглянути.

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

Перше рішення: чи має загальний інтернет-трафік залишатися локальним?

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

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

Друге рішення: які приватні префікси і з чиєю авторизацією?

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

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

Коли призначення має бути доступним за іменем, зверніть увагу, що наступне питання — розв'язання імен, а не маршрут.

Третє рішення: який resolver слідує за тунелем?

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

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

Змініть набір маршрутів, потім перевірте обидва світи

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

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

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