Sparka ut en OpenVPN-klient: kill, deny eller återkalla ett certifikat?

Du har ett common name och en adress i dina anteckningar, och tre kommandon som alla ser ut att ta bort en klient. Bara ett gör det du vill, och valet beror på om du måste avsluta sessionen som körs nu, neka nästa inloggning eller ta bort rätten att ansluta helt. Läs den identitet du faktiskt har innan du rör något, för en OpenVPN-pool ger samma tunneladress till en annan session senare.

Vilken identitet du faktiskt har

En statusfil i version 3 är den vanliga utgångspunkten. CLIENT_LIST-avsnittet bär common name, den riktiga adressen, byträknare och anslutningstid; ROUTING TABLE-avsnittet kopplar en virtuell adress till ett common name med en tidsstämpel för senaste referens. Common name är den stabila identiteten. Den virtuella adressen är en tilldelning, och den riktiga adressen bakom en NAT kan ändras mellan sessioner utan att något på servern ändras.

Hanteringsgränssnittet visar en liknande vy via sitt kommando status och lägger till ett klient-ID per session. Det är det ID:t client-kill förväntar sig, och det är inte tunneladressen. Om du behöver veta vilket common name som fick vilken adress vid anslutningen har miljön för ett client-connect-skript båda, tillsammans med den betrodda yttre adressen, men det skriptet körs som OpenVPN-användaren och behöver en skrivbar loggväg.

Döda nu, neka vid inloggning, återkalla för gott

Båda borttagningskommandona i hanteringsgränssnittet är sessionsåtgärder. kill tar ett common name eller en riktig adress och port; client-kill tar klient-ID:t och avslutar den instansen omedelbart. Ingen av dem är en blockering: en utsparkad klient med giltigt certifikat och lösenord återansluter inom sekunder, vilket är bra när du återanvänder en testpeer och värdelöst när en bärbar dator har stulits.

client-deny är en annan typ av beslut. Det utfärdas vanligtvis från en autentiserings- eller client-connect-hook och avvisar sessionen med ett skäl, så det passar en policy som nekar en inloggning snarare än en som avbryter en anslutning. Dokumentationen varnar också för att ett nekande som utfärdas under en TLS-omförhandling ogiltigförklarar den omförhandlade nyckeln medan den befintliga sessionen kan fortsätta tills övergångsfönstret stängs. Om kravet är att klienten är borta nu är det dokumenterade svaret client-kill.

Beständig borttagning ligger under allt detta. Återkalla certifikatet och se till att crl-verify pekar på en lista som servern faktiskt läser in igen, inaktivera klientens specifika konfigurationsfil i ccd-katalogen, eller inaktivera kontot i det backend som autentiseringshooken frågar. En återkallelse är inte heller omedelbar: med standardinställningarna för reneg-sec kan en etablerad session fortsätta tills den omförhandlar, så sessionsåtgärden och legitimationsåtgärden kompletterar varandra, de är inte alternativ.

Är hanteringsuttaget ledigt?

Hanteringsgränssnittet betjänar en klient i taget. Om ett GUI eller en övervakningsdaemon redan håller anslutningen kan ditt skript inte ansluta bredvid, och beroende på klient kan du knuffa ut den befintliga i stället för att misslyckas rent. Dess lösenord färdas i klartext på det uttaget, så det hör hemma på en lokal adress eller ett unix-uttag, aldrig på ett offentligt gränssnitt.

När du inte kan ta uttaget har du fortfarande alternativ, och alla är långsammare. Släpp GUI:ns session först om du kontrollerar den, eller acceptera vägen via legitimeringslagret och vänta på nästa omförhandling. Vad du inte bör göra är att starta om tjänsten för att bli av med en klient, eftersom det också avslutar alla andra sessioner och förstör statusfilens bevis för den här.

Sekvensen jag kör på en live-server

Anslut, läs det aktuella tillståndet, agera på det ID du just läste och läs det sedan igen. Värden som kopierats från ett dokument är det vanligaste sättet att döda fel person.

status                     # note the client ID and common name
client-kill 3              # end that session now
kill Test-Client           # alternative: by common name
status                     # confirm the session is gone

Namnet och numret ovan är platshållare, och ID:n återanvänds efter att andra klienter har kopplat från. Bekräfta att raden saknas innan du skriver något som klart, och kontrollera att antalet anslutna klienter flyttades med ett och inte flera.

Bekräfta att den höll sig borta

Notera common name, tunneladressen, den yttre adressen och minuten för borttagningen. Om samma common name dyker upp igen en minut senare fungerade sessionsåtgärden men inte legitimeringslagret, vilket är en helt annan reparation än för ett kommando som aldrig fick effekt.

Testa sedan från klientsidan. Ett återkallat certifikat bör misslyckas i nästa handskakning; om det fortfarande ansluter läses CRL inte alls, och det är fyndet som är värt att rapportera. Välj åtgärden efter vad du måste avsluta, bekräfta med ett andra status och reparera legitimeringslagret när svaret måste hålla längre än sessionen.