OpenVPN auth-nocache: hva som skjer ved neste pålogging

Slå på auth-nocache, og advarselen om passordbufring forsvinner, sammen med kopien av påloggingsinformasjonen som OpenVPN holdt for neste reforhandling. Om det blir en forespørsel, et stille nytt forsøk eller en brutt tunnel avhenger av hvor påloggingsinformasjonen kommer fra andre gang. Derfor er dette en sammenligning mellom utrullingsformer og ikke en dom over valget. Les formen du faktisk kjører før du redigerer noen profil.

Hvor det andre settet med påloggingsinformasjon må komme fra

OpenVPN bruker auth-nocache på hemmelighetene som auth-user-pass og askpass samler inn: når de er brukt, kaster prosessen dem i stedet for å holde på dem til neste håndtrykk. En reforhandling kommer på en timer, som standard én gang i timen, så den andre forespørselen kommer lenge etter at personen som skrev passordet, har gått videre. Det gapet er hele historien. Med bufring slått på spiller klienten av den lagrede kopien uten å spørre noen; med bufring slått av må den finne hemmeligheten et annet sted eller mislykkes.

Så list opp hvert sted hemmeligheten kan komme fra i det øyeblikket, og vær ærlig om hvilke av dem som finnes på verten. En person ved en terminal, en fil som auth-user-pass eller askpass kan lese, eller et sesjonstoken utstedt av serveren er de tre som betyr noe her. Hvis ingen av dem er tilgjengelige, mislykkes reforhandlingen en time etter endringen, ikke i øyeblikket du gjorde den.

Tre former, tre feilpunkter

En skrivebordsklient med en person foran er det milde tilfellet: forespørselen kommer tilbake, noen skriver passordet igjen, og prisen er oppmerksomhet. En tjeneste, container eller ruter som kjører OpenVPN uten terminal, er det harde tilfellet, fordi det ikke er noen der til å svare, og tilkoblingen som før var stille, avslutter nå tunnelen. En hybrid ligger mellom de to og oppfører seg som skrivebordstilfellet til sesjonen som kunne svare på forespørselen, forsvinner. Det som skiller dem, er ikke om en GUI er installert, men om det finnes en kilde til påloggingsinformasjon på tidspunktet for reforhandlingen.

Kartlegg utrullingen din til en av de tre før du endrer noe, for rådet du finner på nettet, er nesten alltid skrevet for den første. Å bruke skrivebordssvaret på en hodeløs tjeneste er måten en tunnel som virket i månedsvis, begynner å falle hver time.

Direktiv eller flagg: velg ett, og vit hvilket du brukte

Inne i en profil er auth-nocache en egen linje; i et kall som navngir en profil eksplisitt, er det et flagg på den kommandolinjen, og OpenVPN-håndboken viser begge formene. Begge gjør det samme med oppbevaringen av påloggingsinformasjon, og ingen av dem rører grensesnitttypen eller reparerer en urelatert advarsel i samme logg. Forskjellen er varighet: flagget gjelder bare den kjøringen, så en tjeneste som startes på nytt fra en unit-fil eller et wrapper-skript, har det ikke med mindre wrapperen også sender det videre.

auth-nocache
openvpn --config /path/client.ovpn --auth-nocache

Bestem hvilket artefakt som eier innstillingen, endre den der og ingen andre steder. En profil redigert på en bærbar PC pluss en systemd-unit som overstyrer den med et flagg, er paret som gir motstridende oppførsel etter en omstart.

En påloggingsfil flytter hemmeligheten i stedet for å slette den

Å peke auth-user-pass mot en fil gir hver senere reforhandling en kilde, og det legger også passordet et sted som overlever omstarter. Spør hvem som kan lese filen, om daemonen fortsatt kan lese den etter å ha gitt slipp på privilegier, og hva som skjer når filsystemet er montert skrivebeskyttet eller en containervisning skjuler stien. En hemmelighet på disk og en hemmelighet i minnet er forskjellige problemer, og å løse det ene lar det andre bli stående. Rotasjon er trinnet som hoppes over: et passord som er endret på serveren men ikke i filen, gir en feil som leses som en nettverksfeil.

Hold filen eid av kontoen som kjører daemonen, lesbar for ingen andre, og utenfor sikkerhetskopier som forlater verten. OpenVPNs serverside-alternativ auth-gen-token gir klienten et sesjonstoken etter vellykket pålogging, noe som er en mindre ting å la ligge enn kontopassordet. Skriv rotasjonstrinnet ved siden av filen uansett, for filen overlever vanligvis personen som lagde den.

Å strekke reforhandlingen flytter kostnaden, den fjerner den ikke

Det andre forslaget er å øke reneg-sec til forespørselen er sjelden nok til å ignoreres. Det skriver om tidsplanen for nøkkelrotasjon i sesjonen og skyver det samme påloggingsproblemet til et senere, mindre forutsigbart øyeblikk; det lager ikke en kilde til påloggingsinformasjon. En policy som fornyer nøkler etter en tidsplan av en grunn, bør ikke lempes bare for å slippe å skrive et passord.

Test tilkoblingen på nytt i stedet for sesjonen du sitter i, for den levende sesjonen beviser ingenting. Slipp tunnelen fra serversiden, eller start klienttjenesten på nytt, og se hva den neste reforhandlingen gjør når ingen er ved tastaturet. Hvis den kobler til igjen, navngi mekanismen som leverte hemmeligheten; hvis ikke, har du funnet den virkelige kostnaden for valget på denne verten. Uansett utfall gir det deg et svar som holder under en avbrudd, i stedet for et som holdt under testing.

På en administrert flåte bør den som eier utrullingen kunne navngi tre ting: hvor påloggingsinformasjonen kommer fra, hvor den lagres, og hvem som roterer den. Hvis noe av det svaret er personen som satte opp verten, er valget der ennå ikke trygt.