DNS конечной точки AWS Client VPN: почему закрепление разрешённого IP не работает

На прошлой неделе dig +short выдал один адрес для имени конечной точки в вашем профиле AWS Client VPN, и туннель подключился. На этой неделе тот же профиль стоит на 'Connecting' на вашем ноутбуке, хотя нетронутая копия коллеги всё ещё работает. Ничего не блокировали, и сертификат не истёк. Кто-то заменил имя хоста конечной точки этим разрешённым адресом, и сервис там больше не отвечает. Экспортированное имя — это часть, построенная так, чтобы пережить это изменение.

Имя в вашем профиле может быть не тем именем, которое запрашивается

Профили, экспортированные из Client VPN, обычно содержат remote-random-hostname. Когда эта опция включена, клиент создаёт одноразовую метку, присоединяет её к имени конечной точки через точку и разрешает составное имя. Запись wildcard в зоне конечной точки отвечает на любую метку, поэтому выдуманный префикс тоже разрешается и поэтому трюк остаётся незаметным, когда вы пытаетесь воспроизвести запрос вручную.

Поэтому, когда вы вставляете имя конечной точки в терминал и получаете ответ, вы разрешили другое имя, чем то, которое клиент использует при подключении. Это несоответствие не является дефектом, который нужно исправлять в профиле. Метка создаётся заново намеренно: опция не даёт кешам хранить устаревший ответ и никогда не идентифицирует вашу машину или сеанс.

Мне встречался случай совместимости, когда клиент полностью игнорирует опцию. AWS документирует обход: сохраните настоящее имя конечной точки и добавьте впереди случайную строку плюс точку, рассматривая это как схему именования, а не как значение для вставки. Применить это к старому клиенту разумно; жёстко закреплять строку с префиксом как конечную точку — нет.

Почему сохранённый ответ не может оставаться правильным

Адресами конечных точек Client VPN управляет AWS, и они меняются со временем, о чём документация по лучшим практикам говорит прямо. Захваченный ответ — это снимок одного разрешения. Профиль, который закрепляет его, становится профилем, нацеленным на выведенный из эксплуатации хост, как только сервис переедет, а сбой редко выглядит как DNS: вы получаете тайм-аут подключения или зависший handshake, поэтому люди гоняются за маршрутизацией и сертификатами.

Тот же ответ в /etc/hosts наследует тот же срок с дополнительной проблемой. Запись hosts переживает перезагрузки, повторные экспорты и исправления 'переустановите клиент', поэтому сбой возвращается каждый раз, когда адрес перемещается. Я видел, как одна неделями лежала безвредно, а потом вывела из строя каждую машину, которая её несла, тогда как свежие установки подключались нормально. Это разделение, одна группа сбоит, а другая в порядке на одном и том же аккаунте, — самая дешёвая подсказка, которую вы получите.

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

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

Client VPN требует, чтобы адрес, к которому вы подключены, совпадал с адресом, разрешённым для DNS-имени конечной точки. Это одно требование объясняет несколько сбоев, которые выглядят несвязанными: пользовательская запись DNS, указывающая в другое место, пользовательский frontend, перенаправляющий на настоящий адрес конечной точки, и профиль, переписанный на сырой адрес. AWS документирует схему 'пользовательская запись плюс перенаправление' как сбой с новыми клиентами от AWS. Проверка узкая; это не приговор, что любой псевдоним запрещён.

Это и не общее правило о протоколах VPN. Числовой remote вполне допустим в обычном развёртывании OpenVPN, и многие так работают. Ограничение идёт от управляемой схемы, а не от протокола под ней.

Что делает ослабление проверки сертификатов неправильным рефлексом. Если профиль сбоит после смены адреса, отключение проверки сервера переносит ошибку вместо исправления разрешения или требования совпадения адреса и оставляет клиент, который будет доверять чему угодно. Сохраняйте экспортированный CA, проверку сервера и настройки взаимной аутентификации точно такими, какими они пришли.

Списки разрешений, исходящий трафик и частный DNS — три отдельные проблемы

Правило межсетевого экрана, которое должно разрешить назначение до подключения ноутбука, касается внешнего слушателя. Дайте владельцу сети имя конечной точки, транспорт и настроенный порт, а затем спросите, может ли их контроль следовать поведению DNS сервиса. Правило, удерживающее один захваченный адрес, — это снимок с невыписанным сроком. Если контроль принимает только неизменные назначения, закройте этот пробел до развёртывания, а не закрепляйте ответ молча.

Партнёру, которому нужен фиксированный адрес источника для запросов после поднятия туннеля, нужно другое: исходящий трафик. То, что видит сайт, зависит от маршрута приложения и политики раздельного туннеля, а не от адреса, к которому подключился клиент. Трафик раздельного туннеля может вообще не касаться AWS.

Частный DNS внутри туннеля — третий слой. Резолвер, выдаваемый клиентам, отвечает на внутренние имена после подключения; он не может разрешить публичную конечную точку до появления туннеля. Сбой разрешения конечной точки и сбой разрешения внутреннего приложения происходят на разных этапах, и их смешение отправляет вас не в тот журнал.

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

Проверьте соединение, ничего не закрепляя

Начните с профиля в том виде, в каком он экспортирован, и прочитайте, что он на самом деле требует:

grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'

Затем сравните три вещи: имя конечной точки, которое держит профиль, адрес, который клиент сообщает для новой попытки, и то, во что имя разрешается прямо сейчас. Имя, которое разрешается, доказывает только то, что запись отвечает; транспорт и аутентификация отдельны, и конечная точка не обязана отвечать на ping. Собственный журнал клиента — единственный источник для среднего пункта, поэтому зафиксируйте его во время попытки, а не после.

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

Две привычки, от которых стоит отказаться: отключать проверки сертификатов, чтобы пройти зависший handshake, и нагромождать метки перед именем конечной точки в надежде, что одна зацепится. Метка разрешается через запись wildcard, либо проблема в другом месте. Если правильно настроенный профиль всё равно сбоит, отправьте точный запрос и событие подключения, а не более длинное имя хоста.

Прежде чем закрыть вопрос: профиль всё ещё несёт экспортированное имя конечной точки, ни один файл hosts не закрепляет адрес, remote в журнале клиента соответствует текущему разрешению, а правило межсетевого экрана называет конечную точку, а не адрес. Это и состояние, которое нужно передать следующему человеку.