Вхід OpenConnect потрапляє не на ту сторінку? Спершу перевірте шлях

Ви вставляєте адресу з листа про підключення, клієнт досягає шлюзу, і форма входу, що з’являється, — це загальний портал, а не партнерський, який описав оператор. Ніщо не повідомляє про помилку, і саме це збиває з пантелику: тунель може навіть піднятися, але за неправильною точкою входу. Шлях у цій адресі виконував роботу, і що б його не замінило, воно цю роботу втратило.

Розділіть дві речі, які приходять у заявці одним рядком: адресу, що досягає сервісу, і введення, яке вирішує, де починається автентифікація. Виправити перше, ігноруючи друге, — це спосіб, у який правильне ім’я хоста все одно дає неправильний вхід.

Що клієнт надсилає до того, як ви побачите форму

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

Тому робоча вкладка браузера й клієнтський профіль, що падає, можуть називати той самий шлюз і все одно розходитися. Браузер ішов шляхом; у профілі його ніколи не було.

Два введення, які виглядають взаємозамінними і не є такими

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

Сервісу може законно бути потрібне й те, й інше. Шлях може привести вас на потрібний портал, поки форма все ще просить вибрати групу всередині нього. Якщо дати назву порталу як назву групи або навпаки, вийде вхід, який виглядає прийнятим, а потім не авторизує, бо значення було синтаксично правильним і семантично хибним.

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

Чому обрізання шляху змінює результат

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

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

Адреси браузера несуть і більше, ніж шляхи. Ідентифікатори сеансу, цілі перенаправлення, мовні префікси та тимчасові параметри входу з’являються в адресному рядку, і жоден із них не має бути в збереженому профілі клієнта.

Підтвердьте точку входу, перш ніж редагувати будь-що інше

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

Потім відтворіть ту саму точку входу в затвердженому клієнті, наприклад openconnect --usergroup=partners vpn.example.net, і подивіться, яка форма з’явиться. Якщо форма правильна, а тунель усе одно не працює, шлях ніколи не був проблемою, і наступна зупинка — політика або маршрутизація.

Запишіть ім’я хоста, порт, протокол, шлях входу та вибір у формі як п’ять окремих полів у заявці. Саме цей список дає змогу наступному інженеру відрізнити недоступний сервер від відмови TLS, відхиленого вибору та тунелю, що піднявся без потрібних маршрутів.