Prie serverio pririštas profilis nepavyksta už TLS tarpinio serverio: kuri karta?

Vienas vartotojas gali prisijungti, o kitas ne, per tą patį portalą, tą pačią dieną. Abu turi prie serverio pririštus profilius, abu yra toje pačioje Access Server versijoje, ir vienintelis skirtumas yra tai, kada jų profilis buvo sukurtas. Tai yra šablonas, kurį verta atpažinti, nes "prie serverio pririštas" įvardija politiką, o ne prisijungimo seką. Access Server išleido dvi to artefakto kartas, o TLS atvirkštinis tarpinis serveris stovi prieš tik vieną jų kelių. Tris sąlygos nulemia, kurioje šakoje esate.

Dvi kartos, dvi prisijungimo sekos

Senesniame dizaine, galiojančiame iki 2.8, importuotas failas yra pseudo profilis. OpenVPN Connect naudoja jį autentifikacijai prie Access Server žiniatinklio API per HTTPS, gauna laikiną prie vartotojo pririštą profilį ir sesijos raktą, ir tik tada nustato VPN. Du transportai veikia iš eilės, o pirmasis yra įprasta žiniatinklio užklausa.

Formatas, pristatytas su 2.9, neatlieka to pasiruošimo kiekvienam prisijungimui. Tai vietinis profilis, kurį gali naudoti suderinami OpenVPN klientai, ne tik OpenVPN Connect. Atsisiųsti jį ar importuoti per URL vis dar gali reikšti HTTPS — tai publikavimo žingsnis, o ne laikino profilio gavimas kiekvienam prisijungimui.

Atnaujinimas nebūtinai perrašo jau išduotus profilius, todėl dabartinė serverio versija vis dar gali platinti seną artefaktą. Serverio versija nurodo, kas įmanoma, o ne ką šis vartotojas importavo.

Tris sąlygos, parenkančios jūsų šaką

Pirmoji sąlyga yra artefakto karta. Paprašykite failo, pažiūrėkite, kaip jis buvo sukurtas, ir užsirašykite jį importavusio kliento versiją. Jei negalite nustatyti kartos iš failo, naujas profilis, išduotas bandomajai paskyrai, parodys, ką serveris gamina šiandien, ir tai yra kita informacija nei ta, kurią turi nepavykstantis vartotojas.

Antroji yra tai, ką jūsų priekinė dalis iš tikrųjų užbaigia. Septinto sluoksnio HTTP atvirkštinis tarpinis serveris, kuris nuima TLS, nėra tas pats objektas kaip ketvirto sluoksnio TCP peradresuotojas, ir UDP peradresuotojas taip pat ne. Įprasta Access Server tvarka 443 prievade priverčia OpenVPN TCP tarnybą atpažinti naršyklės srautą ir perduoti jį žiniatinklio paslaugoms, todėl nesusijusio HTTPS užbaigiklio įterpimas priekyje neišsaugo tos tarnybos protokolo apdorojimo. Bendro skaičiaus 443 dalijimasis nepadaro dviejų dizainų lygiaverčių.

Trečioji yra tai, kur patenka gedimas. Gedimas prieš VPN ir valdymo kanalo gedimas atrodo panašiai kliente, kuris sako tik "jungiamasi", tačiau jie palieka įrodymus skirtingose vietose. Jei naudojamas senas formatas, pasiruošimas yra kandidatas. Jei naudojamas naujas formatas, tuščias žiniatinklio prieigos žurnalas yra tikėtinas ir nieko neįrodo nė viena kryptimi.

Kai artefaktas senas: pasiruošimas nepavyksta pirmas

Skaitykite tikrąją kliento klaidą, o ne jo galutinę būseną. Įdomūs laukai yra HTTPS klaida, serverio tapatybė, kurios klientas tikėjosi, paskirties vieta, į kurią nuėjo užklausa, ir ar sertifikato tikrinimas buvo baigtas. Tada palyginkite juos su serverio pusės žiniatinklio paslaugos ir tarpinio serverio žurnalais.

