Почему 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 открывает новую сессию в сторону клиента. То, что первые два шага успешны, а третий нет, — ожидаемая форма этого дизайна, а не дефект, за которым нужно гоняться с правилами брандмауэра.