Вход OpenConnect попадает не на ту страницу? Сначала проверьте путь

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

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

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

С адресом вроде https://vpn.example.net/partners первым действием клиента будет HTTPS-запрос именно к этому пути, а не к голому хосту. В ответ обычно приходит перенаправление на точку входа или сама форма. Клиент, которому дали только vpn.example.net, начинает со страницы по умолчанию, какая бы она ни была, а это может быть другой портал, другой список групп или страница, ожидающая совсем другой протокол. Разница видна в заголовках ответа задолго до того, как введены какие-либо учётные данные.

Поэтому работающая вкладка браузера и падающий профиль клиента могут называть один и тот же шлюз и всё равно расходиться. Браузер шёл по пути; в профиле его никогда не было.

Два ввода, которые кажутся взаимозаменяемыми и не являются такими

OpenConnect предоставляет начальный путь HTTPS как --usergroup, а страница руководства рассматривает полный URL с этим путём как тот же запрос, записанный иначе. --authgroup — отдельная опция: она выбирает запись из списка, который шлюз показывает внутри формы входа. Одни протоколы называют эту запись группой, другие доменом или шлюзом, и именно там два флага путаются.

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

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

Почему обрезание пути меняет результат

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

Замена имени хоста на IP-адрес — отдельная ошибка, которая часто путешествует вместе с этой. Выбор сервиса по имени и проверка сертификата оба зависят от имени, поэтому числовой адрес может превратить проблему формата пути в ошибку TLS.

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

Подтвердите точку входа, прежде чем править что-либо ещё

Прочитайте заголовки для пути, который вам дали. Запрос вроде curl -sS -o /dev/null -D - https://vpn.example.net/partners печатает строку состояния и любой заголовок Location, не следуя перенаправлению. 302, указывающий на именованную точку входа, подтверждает, что путь существует, и показывает, куда он ведёт; 404 означает, что адрес оператора устарел.

Затем воспроизведите ту же точку входа в одобренном клиенте, например openconnect --usergroup=partners vpn.example.net, и посмотрите, какая форма появится. Если форма верна, а туннель всё равно не работает, путь никогда не был проблемой, и следующая остановка — политика или маршрутизация.

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