Serverlåst profil misslyckas bakom en TLS-proxy: vilken generation?

En användare kan ansluta och en annan inte, genom samma portal, samma dag. Båda har serverlåsta profiler, båda är på samma Access Server-bygge, och den enda skillnaden är när deras profil genererades. Det är mönstret som är värt att känna igen, eftersom "serverlåst" namnger en policy och inte en anslutningssekvens. Access Server har levererat två generationer av den artefakten, och en omvänd TLS-proxy står framför bara en av deras vägar. Tre villkor avgör vilken gren du är på.

Två generationer, två anslutningssekvenser

I den äldre designen, giltig till och med 2.8, är den importerade filen en pseudoprofil. OpenVPN Connect använder den för att autentisera mot Access Servers webb-API över HTTPS, tar emot en tillfällig användarlåst profil och en sessionstoken, och upprättar först därefter VPN. Två transporter körs i sekvens, och den första är en vanlig webbförfrågan.

Formatet som introducerades med 2.9 utför inte den uppstarten per anslutning. Det är en inbyggd profil som kan användas av kompatibla OpenVPN klienter, inte bara av OpenVPN Connect. Nedladdning eller import via URL kan fortfarande innebära HTTPS — det är ett publiceringssteg, inte hämtning av en tillfällig profil per anslutning.

En uppgradering skriver inte nödvändigtvis om profiler som redan utfärdats, så en aktuell serverversion kan fortfarande dela ut den gamla artefakten. Serverbygget berättar vad som är möjligt, inte vad den här användaren importerade.

Tre villkor som väljer din gren

Det första villkoret är artefaktens generation. Begär filen, se hur den producerades och notera klientversionen som importerade den. Om du inte kan fastställa generationen från filen, kommer en ny profil utfärdad för ett testkonto att berätta vad servern producerar i dag, och det är annan information än den som den misslyckade användaren har.

Det andra är vad din frontend faktiskt avslutar. En omvänd HTTP-proxy på lager sju som avlastar TLS är inte samma objekt som en TCP-vidarebefordrare på lager fyra, och en UDP-vidarebefordrare är det inte heller. Access Servers vanliga uppställning på port 443 får OpenVPN TCP-demonen att känna igen webbläsartrafik och lämna den till webbtjänsterna, så att sätta in en orelaterad HTTPS-terminator framför bevarar inte den demonens protokollhantering. Att dela numret 443 gör inte två design likvärdiga.

Det tredje är var felet landar. Ett fel före VPN och ett fel i kontrollkanalen ser likadana ut i en klient som bara säger "ansluter", men de lämnar bevis på olika ställen. Om det gamla formatet är i spel är uppstarten en kandidat. Om det nya formatet är i spel är en tom webbåtkomstlogg förväntad och bevisar ingenting i någon riktning.

När artefakten är gammal: uppstarten misslyckas först

Läs klientens faktiska fel i stället för dess sluttillstånd. De intressanta fälten är HTTPS-felet, serveridentiteten klienten förväntade sig, destinationen som begäran gick till, och om certifikatvalideringen slutfördes. Jämför dem sedan med webbtjänstens och proxyns loggar på serversidan.

Att en webbläsare når inloggningssidan är inte bevis för att den här klientens API-autentisering lyckades. Det är olika begäranden, med olika certifikatförväntningar och ofta olika värdnamn. Om portalen serveras korrekt och klienten fortfarande misslyckas, ligger oenigheten i uppstartsvägen, inte i användarens lösenord.

Få inte jämförelsen att lyckas genom att stänga av TLS-verifiering eller lätta på autentiseringspolicyn. Det gör en diagnostiserbar konfigurationsavvikelse till en väg som fungerar men inte är verifierad, och det är just den ändringen som gör ett tillfälligt test till ett permanent hål. Access Servers dokumentation om anslutningsprofiler beskriver båda generationerna och flödet för den tillfälliga profilen, och det är referensen att kontrollera innan du antar att en proxy är skyldig.

När artefakten är ny: läs kontrollkanalen i stället

Med en profil i 2.9-stil går klienten rakt till den inbyggda VPN-slutpunkten. Undersök slutpunkterna i profilen, transporten som används och felet i kontrollkanalen. Om klienten aldrig skickar en HTTP-begäran är det förenligt med designen och inte ett symptom.

Det är också här proxyfrågan byter form. En HTTPS-avlastning kan inte bryta en TCP-only ström som den aldrig ser, men den kan fortfarande bryta nedladdningen som publicerar profilen, och en TCP-only vidarebefordrare kommer inte att bära UDP alls. Kontrollera vilken transport profilen begär innan du drar slutsatsen att frontend är irrelevant.

TLS-genomföring för en enda ström är en snäv uppställning. Den ger ingen UDP-vidarebefordran och återskapar inte demonens egen tjänstevidarebefordran på 443. Om din frontend gör en av dessa saker, säg vilken, eftersom botemedlet skiljer sig.

Botemedel som förblir snäva

Den minst ingripande kontrollen är att generera en ny stödd profil för ett testkonto och ansluta genom den avsedda inbyggda slutpunkten med samma autentiseringskrav. Om det fungerar och den bevarade gamla profilen inte gör det, har du skilt artefakten från servern och från proxyn i ett steg.

Distribution av en användarlåst profil tar bort det äldre uppstartsberoendet helt, eftersom det inte finns något utbyte av en tillfällig profil som kan misslyckas. Den måste utfärdas till den avsedda användaren, aldrig kopieras från en administratör, och den ändrar vad klienten är behörig till, så behandla den som ett policybeslut och inte som en omväg.

Rätta sedan publiceringsuppställningen så att varje nödvändig väg finns: webbvägen för nedladdningar och portalanvändning, och den inbyggda VPN-vägen på den transport som profilerna förväntar sig. Håll proxyns arbete på ett lager. En fungerande användarlåst tunnel bevisar att den vägen fungerar; den bevisar inte att varje proxyuppställning stöder varje generation, och ett gammalt uppstartsfel dömer inte det nyare formatet.

• Fastställ artefaktens generation innan du rör proxyn.
• Fastställ om felet inträffar före tunneln eller inuti den.
• Bekräfta vad frontend avslutar: HTTP, TCP-ström eller UDP.
• Testa en nyligen utfärdad profil mot den inbyggda slutpunkten med oförändrad policy.