Varför en VPN-återanslutning ber om inloggningsuppgifter igen
Ett sparat lösenord och en återanvändbar token går ut enligt olika scheman. Läs vilket material återanslutningen bad om innan du ändrar något på klienten.
En tunnel som fungerade i timmar ber om ett lösenord i samma ögonblick som laptopen vaknar, och ingenting i konfigurationen har ändrats. Det som har ändrats är tillståndet för den inloggningsuppgift som återanslutningen försökte återanvända. Tre typer av material styr detta, och bara en av dem överlever ett godtyckligt gap.
Läs vilken klienten bad om, eftersom de tre går ut enligt olika klockor och misslyckas med olika meddelanden.
Tre typer av återanvändbart material
Ett cachelagrat lösenord är en hemlighet som klienten håller, och det förblir giltigt tills kontot ändrar det. En sessionstoken utfärdas av servern efter en lyckad inloggning, bär sin egen livstid och kan återkallas när som helst. En TLS-sessionsbiljett eller en IKE-säkerhetsassociation är protokolltillstånd, billigt att återuppta och helt oberoende av ditt lösenord. Var och en utfärdas av en annan komponent, och var och en går ut på sina egna villkor.
Den första överlever en omstart, den andra överlever vanligtvis ett viloläge, och den tredje överlever kanske inte ett nätverksbyte alls. Att blanda ihop dem ger fel åtgärd, som att återställa ett lösenord som aldrig avvisades.
Själva uppmaningen är diagnosen. Ett webbläsarfönster eller en andrafaktorkod betyder att servern krävde interaktiv autentisering, medan ett tyst fel utan uppmaning betyder att klienten aldrig kom tillräckligt långt för att bli tillfrågad.
| Material | Typical lifetime | What invalidates it |
|---|---|---|
| Cached password | Until changed | Account or password policy change |
| Session token | Minutes to hours | Expiry, revocation, reauthentication policy |
| Tunnel SA or TLS ticket | Configured rekey interval | Rekey, network change, peer restart |
Nyckelbyte är inte reautentisering
Ett nyckelbyte ersätter nycklar medan den autentiserade identiteten behålls, och därför sker det tyst då och då på en frisk tunnel. Reautentisering upprepar själva identitetskontrollen, och det är händelsen som behöver dig. IKEv2 skiljer de två explicit, och en peer kan kräva full reautentisering med ett konfigurerat intervall oavsett hur många nyckelbyten som skett däremellan. De två händelserna ser identiska ut utifrån tills du läser vilken loggen namnger.
OpenVPN beter sig på samma sätt i sin egen vokabulär: ett intervall för omförhandling fräschar upp datakanalen, och en autentiseringstoken kan lämnas tillbaka till klienten för att undvika en full inloggning vid nästa anslutning. Den token har en livstid, och servern avgör om den accepteras igen.
Så en återanslutning efter åtta timmar kan misslyckas där en återanslutning efter åtta minuter lyckades, utan någon konfigurationsändring på någon sida. Det är hela förklaringen till en uppmaning som bara dyker upp efter lunchen.
När klienten inte kan slutföra den nya utmaningen
En policy som kräver ett webbläsarsteg kommer att misslyckas på en klient som inte har något sätt att visa ett. Huvudlösa servrar, startskript och äldre profiler byggda för autentisering med bara lösenord träffar alla den väggen, och felet visas ofta som en allmän tidsgräns snarare än ett autentiseringsfel.
Enhets- och nätverksövergångar kan också falla inom ett policyutvärderingsfönster, så en roaming från Wi-Fi till en hotspot sammanfaller med en kontroll som skulle ha skett ändå. Sammanfallet får nätverket att verka skyldigt när orsaken är timern.
openvpn --config client.ovpn --verb 3 2>&1 | grep -i -E "reneg|auth" ipsec statusall | grep -i -E "rekey|reauth"
Den första raden visar omförhandlings- och autentiseringshändelser i klientens egen logg, och den andra visar de säkerhetsassociationer som en strongSwan-peer har just nu. Jämför tidsstämplarna med ögonblicket då uppmaningen dök upp; en matchning bekräftar timern och inte nätverket.
Vad som ska rapporteras, och vad som inte ska stängas av
Om en manuell inloggning lyckas och automatisk återanvändning konsekvent misslyckas, säg exakt det till operatören. Det namnger komponenten: återanvändningsvägen, inte inloggningsuppgiften. Ta med tidpunkten för felet, kontot som används och typen av uppmaning du såg.
Inaktivera inte andrafaktorn, hoppa inte över certifikatvalidering och klistra inte in inloggningsuppgifter i ett skript för att göra återanslutningen tyst. Var och en av dessa tar bort den kontroll som policyn finns för att upprätthålla, och var och en förvandlar en inloggningsuppmaning till en incident.
Be i stället om det stödda flödet: en klient som kan slutföra utmaningen, en tokenlivstid som passar arbetsdagen, eller en godkänd icke-interaktiv profil för maskinen som inte kan fråga. Alla är konfigurationsbeslut som någon kan godkänna, vilket en kringgång inte är.