Kvifor ei VPN-gjentilkopling ber om påloggingsinformasjon på nytt
Eit lagra passord og eit gjenbrukbart token går ut etter ulike tidsplanar. Les kva materiale gjentilkoplinga bad om før du endrar noko på klienten.
Ein tunnel som verka i timar ber om eit passord i det augneblinken laptopen vaknar, og ingenting i konfigurasjonen er endra. Det som er endra, er tilstanden til påloggingsinformasjonen som gjentilkoplinga prøvde å gjenbruke. Tre slag materiale styrer dette, og berre eitt av dei overlever eit vilkårleg gap.
Les kva for eitt klienten bad om, fordi dei tre går ut etter ulike klokker og feilar med ulike meldingar.
Tre slag gjenbrukbart materiale
Eit bufra passord er ein løyndom klienten held, og det blir verande gyldig til kontoen endrar det. Eit sesjonstoken blir gjeve ut av tenaren etter ei vellukka pålogging, ber si eiga levetid og kan kallast tilbake når som helst. Ein TLS-sesjonsbillett eller ein IKE-tryggleiksassosiasjon er protokolltilstand, billeg å halde fram og heilt uavhengig av passordet ditt. Kvart blir gjeve ut av ein ulik komponent, og kvart går ut på sine eigne vilkår.
Det første overlever ein omstart, det andre overlever vanlegvis ein dvale, og det tredje overlever kanskje ikkje eit nettverksbyte i det heile. Å blande dei gir feil retting, som å nullstille eit passord som aldri vart avvist.
Sjølve førespurnaden er diagnosen. Eit nettlesarvindauge eller ein andrefaktorkode tyder på at tenaren kravde interaktiv autentisering, medan ein stille feil utan førespurnad tyder på at klienten aldri kom langt nok til å bli spurd.
| 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 |
Nøkkelutskifting er ikkje reautentisering
Ei nøkkelutskifting byter ut nøklar medan den autentiserte identiteten blir halden, og difor skjer det stille no og då på ein sunn tunnel. Reautentisering gjer sjølve identitetskontrollen om att, og det er hendinga som treng deg. IKEv2 skil dei to eksplisitt, og ein peer kan krevje full reautentisering med eit sett intervall uansett kor mange nøkkelutskiftingar som har skjedd imellom. Dei to hendingane ser like ut frå utsida til du les kva for ei loggen namngir.
OpenVPN gjer det same i sitt eige vokabular: eit intervall for nye forhandlingar fornyar datakanalen, og eit autentiseringstoken kan givast tilbake til klienten for å unngå full pålogging ved neste tilkopling. Det tokenet har ei levetid, og tenaren avgjer om det blir godteke igjen.
Så ei gjentilkopling etter åtte timar kan feile der ei gjentilkopling etter åtte minutt lukkast, utan noka konfigurasjonsendring på nokon av sidene. Det er heile forklaringa på ein førespurnad som først dukkar opp etter lunsj.
Når klienten ikkje kan fullføre den nye utfordringa
Ein policy som krev eit nettlesarsteg, vil feile på ein klient som ikkje har nokon måte å vise eitt. Tenarar utan skjerm, oppstartsskript og eldre profilar bygde for autentisering med berre passord treffer alle den veggen, og feilen viser seg ofte som ein generisk tidsavbrot snarare enn ein autentiseringsfeil.
Eining- og nettverksovergangar kan også falle innanfor eit policyvindauge, så ein vandring frå Wi-Fi til eit hotspot fell saman med ein kontroll som ville skjedd uansett. Samanfallet får nettverket til å sjå skuldig ut når årsaka er timeren.
openvpn --config client.ovpn --verb 3 2>&1 | grep -i -E "reneg|auth" ipsec statusall | grep -i -E "rekey|reauth"
Den første lina viser hendingar for nye forhandlingar og autentisering i klienten sin eigen logg, og den andre viser tryggleiksassosiasjonane ein strongSwan-peer har akkurat no. Samanlikn tidsstempla med augneblinken førespurnaden dukka opp; eit samsvar stadfester timeren og ikkje nettverket.
Kva som skal rapporterast, og kva som ikkje skal slåast av
Viss ei manuell pålogging lukkast og automatisk gjenbruk konsekvent feilar, sei nøyaktig det til operatøren. Det namngir komponenten: gjenbruksvegen, ikkje påloggingsinformasjonen. Ta med tidspunktet for feilen, kontoen som blir brukt og typen førespurnad du såg.
Ikkje deaktiver andrefaktoren, hopp over sertifikatvalidering eller lim påloggingsinformasjon inn i eit skript for å gjere gjentilkoplinga stille. Kvar av desse fjernar kontrollen policyen finst for å handheve, og kvar av dei gjer ein påloggingsførespurnad til ei hending.
Be i staden om den støtta flyten: ein klient som kan fullføre utfordringa, ei tokenlevetid som passar arbeidsdagen, eller ein godkjend ikkje-interaktiv profil for maskinen som ikkje kan spørje. Alle er konfigurasjonsavgjerder nokon kan godkjenne, noko ein omveg ikkje er.