Чому EC2 не може достукатися до вашого ноутбука в AWS Client VPN
Client VPN транслює IPv4-джерела клієнта на мережевий інтерфейс кінцевої точки. Тому відповідь працює, а нове з'єднання з EC2 — ні.
Ноутбук, під'єднаний через AWS Client VPN, без проблем досягає застосунку на EC2. Потім ви пробуєте зворотне — з EC2 на адресу, видану клієнту, — і з'єднання зависає або відхиляється. Ця асиметрія рідко буває відсутнім правилом групи безпеки. На кінцевій точці Client VPN, пов'язаній із підмережами VPC, AWS транслює IPv4-джерела клієнта на мережевий інтерфейс кінцевої точки, тому вхідної адреси VPC, яка представляла б ваш ноутбук, не існує.
Почніть з того, що показує перехоплення
Зробіть перехоплення на хості EC2, поки клієнт підключається, і прочитайте адресу джерела, яку застосунок справді бачить. Якщо це інтерфейс кінцевої точки на боці VPC, а не адреса з пулу клієнтів, трансляція підтверджена ще до того, як ви зміните хоч одне правило.
Пул клієнтів — це діапазон виділення, а не підмережа зі зворотним маршрутом. Саме на цій відмінності більшість таких розслідувань і помиляється.
Трансляція, яка пояснює асиметрію
Три потоки плутають між собою, і лише один із них — той, який люди перевіряють.
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
Опис компонентів Client VPN прямо зазначає, що IPv4-джерела клієнта транслюються на інтерфейс кінцевої точки, і цього достатньо, щоб побачити, чому середньому рядку немає з чим зіставитися.
Новому з'єднанню потрібні маршрут, крок розв'язання адреси та рішення про авторизацію. Стан трансляції з чужої сесії не дає жодного з трьох.
Чому відповідь — не нове з'єднання
Відповідь TCP зіставляється з наявним записом, тому зворотний шлях працює взагалі без вхідного правила. Свіжий SYN із хоста EC2 не має запису для зіставлення й стає звичайною вихідною спробою до призначення, до якого VPC не знає, як дістатися.
Тому ж описувати це як трафік, що йде лише в один бік, неправильно. Зворотний трафік у цих сесіях іде безперервно. Без шляху залишається саме ініціювання.
Що все ще ламає сесію, яка повинна працювати
Групи безпеки, мережеві ACL і власний брандмауер ноутбука — усе це важливо для з'єднань, які повинні пройти. Невдалий ping говорить найменше, бо політика ICMP часто відокремлена від тієї політики TCP, яка вас цікавить.
Пишіть ці правила щодо трансльованого джерела, а не адреси клієнта. Правила, прив'язані до адреси, яка ніколи не з'являється в мережі, — найпоширеніша самозаподіяна помилка в цьому дизайні.
Коли VPC справді мусить почати розмову
Якщо сервіс має повідомити робочу станцію, розверніть напрямок і дозвольте клієнту тримати постійний вихідний канал, на який сервіс відповідає. Якщо ціла віддалена мережа має бути доступною з VPC, виберіть архітектуру, яка публікує свої префікси та політику доступу, замість того щоб припускати, що Client VPN уже це робить. Доступ клієнт-клієнт — третій, вужчий випадок із власними об'єктами маршруту й авторизації. Ніщо з цього не є просто галочкою на наявній кінцевій точці.
Тримайте чесними й межі пояснення про IPv4. Поточна документація AWS відокремлює IPv6, де ця трансляція не застосовується, та інші моделі підключення, які маршрутизують інакше.
Перевіряйте в три позначені кроки: клієнт відкриває дозволену сесію, сервіс у VPC відповідає на цю сесію, а хост у VPC відкриває нову сесію в бік клієнта. Те, що перші два успішні, а третій ні, — очікувана форма цього дизайну, а не дефект, за яким треба ганятися з правилами брандмауера.