Serverlåst profil feilar bak ein TLS-proxy: kva generasjon?

Éin brukar kan kople til og ein annan ikkje, gjennom same portal, same dag. Begge har serverlåste profilar, begge er på same Access Server-bygg, og den einaste skilnaden er når profilen deira vart generert. Det er mønsteret som er verdt å kjenne att, fordi "serverlåst" namngjev ein politikk og ikkje ein tilkoplingssekvens. Access Server har sendt ut to generasjonar av den artefakten, og ein TLS-omvend proxy står føre berre éin av vegane deira. Tre vilkår avgjer kva grein du er på.

To generasjonar, to tilkoplingssekvensar

I det eldre designet, gyldig til og med 2.8, er den importerte fila ein pseudoprofil. OpenVPN Connect brukar han til å autentisere mot web-API-et til Access Server over HTTPS, får ein mellombels brukarlåst profil og eit sesjonstoken, og etablerer først deretter VPN. To transportar køyrer i rekkjefølgje, og den første er ein vanleg web-førespurnad.

Formatet som vart innført med 2.9, utfører ikkje den oppstarten per tilkopling. Det er ein innebygd profil som kan brukast av kompatible OpenVPN klientar, ikkje berre OpenVPN Connect. Nedlasting eller import via URL kan framleis innebere HTTPS — det er eit publiseringstrinn, ikkje henting av ein mellombels profil per tilkopling.

Ei oppgradering skriv ikkje nødvendigvis om profilar som alt er utstedte, så ein gjeldande serverversjon kan framleis dele ut den gamle artefakten. Serverbygget fortel deg kva som er mogleg, ikkje kva denne brukaren importerte.

Tre vilkår som vel greina di

Det første vilkåret er generasjonen til artefakten. Be om fila, sjå korleis ho vart produsert, og noter klientversjonen som importerte ho. Viss du ikkje kan fastslå generasjonen frå fila, vil ein ny profil utstedt til ein testkonto fortelje deg kva serveren produserer i dag, og det er annan informasjon enn den brukaren som feilar har.

Det andre er kva frontenden din faktisk avsluttar. Ein HTTP-omvend proxy på lag sju som avlastar TLS er ikkje same objekt som ein TCP-vidareførar på lag fire, og ein UDP-vidareførar er det heller ikkje. Det vanlege oppsettet til Access Server på port 443 får OpenVPN TCP-demonen til å kjenne att nettlesartrafikk og levere han til webbtenestene, så å setje inn ein uvedkomande HTTPS-terminator føre bevarer ikkje protokollhandteringa til den demonen. Å dele nummeret 443 gjer ikkje to design likeverdige.

Det tredje er kvar feilen landar. Ein feil før VPN og ein feil i kontrollkanalen ser like ut i ein klient som berre seier "koplar til", men dei etterlèt spor på ulike stader. Viss det gamle formatet er i spel, er oppstarten ein kandidat. Viss det nye formatet er i spel, er ein tom web-tilgangslogg venta og beviser ingenting i nokon retning.

Når artefakten er gammal: oppstarten feilar først

Les den faktiske feilen til klienten i staden for sluttilstanden. Dei interessante felta er HTTPS-feilen, serveridentiteten klienten venta, destinasjonen førespurnaden gjekk til, og om sertifikatvalideringa vart fullført. Samanlikn dei deretter med loggane til webbtenesta og proxyen på serversida.

At ein nettlesar når innloggingssida er ikkje bevis for at API-autentiseringa til denne klienten lukkast. Det er ulike førespurnader, med ulike sertifikatforventingar og ofte ulike vertsnamn. Viss portalen vert tent riktig og klienten framleis feilar, ligg usemja i oppstartsvegen, ikkje i passordet til brukaren.

Ikkje få samanlikninga til å lukkast ved å slå av TLS-verifisering eller lempe autentiseringspolitikken. Det gjer eit diagnostiserbart konfigurasjonsavvik om til ein veg som verkar, men ikkje er verifisert, og det er nettopp den endringa som gjer ein mellombels test til eit permanent hol. Access Server-dokumentasjonen om tilkoplingsprofilar skildrar begge generasjonane og flyten for den mellombelse profilen, og det er referansen som må sjekkast før du antar at ein proxy er skulda.

Når artefakten er ny: les kontrollkanalen i staden

Med ein profil i 2.9-stil går klienten rett til det innebygde VPN-endepunktet. Undersøk endepunkta i profilen, transporten som vert brukt, og feilen i kontrollkanalen. Viss klienten aldri sender ein HTTP-førespurnad, er det i tråd med designet og ikkje eit symptom.

Det er òg her proxy-spørsmålet skiftar form. Ei HTTPS-avlasting kan ikkje bryte ein TCP-berre straum som ho aldri ser, men ho kan framleis bryte nedlastinga som publiserer profilen, og ein TCP-berre vidareførar vil ikkje bere UDP i det heile. Sjekk kva transport profilen ber om før du konkluderer med at frontenden er irrelevant.

TLS-gjennomføring for éin enkelt straum er eit smalt oppsett. Det gir ikkje UDP-vidareføring, og det attskapar ikkje den eigen tenestevidareføringa til demonen på 443. Viss frontenden din gjer ein av desse tinga, sei kva ein, fordi botemiddelet er ulikt.

Botemiddel som held seg smale

Den minst inngripande sjekken er å generere ein ny støtta profil for ein testkonto og kople til gjennom det tiltenkte innebygde endepunktet med dei same autentiseringskrava. Viss det verkar og den behaldne gamle profilen ikkje gjer det, har du skilt artefakten frå serveren og frå proxyen i eitt trinn.

Distribusjon av ein brukarlåst profil fjernar den eldre oppstartsavhengigheita heilt, fordi det ikkje finst noka utveksling av mellombels profil som kan feile. Han må utstedast til den tiltenkte brukaren, aldri kopierast frå ein administrator, og han endrar kva klienten er autorisert til, så handsam han som ei politikkgjerd og ikkje som ein omveg.

Deretter rettar du publiseringsoppsettet slik at kvar påkravd veg finst: webvegen for nedlastingar og portalbruk, og den innebygde VPN-vegen på transporten som profilane ventar. Hald arbeidet til proxyen på eitt lag. Ein fungerande brukarlåst tunnel beviser at den vegen verkar; han beviser ikkje at eit kvar som helst proxyoppsett støttar kvar generasjon, og ein gammal oppstartsfeil fordømmer ikkje det nyare formatet.

• Fastslå generasjonen til artefakten før du rører proxyen.
• Fastslå om feilen skjer før tunnelen eller inne i han.
• Stadfest kva frontenden avsluttar: HTTP, TCP-straum eller UDP.
• Test ein nyleg utstedt profil mot det innebygde endepunktet med uendra politikk.