Пријава на 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 одбијања, одбијеног избора и тунела који се подигао без потребних рута.