OpenVPN auth-nocache: hvad der sker ved næste login

Slå auth-nocache til, og advarslen om cachelagring af adgangskoden forsvinder, sammen med kopien af de legitimationsoplysninger, som OpenVPN holdt til næste forhandling. Om det bliver en forespørgsel, et stille nyt forsøg eller en afbrudt tunnel afhænger af, hvor oplysningerne kommer fra anden gang. Det gør dette til en sammenligning mellem udrulningsformer og ikke en dom over indstillingen. Læs den form, du faktisk kører, før du redigerer nogen profil.

Hvor det andet sæt legitimationsoplysninger skal komme fra

OpenVPN anvender auth-nocache på de hemmeligheder, som auth-user-pass og askpass indsamler: når de har været brugt, smider processen dem i stedet for at holde på dem til næste håndtryk. En ny forhandling kommer på en timer, som standard én gang i timen, så den anden anmodning lander længe efter, at personen, der tastede adgangskoden, er gået videre. Det hul er hele historien. Med cachen slået til genspiller klienten den gemte kopi uden at spørge nogen; med cachen slået fra skal den finde hemmeligheden et andet sted eller fejle.

Så list hvert sted, hvor hemmeligheden kan komme fra i det øjeblik, og vær ærlig om, hvilke af dem der findes på værten. En person ved en terminal, en fil som auth-user-pass eller askpass kan læse, eller et sessionstoken udstedt af serveren er de tre, der betyder noget her. Hvis ingen af dem er tilgængelige, fejler forhandlingen en time efter ændringen og ikke i det øjeblik, du lavede den.

Tre former, tre fejlpunkter

En skrivebordsklient med en person foran er det milde tilfælde: forespørgslen kommer tilbage, nogen taster adgangskoden igen, og prisen er opmærksomhed. En tjeneste, container eller router, der kører OpenVPN uden terminal, er det hårde tilfælde, fordi der ikke er nogen til at svare, og genopkoblingen, der plejede at være stille, afslutter nu tunnelen. En hybrid ligger mellem de to og opfører sig som skrivebordstilfældet, indtil den session, der kunne svare på forespørgslen, forsvinder. Det, der adskiller dem, er ikke, om en GUI er installeret, men om der findes en kilde til legitimationsoplysninger på tidspunktet for forhandlingen.

Kortlæg din udrulning til en af de tre, før du ændrer noget, for det råd, du finder online, er næsten altid skrevet til den første. At anvende skrivebordssvaret på en hovedløs tjeneste er måden, hvorpå en tunnel, der virkede i månedsvis, begynder at falde hver time.

Direktiv eller flag: vælg ét, og vid hvilket du brugte

Inde i en profil er auth-nocache sin egen linje; ved en kald, der navngiver en profil eksplicit, er det et flag på den kommandolinje, og OpenVPN-manualen viser begge former. Begge gør det samme ved tilbageholdelsen af oplysninger, og ingen af dem rører grænsefladetypen eller reparerer en urelateret advarsel i samme log. Forskellen er vedholdenhed: flaget dækker kun den kørsel, så en tjeneste, der genstartes fra en unit-fil eller et wrapper-script, har det ikke, medmindre wrapperen også sender det videre.

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

Beslut, hvilket artefakt der ejer indstillingen, ændr den der og intet andet sted. En profil, der er redigeret på en bærbar, plus en systemd-unit, der tilsidesætter den med et flag, er det par, der giver modstridende adfærd efter en genstart.

En legitimationsfil flytter hemmeligheden i stedet for at slette den

At pege auth-user-pass mod en fil giver hver senere forhandling en kilde, og det placerer også adgangskoden et sted, der overlever genstarter. Spørg, hvem der kan læse den fil, om dæmonen stadig kan læse den efter at have opgivet privilegier, og hvad der sker, når filsystemet er monteret skrivebeskyttet, eller en containervisning skjuler stien. En hemmelighed på disken og en hemmelighed i hukommelsen er forskellige problemer, og løsning af det ene lader det andet blive på plads. Rotation er det trin, der springes over: en adgangskode, der er ændret på serveren men ikke i filen, giver en fejl, der læses som en netværksfejl.

Hold filen ejet af den konto, der kører dæmonen, læsbar for ingen andre og uden for backups, der forlader værten. OpenVPNs server-side-indstilling auth-gen-token giver klienten et sessionstoken efter et vellykket login, hvilket er en mindre ting at efterlade end kontoens adgangskode. Skriv rotationsproceduren ved siden af filen under alle omstændigheder, for filen overlever normalt personen, der oprettede den.

At strække forhandlingen flytter omkostningen, det fjerner den ikke

Det andet forslag er at hæve reneg-sec, indtil forespørgslen er sjælden nok til at ignorere. Det omskriver sessionens tidsplan for nøglerotation og skubber det samme legitimationsproblem til et senere, mindre forudsigeligt tidspunkt; det skaber ikke en kilde til oplysninger. En politik, der fornyer nøgler efter en tidsplan af en grund, bør ikke lempes bare for at undgå at taste en adgangskode.

Test genopkoblingen i stedet for den session, du sidder i, for den levende session beviser intet. Drop tunnelen fra serversiden, eller genstart klienttjenesten, og se, hvad den næste forhandling gør, når der ikke er nogen ved tastaturet. Hvis den genopkobler, navngiv den mekanisme, der leverede hemmeligheden; hvis ikke, har du fundet den reelle pris for indstillingen på denne vært. Begge udfald giver dig et svar, der holder under en afbrydelse, i stedet for et, der holdt under test.

På en administreret flåde bør den, der ejer udrulningen, kunne navngive tre ting: hvor oplysningerne kommer fra, hvor de opbevares, og hvem der roterer dem. Hvis noget af det svar er personen, der satte værten op, er indstillingen der endnu ikke sikker.