Профилот заклучен на серверот не успева зад 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.
• Тестирајте новоиздаден профил против вродената крајна точка со непроменета политика.