OpenVPN auth-nocache: vad som händer vid nästa inloggning

Slå på auth-nocache och varningen om lösenordscache försvinner, tillsammans med kopian av inloggningsuppgifterna som OpenVPN höll för nästa omförhandling. Om det blir en fråga, ett tyst nytt försök eller en bruten tunnel beror på var inloggningsuppgifterna kommer ifrån andra gången. Därför är detta en jämförelse mellan utrullningsformer och inte en dom över alternativet. Läs den form du faktiskt kör innan du redigerar någon profil.

Varifrån den andra uppsättningen inloggningsuppgifter måste komma

OpenVPN tillämpar auth-nocache på hemligheterna som auth-user-pass och askpass samlar in: när de har använts kastar processen dem i stället för att hålla dem till nästa handskakning. En omförhandling kommer på en timer, som standard en gång i timmen, så den andra begäran kommer långt efter att personen som skrev lösenordet har gått vidare. Den luckan är hela historien. Med cachen på spelar klienten upp den sparade kopian utan att fråga någon; med cachen av måste den hitta hemligheten någon annanstans eller misslyckas.

Så lista varje plats hemligheten kan komma från i det ögonblicket, och var ärlig om vilka av dem som finns på värden. En person vid en terminal, en fil som auth-user-pass eller askpass kan läsa, eller en sessionstoken som utfärdats av servern är de tre som spelar roll här. Om ingen av dem är tillgänglig misslyckas omförhandlingen en timme efter ändringen, inte i det ögonblick du gjorde den.

Tre former, tre felpunkter

En skrivbordsklient med en person framför är det milda fallet: frågan kommer tillbaka, någon skriver lösenordet igen, och priset är uppmärksamhet. En tjänst, container eller router som kör OpenVPN utan terminal är det hårda fallet, eftersom ingen är där för att svara och återanslutningen som förr var tyst nu avslutar tunneln. En hybrid ligger mellan de två och beter sig som skrivbordsfallet tills sessionen som kunde svara på frågan försvinner. Det som skiljer dem är inte om ett GUI är installerat, utan om det finns en källa till inloggningsuppgifter vid tidpunkten för omförhandlingen.

Mappa din utrullning till en av de tre innan du ändrar något, för rådet du hittar online är nästan alltid skrivet för den första. Att tillämpa skrivbordssvaret på en tjänst utan terminal är hur en tunnel som fungerade i månader börjar falla varje timme.

Direktiv eller flagga: välj en och vet vilken du använde

Inuti en profil är auth-nocache en egen rad; vid ett anrop som namnger en profil uttryckligen är det en flagga på den kommandoraden, och OpenVPN-handboken listar båda formerna. Båda gör samma sak med bevarandet av inloggningsuppgifter, och ingen av dem rör gränssnittstypen eller reparerar en orelaterad varning i samma logg. Skillnaden är varaktighet: flaggan gäller bara den körningen, så en tjänst som startas om från en unit-fil eller ett wrapper-skript har den inte om inte omslaget också skickar den.

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

Bestäm vilken artefakt som äger inställningen, ändra den där och ingen annanstans. En profil redigerad på en bärbar dator plus en systemd-unit som skriver över den med en flagga är paret som ger motstridigt beteende efter en omstart.

En inloggningsfil flyttar hemligheten i stället för att radera den

Att peka auth-user-pass mot en fil ger varje senare omförhandling en källa, och det placerar också lösenordet någonstans som överlever omstarter. Fråga vem som kan läsa filen, om daemonen fortfarande kan läsa den efter att ha avstått från privilegier, och vad som händer när filsystemet är monterat skrivskyddat eller en containervy döljer sökvägen. En hemlighet på disk och en hemlighet i minnet är olika problem, och att lösa det ena lämnar det andra på plats. Rotation är steget som hoppas över: ett lösenord som ändrats på servern men inte i filen ger ett fel som läses som ett nätverksfel.

Håll filen ägd av kontot som kör daemonen, läsbar för ingen annan, och utanför säkerhetskopior som lämnar värden. OpenVPNs server-sidiga alternativ auth-gen-token ger klienten en sessionstoken efter en lyckad inloggning, vilket är en mindre sak att lämna liggande än kontots lösenord. Skriv rotationssteget bredvid filen i vilket fall som helst, eftersom filen oftast överlever personen som skapade den.

Att sträcka ut omförhandlingen flyttar kostnaden, den tar inte bort den

Det andra förslaget är att höja reneg-sec tills frågan är tillräckligt sällsynt för att ignoreras. Det skriver om sessionens schema för nyckelrotation och skjuter samma inloggningsproblem till ett senare, mindre förutsägbart ögonblick; det skapar ingen källa till inloggningsuppgifter. En policy som förnyar nycklar enligt ett schema av någon anledning bör inte luckras upp bara för att slippa skriva ett lösenord.

Testa återanslutningen och inte sessionen du sitter i, för den levande sessionen bevisar ingenting. Släpp tunneln från serversidan, eller starta om klienttjänsten, och se vad nästa omförhandling gör när ingen är vid tangentbordet. Om den ansluter igen, namnge mekanismen som levererade hemligheten; om inte, har du hittat den verkliga kostnaden för alternativet på den här värden. Vilket utfall som helst ger dig ett svar som håller under ett avbrott i stället för ett som höll under testning.

På en hanterad flotta bör den som äger utrullningen kunna namnge tre saker: varifrån inloggningsuppgifterna kommer, var de lagras och vem som roterar dem. Om något av det svaret är personen som satte upp värden är alternativet där ännu inte säkert.