Переривчастий доступ через AWS Client VPN: перевірте кожну пов’язану підмережу

Користувач підключається, відкриває внутрішній застосунок і отримує відповідь; колега на тій самій кінцевій точці отримує тайм-аут з ідентичного ноутбука в тій самій мережі Wi-Fi. Цей шаблон — підпис кінцевої точки client VPN з більш ніж однією пов’язаною підмережею, де шляхи не еквівалентні. Я проходжу це від консолі назовні, бо дві вкладки вирішують, чи варте решта розслідування. Ніщо в конфігурації клієнта цього не пояснює.

Почніть із кінцевої точки та перелічте зв’язки

У консолі VPC відкрийте Client VPN endpoints, виберіть кінцеву точку й прочитайте вкладку Associations. Кожен зв’язок — це підмережа в зоні доступності, і клієнт потрапляє в ту, яку вибере сервіс під час побудови з’єднання. Запишіть ID підмереж і таблицю маршрутів, яку кожна реально використовує, бо ці два списки — це порівняння, яке ви збираєтеся зробити.

Якщо кінцева точка показує лише один зв’язок, ця теорія хибна, і клієнт — кращий підозрюваний.

Порівняйте таблицю маршрутів кінцевої точки з кожним зв’язком

Відкрийте вкладку Route table на тій самій кінцевій точці. Кожен цільовий CIDR там має ціль, а в client VPN ціль — це зв’язок, а не шлюз. AWS вимагає запис призначення для кожної пов’язаної підмережі, тож маршрут, що вказує лише на одну з них, робить доступ залежним від того, де опинилася сесія. Перевірте призначення, яке справді важливе, потім його правило авторизації, бо маршрут дає шлях, а правило вирішує, кому ним можна користуватися.

Коли ви зведете обидва шари в таблицю, збій важко не помітити.

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

Простежте кожну підмережу до її чинної таблиці маршрутів

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

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

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

Перевірте правила авторизації, потім зворотний шлях

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

Зворотний шлях заслуговує такої ж уваги. З’єднанню peering потрібен маршрут у VPC застосунку назад до CIDR клієнта, правила груп безпеки, що дозволяють трафік на обох кінцях, і мережеві ACL, які його не відкидають. Одностороння доступність, коли ping працює, а рукостискання TCP ні, зазвичай вказує на ACL або групу безпеки, а не на VPN.

Власні групи безпеки кінцевої точки розташовані на еластичних мережевих інтерфейсах зв’язку, тож правило, яке дозволяє порт застосунку з CIDR клієнта, має бути прикріплене до зв’язку, а не лише до екземпляра.

Перевіряйте повторним підключенням, а не одним щасливим запитом

За split tunnel маршрути кінцевої точки передаються під час встановлення з’єднання, тож змінений набір маршрутів ніколи не доходить до клієнта, який залишається підключеним. Відключіться й підключіться знову через підтримуваний клієнт, потім переконайтеся, що нові маршрути є на машині.

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