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