Serverlåst profil fejler bag en TLS-proxy: hvilken generation?

Én bruger kan forbinde, og en anden kan ikke, gennem samme portal, samme dag. Begge har serverlåste profiler, begge er på samme Access Server-build, og den eneste forskel er, hvornår deres profil blev genereret. Det er mønstret værd at genkende, fordi "serverlåst" navngiver en politik og ikke en forbindelsesrækkefølge. Access Server har udsendt to generationer af det artefakt, og en TLS-reverse-proxy står kun foran en af deres veje. Tre betingelser afgør, hvilken gren du er på.

To generationer, to forbindelsesrækkefølger

I det ældre design, gældende til og med 2.8, er den importerede fil en pseudoprofil. OpenVPN Connect bruger den til at godkende sig over for Access Servers web-API over HTTPS, modtager en midlertidig brugerlåst profil og et sessionstoken, og etablerer først derefter VPN. To transporter kører i rækkefølge, og den første er en almindelig webforespørgsel.

Formatet, der blev indført med 2.9, udfører ikke den bootstrap pr. forbindelse. Det er en indbygget profil, der kan bruges af kompatible OpenVPN klienter, ikke kun af OpenVPN Connect. Download eller import via URL kan stadig involvere HTTPS — det er et publiceringstrin, ikke en hentning af en midlertidig profil pr. forbindelse.

En opgradering omskriver ikke nødvendigvis profiler, der allerede er udstedt, så en aktuel serverversion kan stadig udlevere det gamle artefakt. Server-builden fortæller dig, hvad der er muligt, ikke hvad denne bruger importerede.

Tre betingelser, der vælger din gren

Den første betingelse er artefaktets generation. Bed om filen, se hvordan den blev produceret, og noter den klientversion, der importerede den. Hvis du ikke kan fastslå generationen ud fra filen, vil en ny profil udstedt til en testkonto fortælle dig, hvad serveren producerer i dag, hvilket er en anden information end den, den fejlende bruger har.

Den anden er, hvad din frontend faktisk terminerer. En HTTP-reverse-proxy på lag syv, der aflaster TLS, er ikke det samme objekt som en TCP-videresender på lag fire, og en UDP-videresender er det heller ikke. Access Servers sædvanlige opsætning på port 443 får OpenVPN TCP-dæmonen til at genkende browsertrafik og give den videre til webtjenesterne, så indsættelse af en uvedkommende HTTPS-terminator foran bevarer ikke den dæmons protokolhåndtering. At dele nummeret 443 gør ikke to design ækvivalente.

Den tredje er, hvor fejlen lander. En fejl før VPN og en fejl i kontrolkanalen ser ens ud i en klient, der kun siger "forbinder", men de efterlader beviser forskellige steder. Hvis det gamle format er i spil, er bootstrap en kandidat. Hvis det nye format er i spil, er en tom webadgangslog forventet og beviser intet i nogen retning.

Når artefaktet er gammelt: bootstrap fejler først

Læs klientens faktiske fejl i stedet for dens sluttilstand. De interessante felter er HTTPS-fejlen, den serveridentitet klienten forventede, den destination anmodningen gik til, og om certifikatvalideringen blev gennemført. Sammenhold dem derefter med webtjenestens og proxyens logfiler på serversiden.

At en browser når login-siden er ikke bevis på, at denne klients API-godkendelse lykkedes. Det er forskellige anmodninger med forskellige certifikatforventninger og ofte forskellige værtsnavne. Hvis portalen betjenes korrekt, og klienten stadig fejler, ligger uenigheden i bootstrap-vejen, ikke i brugerens adgangskode.

Få ikke sammenligningen til at bestå ved at slå TLS-verifikation fra eller lempe godkendelsespolitikken. Det gør en diagnosticerbar konfigurationsafvigelse til en fungerende, men uverificeret vej, og det er netop den ændring, der gør en midlertidig test til et permanent hul. Access Servers dokumentation om forbindelsesprofiler beskriver begge generationer og forløbet med den midlertidige profil, og det er referencen, der skal tjekkes, før du antager, at en proxy er skylden.

Når artefaktet er nyt: læs kontrolkanalen i stedet

Med en profil i 2.9-stil går klienten direkte til det indbyggede VPN-endepunkt. Undersøg endepunkterne i profilen, den anvendte transport og kontrolkanalens fejl. Hvis klienten aldrig udsender en HTTP-anmodning, er det i overensstemmelse med designet og ikke et symptom.

Det er også her, proxy-spørgsmålet skifter form. En HTTPS-aflastning kan ikke bryde en TCP-only strøm, den aldrig ser, men den kan stadig bryde det download, der publicerer profilen, og en TCP-only videresender vil slet ikke bære UDP. Tjek, hvilken transport profilen beder om, før du konkluderer, at frontenden er irrelevant.

TLS-gennemførsel for en enkelt strøm er en snæver opsætning. Den giver ikke UDP-videresendelse og genskaber ikke dæmonens egen videresendelse af tjenester på 443. Hvis din frontend gør en af disse ting, sig hvilken, fordi afhjælpningen er forskellig.

Afhjælpninger, der forbliver snævre

Den mindst indgribende kontrol er at generere en ny understøttet profil til en testkonto og forbinde gennem det tilsigtede indbyggede endepunkt med de samme godkendelseskrav. Hvis det virker, og den bevarede gamle profil ikke gør, har du adskilt artefaktet fra serveren og fra proxyen i ét trin.

Distribution af en brugerlåst profil fjerner den ældre bootstrap-afhængighed helt, fordi der ikke er nogen udveksling af midlertidig profil, der kan fejle. Den skal udstedes til den tilsigtede bruger, aldrig kopieres fra en administrator, og den ændrer, hvad klienten er autoriseret til, så behandl det som en politisk beslutning og ikke som en omgåelse.

Ret derefter publiceringsopsætningen, så hver påkrævet vej findes: webvejen til downloads og portalbrug og den indbyggede VPN-vej på den transport, profilerne forventer. Hold proxyens arbejde på ét lag. En fungerende brugerlåst tunnel beviser, at den vej virker; den beviser ikke, at enhver proxyopsætning understøtter enhver generation, og en gammel bootstrap-fejl fordømmer ikke det nyere format.

• Fastslå artefaktets generation, før du rører proxyen.
• Fastslå, om fejlen sker før tunnelen eller inde i den.
• Bekræft, hvad frontenden terminerer: HTTP, TCP-strøm eller UDP.
• Test en nyudstedt profil mod det indbyggede endepunkt med uændret politik.