Уваход праз OpenConnect трапляе не на тую старонку? Спачатку праверце шлях
Поўны адрас VPN змяшчае шлях, які вызначае пункт уваходу ў сістэму. Трымайце яго асобна ад групы формы і праверце перанакіраванне, перш чым правіць профіль.
Вы ўстаўляеце адрас з ліста пра наладку, кліент дасягае шлюза, і форма ўваходу, якая з’яўляецца, — гэта агульны партал, а не партнёрскі, пра які казаў аператар. Нішто не выдае памылку, і менавіта гэта блытае: тунель можа нават узняцца, проста за няправільным пунктам уваходу. Шлях у гэтым 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, адхіленага выбару і тунеля, які ўзняўся без патрэбных маршрутаў.