Spark en OpenVPN-klient ud: dræb, afvis eller tilbagekald et certifikat?
Tre OpenVPN-handlinger fjerner en klient, men hver især afslutter noget forskelligt: en live session, et enkelt login-forsøg eller retten til at genoprette forbindelsen. Vælg efter identitet.
Du har et common name og en adresse i dine noter, og tre kommandoer der alle ser ud til at fjerne en klient. Kun én af dem gør det, du vil, og valget afhænger af, om du skal afslutte den session, der kører nu, afvise det næste login eller fjerne retten til at forbinde overhovedet. Læs den identitet, du faktisk har, før du rører noget, fordi en OpenVPN-pool giver den samme tunneladresse til en anden session senere.
Hvilken identitet du faktisk har
En statusfil i version 3 er det sædvanlige udgangspunkt. CLIENT_LIST-afsnittet indeholder common name, den rigtige adresse, byttetællere og forbindelsestid; ROUTING TABLE-afsnittet knytter en virtuel adresse til et common name med et tidsstempel for sidste reference. Common name er den stabile identitet. Den virtuelle adresse er en tildeling, og den rigtige adresse bag en NAT kan skifte mellem sessioner, uden at noget på serveren ændrer sig.
Styringsgrænsefladen viser et lignende billede gennem sin status-kommando og tilføjer et klient-ID for hver session. Det ID er det, client-kill forventer, og det er ikke tunneladressen. Hvis du skal vide, hvilket common name der fik hvilken adresse ved forbindelsen, har miljøet for et client-connect-script begge dele sammen med den betroede ydre adresse, men det script kører som OpenVPN-brugeren og har brug for en skrivbar logsti.
| What you hold | Where it came from | What it can act on |
|---|---|---|
| Common name | CLIENT_LIST, or the auth hook | kill, and credential revocation |
| Client ID | status on the management socket | client-kill, that one session |
| Tunnel address | ROUTING TABLE, client-connect environment | Nothing durable, the address is recycled |
Dræb nu, afvis ved login, tilbagekald for bestandigt
Begge fjernelseskommandoer i styringsgrænsefladen er sessionhandlinger. kill tager et common name eller en rigtig adresse og port; client-kill tager klient-ID'et og afslutter den instans med det samme. Ingen af dem er en blokering: en udsparket klient med et gyldigt certifikat og kodeord forbinder igen inden for sekunder, hvilket er fint, når du genbruger en testpeer, og ubrugeligt, når en bærbar er blevet stjålet.
client-deny er en anden slags beslutning. Den udstedes normalt fra et authentication- eller client-connect-hook og afviser sessionen med en begrundelse, så den passer til en politik, der afviser et login snarere end en, der afbryder en forbindelse. Dokumentationen advarer også om, at en afvisning udstedt under en TLS-renegociering ugyldiggør den renegocierede nøgle, mens den eksisterende session kan køre, indtil overgangsvinduet lukker. Hvis kravet er, at klienten er væk nu, er det dokumenterede svar client-kill.
Varig fjernelse ligger under alt dette. Tilbagekald certifikatet, og sørg for at crl-verify peger på en liste, som serveren faktisk genindlæser, deaktiver klientens specifikke konfigurationsfil i ccd-mappen, eller deaktiver kontoen i det backend, som authentication-hooket forespørger. En tilbagekaldelse er heller ikke øjeblikkelig: med standardindstillinger for reneg-sec kan en etableret session fortsætte, indtil den renegocierer, så sessionhandlingen og legitimationshandlingen supplerer hinanden, de er ikke alternativer.
Er styringsstikket ledigt?
Styringsgrænsefladen betjener én klient ad gangen. Hvis en GUI eller en overvågningsdaemon allerede holder forbindelsen, kan dit script ikke koble sig ved siden af, og afhængigt af klienten kan du smide den eksisterende ud i stedet for at fejle pænt. Dens adgangskode rejser i klartekst på det stik, så den hører til på en lokal adresse eller et unix-stik, aldrig på en offentlig grænseflade.
Når du ikke kan tage stikket, har du stadig muligheder, og de er alle langsommere. Slip først GUI'ens session, hvis du styrer den, eller accepter ruten over legitimationslaget og vent på den næste renegociering. Det, du ikke bør gøre, er at genstarte tjenesten for at komme af med én klient, fordi det også afslutter alle andre sessioner og ødelægger statusfilens bevis for denne.
Den rækkefølge, jeg kører på en live server
Kobl til, læs den aktuelle tilstand, handl på det ID, du lige har læst, og læs det så igen. Værdier kopieret fra et dokument er den mest almindelige måde at dræbe den forkerte person på.
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 goneNavnet og nummeret ovenfor er pladsholdere, og ID'er genbruges, efter at andre klienter er koblet fra. Bekræft, at rækken er væk, før du skriver noget ned som gjort, og kontroller, at antallet af tilsluttede klienter flyttede sig med én frem for flere.
Bekræft, at den blev væk
Notér common name, tunneladressen, den ydre adresse og tidspunktet for fjernelsen. Hvis det samme common name dukker op igen et minut senere, virkede sessionhandlingen, og legitimationslaget gjorde ikke, hvilket er en helt anden reparation end en kommando, der aldrig fik virkning.
Test derefter fra klientsiden. Et tilbagekaldt certifikat bør fejle det næste handshake; hvis det stadig forbinder, bliver CRL slet ikke læst, og det er den observation, der er værd at rapportere. Vælg handlingen efter, hvad du skal afslutte, bekræft med en anden status, og ret legitimationslaget, når svaret skal holde længere end sessionen.