Hvorfor en VPN-gjentilkobling ber om påloggingsinformasjon igjen
Et lagret passord og et gjenbrukbart token utløper etter ulike tidsplaner. Les hvilket materiale gjentilkoblingen ba om før du endrer noe på klienten.
En tunnel som fungerte i timer ber om et passord i det øyeblikket laptopen våkner, og ingenting i konfigurasjonen er endret. Det som er endret, er tilstanden til påloggingsinformasjonen som gjentilkoblingen prøvde å gjenbruke. Tre typer materiale styrer dette, og bare én av dem overlever et vilkårlig gap.
Les hvilken klienten ba om, fordi de tre utløper etter ulike klokker og feiler med ulike meldinger.
Tre typer gjenbrukbart materiale
Et bufret passord er en hemmelighet klienten holder, og det forblir gyldig til kontoen endrer det. Et sesjonstoken utstedes av serveren etter en vellykket pålogging, har sin egen levetid og kan tilbakekalles når som helst. En TLS-sesjonsbillett eller en IKE-sikkerhetsassosiasjon er protokolltilstand, billig å gjenoppta og helt uavhengig av passordet ditt. Hver utstedes av en ulik komponent, og hver utløper på sine egne vilkår.
Den første overlever en omstart, den andre overlever vanligvis en dvale, og den tredje overlever kanskje ikke et nettverksbytte i det hele tatt. Å forveksle dem gir feil rettelse, som å tilbakestille et passord som aldri ble avvist.
Selve forespørselen er diagnosen. Et nettleservindu eller en andrefaktorkode betyr at serveren krevde interaktiv autentisering, mens en stille feil uten forespørsel betyr at klienten aldri kom langt nok til å bli spurt.
| 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 ikke reautentisering
En nøkkelutskifting erstatter nøkler mens den autentiserte identiteten beholdes, og derfor skjer det stille med jevne mellomrom på en sunn tunnel. Reautentisering gjentar selve identitetskontrollen, og det er hendelsen som trenger deg. IKEv2 skiller de to eksplisitt, og en peer kan kreve full reautentisering med et konfigurert intervall uansett hvor mange nøkkelutskiftinger som har skjedd i mellomtiden. De to hendelsene ser identiske ut fra utsiden til du leser hvilken loggen navngir.
OpenVPN oppfører seg på samme måte i sitt eget vokabular: et intervall for nye forhandlinger fornyer datakanalen, og et autentiseringstoken kan gis tilbake til klienten for å unngå full pålogging ved neste tilkobling. Det tokenet har en levetid, og serveren avgjør om det godtas igjen.
Så en gjentilkobling etter åtte timer kan feile der en gjentilkobling etter åtte minutter lyktes, uten noen konfigurasjonsendring på noen av sidene. Det er hele forklaringen på en forespørsel som først dukker opp etter lunsj.
Når klienten ikke kan fullføre den nye utfordringen
En policy som krever et nettlesersteg, vil feile på en klient som ikke har noen måte å vise ett. Hodeløse servere, oppstartsskript og eldre profiler bygget for autentisering med bare passord treffer alle den veggen, og feilen vises ofte som en generisk tidsavbrudd snarere enn en autentiseringsfeil.
Enhets- og nettverksoverganger kan også falle innenfor et policyvindu, så en vandring fra Wi-Fi til et hotspot sammenfaller med en kontroll som ville skjedd uansett. Sammenfall gjør at nettverket ser skyldig ut når årsaken 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 linjen viser hendelser for nye forhandlinger og autentisering i klientens egen logg, og den andre viser sikkerhetsassosiasjonene en strongSwan-peer har akkurat nå. Sammenlign tidsstemplene med øyeblikket forespørselen dukket opp; et samsvar bekrefter timeren og ikke nettverket.
Hva som skal rapporteres, og hva som ikke skal slås av
Hvis en manuell pålogging lykkes og automatisk gjenbruk konsekvent feiler, si nøyaktig det til operatøren. Det navngir komponenten: gjenbruksbanen, ikke påloggingsinformasjonen. Ta med tidspunktet for feilen, kontoen som brukes og typen forespørsel du så.
Ikke deaktiver andrefaktoren, hopp over sertifikatvalidering eller lim påloggingsinformasjon inn i et skript for å gjøre gjentilkoblingen stille. Hver av disse fjerner kontrollen policyen finnes for å håndheve, og hver av dem gjør en påloggingsforespørsel til en hendelse.
Be i stedet om den støttede flyten: en klient som kan fullføre utfordringen, en tokenlevetid som passer arbeidsdagen, eller en godkjent ikke-interaktiv profil for maskinen som ikke kan spørre. Alle er konfigurasjonsbeslutninger noen kan godkjenne, noe en omvei ikke er.