Полный туннель Access Server на EC2: почему одного флажка недостаточно

Отключение проверки источника и назначения на экземпляре EC2 — самый повторяемый ответ на вопросы о выходе Access Server в интернет, и сам по себе он ничего не делает для ваших клиентов. Проверка — это ограничение пересылки в AWS: она позволяет экземпляру принимать пакеты, источник или назначение которых не является его собственным адресом. Она не говорит клиенту Access Server отправлять интернет-трафик через туннель, не создаёт маршрут вверх и не добавляет NAT. Миф в том, что флажок и есть функция.

Что на самом деле контролирует проверка

Каждый сетевой интерфейс EC2 отбрасывает трафик, который ему не адресован, если только экземпляр не работает как маршрутизатор, устройство NAT или VPN-шлюз и вы не отключите эту проверку. Отключение даёт разрешение на пересылку. Разрешение — не конфигурация: экземпляру по-прежнему нужен маршрут к интернет-шлюзу или устройству NAT, таблице маршрутов VPC по-прежнему нужна соответствующая запись, группы безопасности должны разрешать поток, а сервер должен транслировать или маршрутизировать обратный трафик.

Проверьте текущее значение с помощью aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck, прежде чем что-либо менять. Если вы меняете его в консоли, меняйте потому, что экземпляр пересылает за других, а не потому, что клиент не может попасть в интернет.

Политикой маршрутизации клиента владеет Access Server

В Access Server 3 откройте Access Controls и найдите раздел Internet Access and DNS. Выбор Internet Gateway предлагает полный или разделённый туннель; полный туннель велит клиенту направлять трафик по умолчанию в VPN, разделённый оставляет интернет-трафик на локальном пути клиента. Сохраните и примените через рабочий процесс продукта, затем переподключите тестового клиента, потому что политика доставляется в момент подключения.

Старые выпуски используют другие меню, а некоторые сборки Community OpenVPN не имеют эквивалентного управления. Проверьте установленную основную версию, прежде чем искать экран, которого нет. Затем убедитесь, что получил клиент: профиль полного туннеля должен установить маршрут по умолчанию через туннель, а профиль разделённого туннеля не должен.

Проследите пакет после туннеля

Как только клиент отправляет интернет-трафик в туннель, сервер должен его переслать и обычно транслировать. Access Server управляет собственными правилами NAT и маршрутизации, поэтому читайте фактическую конфигурацию, а не добавляйте правила Community OpenVPN в сгенерированные файлы; неуправляемые правила перезаписываются или конфликтуют при следующем обновлении продукта. sudo iptables -t nat -L -n -v или эквивалент nftables показывает, что действительно транслируется.

Сторона AWS — отдельный путь. Экземпляр в публичной подсети достигает интернет-шлюза напрямую и сохраняет свой публичный адрес или эластичный IP. Экземпляру в частной подсети нужен маршрут к NAT-шлюзу или NAT-экземпляру, а устройству NAT нужен собственный маршрут к интернет-шлюзу. Подключение интернет-шлюза к VPC само по себе не даёт ни одному частному источнику публичного обратного адреса, поэтому одна и та же настройка Access Server работает в одной подсети и молча отказывает в другой.

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

Держите выход IP и DNS раздельно

Сначала проверьте литерал адреса, затем имя, из одного и того же клиентского приложения. Если curl -4 https://checkip.amazonaws.com возвращает публичный адрес, но имена хостов не разрешаются, туннель и путь NAT работают, а проблема в DNS: отправленный резолвер, состояние резолвера клиента или группа безопасности, блокирующая резолвер. Настройки DNS Access Server находятся в той же области Internet Access, но идут другим путём в коде.

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

Не позволяйте одному флажку закрыть расследование

IPv6 — отдельное решение. Политика полного туннеля для IPv4 ничего не говорит о том, передаётся ли IPv6, блокируется или утекает, и клиент с двумя стеками может продолжать использовать локальный путь IPv6, пока IPv4 идёт через туннель. Проверьте то семейство адресов, которое вам действительно важно, и явно решите, нужно ли отключать другое.

Наконец, проверьте отключённое состояние. Выбор полного туннеля описывает политику маршрутизации при подключении, а не то, что происходит при падении туннеля. Если требование в том, чтобы никакой трафик не утекал за пределы VPN, это вопрос kill-switch и межсетевого экрана, и он требует собственной проверки, а не вывода из таблицы маршрутов.