Профіль, прывязаны да сервера, не працуе за праксі 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.
• Праверце свежавыдадзены профіль супраць натыўнай канчатковай кропкі з нязменнай палітыкай.