Профиль, привязанный к серверу, не работает за прокси TLS: какое поколение?

Один пользователь подключается, а другой нет, через тот же портал, в тот же день. У обоих есть привязанные к серверу профили, оба на одной и той же сборке Access Server, и единственное различие — когда был создан их профиль. Это тот шаблон, который стоит распознавать, потому что "привязанный к серверу" называет политику, а не последовательность подключения. Access Server выпустил два поколения этого артефакта, и обратный прокси TLS стоит перед одним из их путей. Три условия определяют, на какой ветке вы находитесь.

Два поколения, две последовательности подключения

В старой схеме, действующей до 2.8, импортированный файл является псевдопрофилем. OpenVPN Connect использует его для аутентификации в веб-API Access Server по HTTPS, получает временный профиль, привязанный к пользователю, и токен сессии, и только после этого устанавливает VPN. Два транспорта работают последовательно, и первый из них — обычный веб-запрос.

Формат, введённый с 2.9, не выполняет эту начальную загрузку при каждом подключении. Это нативный профиль, который могут использовать совместимые OpenVPN клиенты, а не только OpenVPN Connect. Его загрузка или импорт по URL всё ещё может включать HTTPS — это шаг публикации, а не получение временного профиля при каждом подключении.

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

Три условия, которые выбирают вашу ветку

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

Второе — что ваш фронтенд действительно завершает. Обратный HTTP-прокси седьмого уровня, который снимает TLS, — не тот же объект, что переадресующий TCP четвёртого уровня, и переадресующий UDP тоже. Обычная схема Access Server на порту 443 заставляет демон OpenVPN TCP распознавать трафик браузера и передавать его веб-сервисам, поэтому вставка постороннего терминатора HTTPS спереди не сохраняет обработку протокола этим демоном. Общий номер 443 не делает две схемы эквивалентными.

Третье — где происходит сбой. Сбой до VPN и сбой канала управления выглядят похоже в клиенте, который говорит только "подключение", но оставляют следы в разных местах. Если задействован старый формат, начальная загрузка — кандидат. Если задействован новый формат, пустой журнал веб-доступа ожидаем и ничего не доказывает ни в одну сторону.

Когда артефакт старый: начальная загрузка сбоит первой

Читайте фактическую ошибку клиента, а не его конечное состояние. Интересны поля ошибки HTTPS, идентичности сервера, которую клиент ожидал, назначения, куда ушёл запрос, и того, завершилась ли проверка сертификата. Затем сопоставьте их с журналами веб-сервиса и прокси на стороне сервера.

То, что браузер доходит до страницы входа, не доказывает, что аутентификация API этого клиента прошла успешно. Это разные запросы, с разными ожиданиями по сертификату и часто разными именами хостов. Если портал обслуживается правильно, а клиент всё ещё сбоит, расхождение в пути начальной загрузки, а не в пароле пользователя.

Не заставляйте сравнение пройти, отключая проверку TLS или ослабляя политику аутентификации. Это превращает диагностируемое несоответствие конфигурации в рабочий, но непроверенный путь, и именно это изменение превращает временный тест в постоянную дыру. Документация Access Server о профилях подключения описывает оба поколения и поток временного профиля, и это справочник, который нужно проверить, прежде чем предполагать вину прокси.

Когда артефакт новый: читайте канал управления

С профилем в стиле 2.9 клиент идёт прямо на нативную конечную точку VPN. Исследуйте конечные точки в профиле, используемый транспорт и ошибку канала управления. Если клиент никогда не отправляет HTTP-запрос, это соответствует схеме и не является симптомом.

Здесь же вопрос о прокси меняет форму. Снятие HTTPS не может сломать поток только по TCP, который он никогда не видит, но всё ещё может сломать скачивание, публикующее профиль, а переадресующий только TCP вообще не понесёт UDP. Проверьте, какой транспорт требует профиль, прежде чем заключать, что фронтенд не имеет значения.

Пропуск TLS для одного потока — узкая схема. Он не даёт переадресации UDP и не воспроизводит собственное поведение демона при переадресации сервисов на 443. Если ваш фронтенд делает одно из этого, скажите какое, потому что средство исправления другое.

Средства, которые остаются узкими

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

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

Затем исправьте схему публикации так, чтобы существовал каждый требуемый путь: веб-путь для загрузок и использования портала и нативный путь VPN на том транспорте, которого ожидают профили. Держите работу прокси на одном уровне. Работающий туннель, привязанный к пользователю, доказывает, что этот путь работает; он не доказывает, что любая схема прокси поддерживает любое поколение, и старый сбой начальной загрузки не осуждает более новый формат.

• Определите поколение артефакта, прежде чем трогать прокси.
• Установите, происходит ли сбой до туннеля или внутри него.
• Подтвердите, что завершает фронтенд: HTTP, поток TCP или UDP.
• Проверьте свежевыданный профиль против нативной конечной точки при неизменной политике.