LAN за одной сессией AWS Client VPN: что пересылается

Ноутбук подключается к конечной точке AWS Client VPN, попадает в частную подсеть, и всё выглядит здоровым. Рабочий стол в том же LAN не достигает ничего, хотя на хосте Linux тоже есть мостовой интерфейс и обе машины на одном кабеле. В туннеле ничего не настроено неправильно; недостающая часть — маршрутизация, а мост — ложный след.

Расширение сессии Client VPN на LAN — это роль шлюза. Это не сегмент Ethernet, растянутый в управляемый сервис.

Хост работает, а LAN — нет

Интерфейс туннеля на машине Linux имеет адрес внутри CIDR клиента Client VPN, и конечная точка протолкнула маршруты для диапазонов VPC. Запрос, сделанный на этой машине, — локально сгенерированный трафик: он выбирает маршрут, выходит через туннель и получает ответ. Этот путь никогда не касается кода пересылки, интерфейса LAN или любого правила брандмауэра, управляющего транзитом.

Трафик с другого устройства LAN — это другой поток. Он приходит на интерфейс LAN, требует маршрута, указывающего в туннель, требует включённой пересылки, требует брандмауэра, который его разрешает, и требует, чтобы ответ вернулся через тот же хост. Четыре условия, и работающий тест на ноутбуке не доказывает ни одного. Со стороны рабочего стола сбой выглядит странно: туннель поднят, учётные данные действительны, а пункт назначения просто никогда не отвечает. Дефект локален для пути пересылки шлюза, а не для сервиса.

Не каждый клиент может быть шлюзом

AWS указывает, что его настольное приложение Client VPN не поддерживает пересылку IP, а другие клиенты могут. Это ограничение определяет архитектуру ещё до того, как набрана любая команда. Если единственный доступный клиент — официальное настольное приложение, шлюз Linux, пересылающий для LAN, — не та конфигурация, которую можно завершить, и никакое количество masquerading этого не изменит.

Заменяющий клиент также должен соответствовать методу аутентификации конечной точки и политике, которую вы собираетесь применять. Конечные точки на основе сертификатов, каталога и SAML не принимают одни и те же конфигурации клиента, а сторонний клиент, который аутентифицируется, но игнорирует протолкнутые маршруты, не является улучшением.

Относитесь к выбору клиента как к части обзора проекта. Он определяет, доступен ли шаблон пересылки LAN вообще, и определяет, какую идентичность конечная точка видит для каждого устройства за шлюзом. Запишите клиент и конфигурацию конечной точки, против которой он тестировался. Замена клиента через полгода может тихо убрать возможность, которую предполагал проект.

Направьте LAN в туннель и транслируйте его

С поддерживаемым клиентом на месте остальное — обычная работа шлюза. Устройствам LAN нужен маршрут для диапазона VPC, указывающий на хост Linux, а хосту нужна включённая пересылка. Если вы хотите, чтобы VPC видел трафик как подключённого клиента, а не как произвольный адрес LAN, транслируйте источник на выходе.

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

Ограничьте правило интерфейсом туннеля и диапазоном VPC, как выше, вместо того чтобы маскировать всё, что пересылает хост. Более узкое правило легче осмыслить, и оно не меняет тихо трафик, который должен был сохранить свой исходный адрес источника.

Сделайте так, чтобы маршрут LAN приходил автоматически, если можете: параметр DHCP, объявление маршрутизатора или статический маршрут, проталкиваемый тем, что управляет LAN. Маршрут, существующий только на одной тестовой машине, заставит проект выглядеть сломанным в тот момент, когда кто-то другой его попробует.

Ответу тоже нужен путь

Как только запрос достигает VPC, ответ должен вернуться через те же состояния трансляции и найти маршрут LAN на шлюзе. Эта часть обычно работает, когда правило masquerade на месте, потому что сопоставление живёт на хосте, который его выполнил. Оно ломается, когда на стороне VPC есть маршрут, отправляющий ответ в другое место, и поэтому важны и маршрут CIDR клиента, и привязка подсети на конечной точке.

Смотрите на счётчики, а не только на ping. Правило masquerade с нулём пакетов говорит вам, что запрос так и не дошёл до интерфейса туннеля, что указывает обратно на маршрут LAN или на собственную таблицу маршрутизации клиента. Правило с пакетами, но без ответов указывает на сторону VPC, правила авторизации или группу безопасности, которая не принимает транслированный источник. Читайте оба направления, прежде чем что-то менять, потому что число, растущее только с одной стороны, — это односторонний путь, а не медленный.

Помните, что конечная точка — управляемый сервис. Нет файла конфигурации сервера для редактирования и нет директивы client-config для добавления, поэтому инструкции, написанные для самостоятельно управляемого сервера OpenVPN с собственными маршрутами клиентских подсетей, не переносятся. В AWS рычаги — это привязка подсети, правила авторизации и таблицы маршрутизации VPC.

Общая идентичность — та часть, на которую должна ответить политика

Каждое устройство за шлюзом использует VPN-сессию шлюза. Правила авторизации конечной точки дают доступ пользователю или группе, и с точки зрения сервиса в этой сессии ровно один пользователь. Локальная пересылка не умножает эту идентичность в аутентификацию для каждого устройства и не распространяет проверки состояния устройств на принтер в углу.

Это может быть приемлемо, а может быть причиной, по которой проект отклоняют. Это зависит от того, что ресурсы VPC предполагают о том, кто звонит. Общая идентичность, вписывающаяся в модель авторизации, — это нормально; та, что тихо превращает одну аутентифицированную сессию в доступ ко всему LAN, — находка, ждущая, когда её запишут.

Если требование действительно в том, чтобы подключить целый сайт к VPC, сравните поддерживаемый проект «сайт-сайт», прежде чем расширять клиент удалённого доступа. Семантика различается, и сессия клиента с NAT — плохая замена каналу сайта, когда VPC должен инициировать соединения в LAN.

Решите клиента, маршрут, трансляцию и историю идентичности именно в таком порядке. Каждый ограничивает следующий, и порядок объясняет, почему хост работает, а LAN — нет.