Tai, kad naršyklė pasiekia prisijungimo puslapį, neįrodo, kad šio kliento API autentifikacija pavyko. Tai skirtingos užklausos, su skirtingais sertifikato lūkesčiais ir dažnai skirtingais pagrindinio kompiuterio vardais. Jei portalas aptarnaujamas teisingai, o klientas vis tiek nepavyksta, nesutarimas yra pasiruošimo kelyje, o ne vartotojo slaptažodyje.

Nepriverskite palyginimo pavykti išjungdami TLS tikrinimą ar sušvelnindami autentifikacijos politiką. Tai diagnozuojamą konfigūracijos neatitikimą paverčia veikiančiu, bet nepatikrintu keliu, ir būtent tas pakeitimas laikiną testą paverčia nuolatine skyle. Access Server prisijungimo profilių dokumentacija aprašo abi kartas ir laikino profilio eigą, ir tai yra nuoroda, kurią reikia patikrinti prieš darant prielaidą, kad kaltas tarpinis serveris.

Kai artefaktas naujas: skaitykite valdymo kanalą

Su 2.9 stiliaus profiliu klientas eina tiesiai į vietinį VPN galinį tašką. Išnagrinėkite profilio galinius taškus, naudojamą transportą ir valdymo kanalo klaidą. Jei klientas niekada nesiunčia HTTP užklausos, tai atitinka dizainą ir nėra simptomas.

Čia taip pat keičiasi tarpinio serverio klausimo forma. HTTPS nuėmimas negali sulaužyti tik TCP srauto, kurio niekada nemato, bet vis dar gali sulaužyti atsisiuntimą, kuris publikuoja profilį, o tik TCP peradresuotojas visai negabens UDP. Patikrinkite, kokio transporto reikalauja profilis, prieš darydami išvadą, kad priekinė dalis nesvarbi.

TLS pralaidumas vienam srautui yra siaura tvarka. Jis neteikia UDP peradresavimo ir neatkuria pačios tarnybos paslaugų peradresavimo elgsenos 443 prievade. Jei jūsų priekinė dalis daro vieną iš šių dalykų, pasakykite kuri, nes sprendimas skiriasi.

Sprendimai, kurie išlieka siauri

Mažiausiai invazyvus patikrinimas yra sukurti naują palaikomą profilį bandomajai paskyrai ir prisijungti per numatytą vietinį galinį tašką su tais pačiais autentifikacijos reikalavimais. Jei tai veikia, o išsaugotas senas profilis ne, vienu žingsniu atskyrėte artefaktą nuo serverio ir nuo tarpinio serverio.

Prie vartotojo pririšto profilio platinimas visiškai pašalina paveldėtą pasiruošimo priklausomybę, nes nėra laikino profilio mainų, kurie galėtų nepavykti. Jis turi būti išduotas numatytam vartotojui, niekada nenukopijuotas iš administratoriaus, ir jis keičia, ką klientas turi teisę daryti, todėl traktuokite jį kaip politikos sprendimą, o ne kaip apeinamąjį kelią.

Tada pataisykite publikavimo išdėstymą, kad egzistuotų kiekvienas reikalingas kelias: žiniatinklio kelias atsisiuntimams ir portalo naudojimui, ir vietinis VPN kelias transportu, kurio tikisi profiliai. Laikykite tarpinio serverio darbą viename sluoksnyje. Veikiantis prie vartotojo pririštas tunelis įrodo, kad tas kelias veikia; jis neįrodo, kad kiekviena tarpinio serverio tvarka palaiko kiekvieną kartą, ir senas pasiruošimo gedimas nepasismerkia naujesnio formato.

• Nustatykite artefakto kartą prieš liesdami tarpinį serverį.
• Nustatykite, ar gedimas įvyksta prieš tunelį, ar jo viduje.
• Patvirtinkite, ką užbaigia priekinė dalis: HTTP, TCP srautą ar UDP.
• Išbandykite naujai išduotą profilį prieš vietinį galinį tašką nekeisdami politikos.