OpenConnect кіру қукиін туннельге қалай айналдырады?

OpenConnect екі бөлек айырбасты бір қысқа мерзімді мәнмен байланыстырады: веб кіру мен VPN туннелін. Бірінші айырбас — қарапайым HTTPS: тіркелгі деректері, SAML айналымы немесе токен қақпаға барады, ал жауап аутентификация қукиін әкеледі. Екінші айырбас сол қукиді сол қақпаға веб кезеңі әлдеқашан болғанының дәлелі ретінде ұсынады, тек содан кейін туннель көтеріледі.

Кіру кезінде туннель туралы ештеңе келісілмейді. Міне, түсінуге тұрарлық нәрсе осы, өйткені скрипт қателерінің көбі қукиді сақталатын құпиясөз немесе трафикті қорғайтын кілт деп есептейді, ал шын мәнінде ол нақты қақпа сессиясына арналған тасымалдаушы билет.

Клиент пен қақпа кезекпен нені айырбастайды

Аутентификация кезеңі қарапайым қорғалған веб-сайтқа ұқсайды. OpenConnect пайдаланушының тіркелгі деректерін жібереді немесе қақпаның идентификация провайдеріне бағыттауын ұстанады, ал қақпа аутентификация қукиін кірістірген құжатпен жауап береді. AnyConnect протоколында бұл мән келесі сұраныстарда қуки тақырыбында жүреді, әдетте webvpn тәрізді атпен, және нұсқаулық оны сессияны алға апаратын тіркелгі дерегі деп қарастырады.

Екінші кезең — қақпаның VPN соңғы нүктесіне сол қуки тіркелген CONNECT сұранысы. Қақпа оны тексереді, мекенжай береді, ал клиент TLS үстінде CSTP бастайды, сессия пайда болғаннан кейін DTLS қосымша жылдамырақ деректер жолы болады. Туннель параметрлері, маршруттар, DNS баптаулары және сессияның трафик кілттері дәл осы сәтте ғана орнатылады. Қуки клиентті есіктен өткізді; ол ештеңені шифрламады.

Осы реттілік openconnect --authenticate не үшін бар екенін түсіндіреді. Оны іске қосыңыз, ол веб кезеңін орындайды, COOKIE, HOST, CONNECT_URL және FINGERPRINT тәрізді shell айнымалыларының шағын блогын шығарады да, кез келген туннель салынбай тұрып шығады. Содан кейін қаптама скрипт осы мәндермен нақты қосылымды бастай алады, және бұл дәл бассыз немесе екі контейнерлі орналастыруға қажет бөлініс.

Қуки — сессия тасымалдаушысы, кілт емес

Мәнді веб-қолданбадағы сессия идентификаторындай ұстаңыз. Оны өмір бойы ұстаған адам қақпадан сол сессияға тиесілі туннельді сұрай алады, сондықтан оның құпиялығы маңызды. Бірақ көшіру трафикті ашпайды, өйткені туннельдің құпиялығы TLS қол алысуы мен туынды кілттерден келеді, қуки жолынан емес.

Бұл тұрақты рұқсат та емес. Сессияның қанша өмір сүретінін қақпа мен идентификация провайдері шешеді, ал әлі кірген бетті көрсетіп тұрған браузер туннель сессиясының әлі жарамды екенін білдірмейді. Мерзімі біткеннен кейін қайта қосылу веб кезеңін қайталап, жаңа қуки жасауды білдіреді, және қайта аутентификацияның мәні дәл осы, инженериямен айналып өтетін кедергі емес.

Қукиді басқа тіркелгі деректерінің әмбебап алмастырғышы деп санамаңыз. SAML тұжырымы, браузер құпиясөзі және басқа қызмет шығарған қуки — әртүрлі аудиториясы бар әртүрлі нысандар, ал біреуін екіншісінің өрісіне қою әдетте қақпада сәтсіз аяқталады немесе, одан жаман, қате сенім шекарасына қарсы сәтті болады.

Қукиді көшірме қалдырмай беру

Linux-те ең қауіпсіз механикалық беру — стандартты кіріс. --cookie-on-stdin мәнді stdin-нан оқиды, сондықтан қуки процестің аргумент тізімінде ешқашан көрінбейді, онда кез келген жергілікті пайдаланушы оны ps арқылы оқи алады. Бір процесте аутентификация жасап, екіншісінде туннельді қоректендіретін құбыр мәнді файлда немесе орта айнымалысында емес, құбырда ұстайды.

Аргументтер мен орта айнымалылары әртүрлі себептермен әлсіз. Аргумент клиенттің бүкіл өмірінде процестер кестесінде көрінеді және жиі shell тарихына түседі. Орта айнымалысы бала процестерге мұраға беріледі, ал оны бірлік файлында орнататын systemd бірлігі құпияны оқуға болатын конфигурацияда сақтайды. Егер файл міндетті болса, оны қызмет тіркелгісімен шектеп, сессия біткенде жойыңыз.

Артықшылық шекарасын да әдейі ұстаңыз. Идентификация провайдерімен сөйлесетін және мүмкін браузер ашатын процесс сол кіруге ие пайдаланушы ретінде жүруі керек. Маршруттарды, DNS-ті және туннель құрылғысын баптайтын процеске көбірек артықшылық қажет болуы мүмкін. root иелігіндегі туннельге қуки жеткізу үшін бүкіл браузерді root ретінде жүргізу — қате айырбас, ал заманауи OpenConnect баптаулары мәнді осы шекарадан анық бере алады.

Журналдау да сол күмәнге лайық. Егжей-тегжейлі клиент шығысы, көмекші скрипттер және қақпа диагностикасы сұраныс материалын қайталай алады, ал әрбір журнал деңгейі қукиді жасыра бермейді. Өзіңізге қажет ең кіші қате жазбасын ұстаңыз, оны ортақ арналардан тыс ұстаңыз және билетке тіркемес бұрын жасырылған үлгіні тексеріңіз.

Екінші кезеңдегі тексеру және мерзімнің бітуі

Екінші кезең серверді әлі де тексеруі керек. --authenticate басатын FINGERPRINT — pin-sha256: пішіміндегі сертификат бекітуі, ал оны --servercert арқылы туннель шақыруына беру тексеруді сіз аутентификацияланған қақпаға бекітіп ұстайды. Скриптті жеңілдету үшін сертификат тексеруін өшіру қукидің арналған хостқа беріліп жатқанының жалғыз дәлелін жояды.

Қақпа қукиді қабылдамаса, шешім — жаңа аутентификация раунды, ұзағырақ кэш емес. Қукиді тек қосылым өміріне сақтаңыз, шығу кезінде уақытша файлдарды жойыңыз және сессия ашылғанда немесе құрылғы жоғалғанда идентификация провайдерінің немесе қақпаның сессияны жою процесін қолданыңыз. Кэштелген қуки MFA-дан босату емес.

Мұны автоматтандырмас бұрын төрт нәрсені тексеріңіз: туннель дұрыс тіркелгімен жүреді, қуки stdin арқылы келеді, сертификат саусақ ізі бекітілген және туннель жабылғанда сессия тасталады. Осылардың біреуі жетпесе, автоматтандыру қолмен жасалатын ағымды қайталаудың орнына қукиге деген сенімді кеңейтті.