OpenVPN: TLS-handskakningen misslyckades – vilken gren är du på?

Raden som säger att TLS-handskakningen misslyckades är slutet på en historia, inte början. Det avgörande är händelsen precis före, eftersom den händelsen namnger vilket av fyra mycket olika fel du har. En timeout, en avvikelse i kontrollkanalen, ett avvisat certifikat och ett fel efter förhandlingen ger alla samma rubrik. Välj grenen utifrån bevisen, och åtgärden är inte längre en gissning.

Läs den sista händelsen före felet

Rulla uppåt i stället för att läsa sista raden. Händelsen före frånkopplingen namnger vanligtvis fasen: inget svar alls, ett fel vid utbytet av kontrollpaket, ett verifieringsresultat eller en lyckad förhandling följd av ett autentiseringsresultat. Var och en av dem tillhör olika ägare. Den enda raden avgör vilket avsnitt nedan som gäller.

Spara feltexten med klientversionen, slutpunkten och transporten. Håll nycklar, lösenord och oredigerade profiler borta från allt du klistrar in offentligt.

Ett exakt första fel är värt mer än ett långt loggutdrag. Det namnger fasen, och fasen namnger ägaren.

Gren ett: ingenting kom tillbaka

Om klienten skickade sitt första paket och inte fick något användbart ligger problemet på vägen eller hos lyssnaren. Bekräfta att profilen matchar ett alternativ som operatören faktiskt erbjuder: adress, port och UDP eller TCP. Kontrollera sedan om slutpunkten över huvud taget går att nå från det här nätet. Notera vilken av de två kontrollerna som misslyckades innan du går vidare.

En webbläsare som laddar en sida på samma värdnamn bevisar bara att en webbtjänst svarade. Inte ens en accepterad TCP-anslutning säger något om huruvida OpenVPN slutförde förhandlingen.

Om profilen fungerar i ett annat betrott nätverk, behåll den jämförelsen. Den lokaliserar begränsningen till en väg eller en mellanhand.

Gren två: kontrollkanalen stämmer inte

När utbytet börjar och sedan stannar är kontrollkanalens inställningar den första misstänkta. tls-auth och tls-crypt måste stämma med driftsättningen, och material från en annan server ger inget användbart utbyte. Detta fel inträffar före varje kontoinloggning. En profil kopierad från en äldre server är den vanliga källan.

En lösenordsåterställning ersätter inte dessa inställningar, och att låna en nyckel från en annan tjänst är inte en kompatibilitetsåtgärd. Hämta profilen via operatörens verifierade kanal och notera den klientversion den förväntar sig.

Notera det specifika förhandlingsfelet i stället för att slå på en hög äldre algoritmer för att se vad som håller. En fångad feltext är det som gör det möjligt för operatören att kontrollera sin sida.

Gren tre: ett certifikat avvisades

Ett uttryckligt verifieringsfel namnger det certifikat det inte tycker om. Kontrollera enhetens klocka först och läs sedan vilket objekt som misslyckades: serverns certifikat, klientens certifikat eller en utfärdare i kedjan. Utgång, en ej betrodd utfärdare och en oväntad identitet är tre olika meddelanden.

Håll verifieringen på medan du skaffar rättat material. Att acceptera ett orelaterat certifikat tar bort felet utan att bevisa att du nådde den avsedda servern.

Notera om felet följer nätverket eller profilen. Ett certifikatfel som dyker upp överallt är inte ett vägproblem.

Gren fyra: förhandlingen blev klar och något annat misslyckades

När identitetsutbytet lyckas tillhör det återstående felet autentisering eller routing. Ett uttryckligt kontoavslag är en autentiseringsfråga, och en ansluten tunnel med oåtkomliga webbplatser är en routing- eller DNS-fråga. Att fortsätta byta ut TLS-alternativ vid den punkten skadar en fas som redan fungerade.

När du rapporterar problemet, säg om varje nätverk misslyckas, om en annan profil fungerar och om servern registrerade försöket. Tystnad på serversidan och ett avslag därifrån står vid olika gränser.