Serverlåst profil feiler bak en TLS-proxy: hvilken generasjon?

Én bruker kan koble til og en annen ikke, gjennom samme portal, samme dag. Begge har serverlåste profiler, begge er på samme Access Server-bygg, og den eneste forskjellen er når profilen deres ble generert. Det er mønsteret som er verdt å kjenne igjen, fordi "serverlåst" navngir en policy og ikke en tilkoblingssekvens. Access Server har sendt ut to generasjoner av den artefakten, og en TLS-reversproxy står foran bare én av veiene deres. Tre betingelser avgjør hvilken gren du er på.

To generasjoner, to tilkoblingssekvenser

I det eldre designet, gyldig til og med 2.8, er den importerte filen en pseudoprofil. OpenVPN Connect bruker den til å autentisere mot Access Servers web-API over HTTPS, mottar en midlertidig brukerlåst profil og et sesjonstoken, og etablerer først deretter VPN. To transporter kjører i rekkefølge, og den første er en vanlig web-forespørsel.

Formatet som ble innført med 2.9, utfører ikke den oppstarten per tilkobling. Det er en innebygd profil som kan brukes av kompatible OpenVPN klienter, ikke bare OpenVPN Connect. Nedlasting eller import via URL kan fortsatt innebære HTTPS — det er et publiseringstrinn, ikke henting av en midlertidig profil per tilkobling.

En oppgradering skriver ikke nødvendigvis om profiler som allerede er utstedt, så en gjeldende serverversjon kan fortsatt dele ut den gamle artefakten. Serverbygget forteller deg hva som er mulig, ikke hva denne brukeren importerte.

Tre betingelser som velger grenen din

Den første betingelsen er artefaktens generasjon. Be om filen, se hvordan den ble produsert, og noter klientversjonen som importerte den. Hvis du ikke kan fastslå generasjonen fra filen, vil en ny profil utstedt til en testkonto fortelle deg hva serveren produserer i dag, og det er annen informasjon enn den brukeren som feiler har.

Den andre er hva frontenden din faktisk avslutter. En HTTP-reversproxy på lag sju som avlaster TLS er ikke samme objekt som en TCP-videresender på lag fire, og en UDP-videresender er det heller ikke. Access Servers vanlige oppsett på port 443 får OpenVPN TCP-demonen til å gjenkjenne nettlesertrafikk og levere den til webtjenestene, så å sette inn en uvedkommende HTTPS-terminator foran bevarer ikke den demonens protokollhåndtering. Å dele nummeret 443 gjør ikke to design likeverdige.

Den tredje er hvor feilen lander. En feil før VPN og en feil i kontrollkanalen ser like ut i en klient som bare sier "kobler til", men de etterlater spor på ulike steder. Hvis det gamle formatet er i spill, er oppstarten en kandidat. Hvis det nye formatet er i spill, er en tom web-tilgangslogg forventet og beviser ingenting i noen retning.

Når artefakten er gammel: oppstarten feiler først

Les klientens faktiske feil i stedet for sluttilstanden. De interessante feltene er HTTPS-feilen, serveridentiteten klienten forventet, destinasjonen forespørselen gikk til, og om sertifikatvalideringen ble fullført. Sammenlign dem deretter med webtjenestens og proxyens logger på serversiden.

At en nettleser når innloggingssiden er ikke bevis for at denne klientens API-autentisering lyktes. Det er forskjellige forespørsler, med forskjellige sertifikatforventninger og ofte forskjellige vertsnavn. Hvis portalen betjenes riktig og klienten fortsatt feiler, ligger uenigheten i oppstartsveien, ikke i brukerens passord.

Ikke få sammenligningen til å lykkes ved å slå av TLS-verifisering eller lempe autentiseringspolicyen. Det gjør et diagnostiserbart konfigurasjonsavvik om til en vei som virker, men ikke er verifisert, og det er nettopp den endringen som gjør en midlertidig test til et permanent hull. Access Servers dokumentasjon om tilkoblingsprofiler beskriver begge generasjonene og flyten for den midlertidige profilen, og det er referansen som må sjekkes før du antar at en proxy er skylden.

Når artefakten er ny: les kontrollkanalen i stedet

Med en profil i 2.9-stil går klienten rett til det innebygde VPN-endepunktet. Undersøk endepunktene i profilen, transporten som brukes, og feilen i kontrollkanalen. Hvis klienten aldri sender en HTTP-forespørsel, er det i tråd med designet og ikke et symptom.

Det er også her proxy-spørsmålet skifter form. En HTTPS-avlasting kan ikke bryte en TCP-only strøm den aldri ser, men den kan fortsatt bryte nedlastingen som publiserer profilen, og en TCP-only videresender vil ikke bære UDP i det hele tatt. Sjekk hvilken transport profilen ber om før du konkluderer med at frontenden er irrelevant.

TLS-gjennomføring for én enkelt strøm er et smalt oppsett. Det gir ikke UDP-videresending, og det gjenskaper ikke demonens egen tjenestevideresending på 443. Hvis frontenden din gjør en av disse tingene, si hvilken, fordi botemidlet er forskjellig.

Botemidler som holder seg smale

Den minst inngripende sjekken er å generere en ny støttet profil for en testkonto og koble til gjennom det tiltenkte innebygde endepunktet med de samme autentiseringskravene. Hvis det virker og den beholdte gamle profilen ikke gjør det, har du skilt artefakten fra serveren og fra proxien i ett trinn.

Distribusjon av en brukerlåst profil fjerner den eldre oppstartsavhengigheten helt, fordi det ikke finnes noen utveksling av midlertidig profil som kan feile. Den må utstedes til den tiltenkte brukeren, aldri kopieres fra en administrator, og den endrer hva klienten er autorisert til, så behandle den som en policybeslutning og ikke som en omvei.

Deretter retter du publiseringsoppsettet slik at hver påkrevd vei finnes: webveien for nedlastinger og portalbruk, og den innebygde VPN-veien på transporten som profilene forventer. Hold proxyens arbeid på ett lag. En fungerende brukerlåst tunnel beviser at den veien virker; den beviser ikke at ethvert proxyoppsett støtter hver generasjon, og en gammel oppstartsfeil fordømmer ikke det nyere formatet.

• Fastslå artefaktens generasjon før du berører proxien.
• Fastslå om feilen skjer før tunnelen eller inne i den.
• Bekreft hva frontenden avslutter: HTTP, TCP-strøm eller UDP.
• Test en nylig utstedt profil mot det innebygde endepunktet med uendret policy.