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