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

Slå på auth-nocache, og åtvaringa om passordbufring forsvinn, saman med kopien av påloggingsinformasjonen som OpenVPN heldt for neste reforhandling. Om det blir ei førespurnad, eit stille nytt forsøk eller ein broten tunnel, avheng av kvar påloggingsinformasjonen kjem frå andre gongen. Derfor er dette ei samanlikning mellom utrullingsformer og ikkje ein dom over valet. Les forma du faktisk køyrer før du redigerer nokon profil.

Kvar det andre settet med påloggingsinformasjon må kome frå

OpenVPN brukar auth-nocache på løyndomane som auth-user-pass og askpass samlar inn: når dei er brukte, kastar prosessen dei i staden for å halde på dei til neste handtrykk. Ei reforhandling kjem på ein timer, som standard éin gong i timen, så den andre førespurnaden kjem lenge etter at personen som skreiv passordet, har gått vidare. Det gapet er heile historia. Med bufring slått på spelar klienten av den lagra kopien utan å spørje nokon; med bufring slått av må han finne løyndomen ein annan stad eller mislukkast.

Så list opp kvar stad løyndomen kan kome frå i det augneblinken, og ver ærleg om kva av dei som finst på verten. Ein person ved ein terminal, ei fil som auth-user-pass eller askpass kan lese, eller eit sesjonstoken utstedt av tenaren er dei tre som tel her. Viss ingen av dei er tilgjengelege, mislukkast reforhandlinga ein time etter endringa, ikkje i augneblinken du gjorde ho.

Tre former, tre feilpunkt

Ein skrivebordsklient med ein person framfor er det milde tilfellet: førespurnaden kjem tilbake, nokon skriv passordet igjen, og prisen er merksemd. Ein teneste, container eller ruter som køyrer OpenVPN utan terminal, er det harde tilfellet, fordi det ikkje er nokon der til å svare, og tilkoplinga som før var stille, avsluttar no tunnelen. Ein hybrid ligg mellom dei to og oppfører seg som skrivebordstilfellet til sesjonen som kunne svare på førespurnaden, forsvinn. Det som skil dei, er ikkje om ein GUI er installert, men om det finst ei kjelde til påloggingsinformasjon på tidspunktet for reforhandlinga.

Kartlegg utrullinga di til ein av dei tre før du endrar noko, for rådet du finn på nettet, er nesten alltid skrive for den første. Å bruke skrivebordssvaret på ein hovudlaus teneste er måten ein tunnel som verka i månadsvis, byrjar å falle kvar time.

Direktiv eller flagg: vel eitt, og vit kva du brukte

Inne i ein profil er auth-nocache ei eiga linje; i eit kall som namngjev ein profil eksplisitt, er det eit flagg på den kommandolinja, og OpenVPN-handboka viser begge formene. Begge gjer det same med oppbevaringa av påloggingsinformasjon, og ingen av dei rører grensesnitttypen eller reparerer ei urelatert åtvaring i same loggen. Skilnaden er varigheit: flagget gjeld berre den køyringa, så ein teneste som blir starta på nytt frå ei unit-fil eller eit wrapper-skript, har det ikkje med mindre wrapperen òg sender det vidare.

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

Avgjer kva artefakt som eig innstillinga, endre ho der og ingen andre stader. Ein profil redigert på ein berbar PC pluss ei systemd-unit som overstyrer han med eit flagg, er paret som gir motstridande oppførsel etter ein omstart.

Ei påloggingsfil flyttar løyndomen i staden for å slette han

Å peike auth-user-pass mot ei fil gir kvar seinare reforhandling ei kjelde, og det legg òg passordet ein stad som overlever omstartar. Spør kven som kan lese fila, om daemonen framleis kan lese ho etter å ha gitt frå seg privilegium, og kva som skjer når filsystemet er montert skriveverna eller ei containervising gøymer stigen. Ein løyndom på disk og ein løyndom i minnet er ulike problem, og å løyse det eine lèt det andre bli ståande. Rotasjon er trinnet som blir hoppa over: eit passord som er endra på tenaren men ikkje i fila, gir ein feil som blir lesen som ein nettverksfeil.

Hald fila eigd av kontoen som køyrer daemonen, lesbar for ingen andre, og utanfor tryggleikskopiar som forlèt verten. Tenarside-alternativet auth-gen-token i OpenVPN gir klienten eit sesjonstoken etter vellykka pålogging, noko som er ein mindre ting å la liggje enn kontopassordet. Skriv rotasjonstrinnet ved sida av fila uansett, for fila overlever vanlegvis personen som laga ho.

Å strekkje reforhandlinga flyttar kostnaden, han fjernar han ikkje

Det andre forslaget er å auke reneg-sec til førespurnaden er sjeldan nok til å bli ignorert. Det skriv om tidsplanen for nøkkelrotasjon i sesjonen og skyv det same påloggingsproblemet til eit seinare, mindre føreseieleg augneblink; det lagar ikkje ei kjelde til påloggingsinformasjon. Ein policy som fornyar nøklar etter ein tidsplan av ein grunn, bør ikkje bli mjuka opp berre for å sleppe å skrive eit passord.

Test tilkoplinga på nytt i staden for sesjonen du sit i, for den levande sesjonen bevisar ingenting. Slepp tunnelen frå tenarsida, eller start klienttenesta på nytt, og sjå kva den neste reforhandlinga gjer når ingen er ved tastaturet. Viss han koplar til igjen, namngi mekanismen som leverte løyndomen; viss ikkje, har du funne den verkelege kostnaden for valet på denne verten. Uansett utfall gir det deg eit svar som held under eit avbrot, i staden for eit som heldt under testing.

På ein administrert flåte bør den som eig utrullinga kunne namngi tre ting: kvar påloggingsinformasjonen kjem frå, kvar han blir lagra, og kven som roterer han. Viss noko av det svaret er personen som sette opp verten, er valet der enno ikkje trygt.