Spark en OpenVPN-klient ut: kill, deny eller tilbakekall et sertifikat?
Tre OpenVPN-handlinger fjerner en klient, men hver avslutter noe annet: en levende sesjon, ett innloggingsforsøk eller retten til å koble til på nytt. Velg etter identitet.
Du har et common name og en adresse i notatene dine, og tre kommandoer som alle ser ut til å fjerne en klient. Bare én gjør det du vil, og valget avhenger av om du må avslutte sesjonen som kjører nå, avvise neste innlogging eller ta retten til å koble til helt bort. Les identiteten du faktisk har før du rører noe, fordi en OpenVPN-pool gir samme tunneladresse til en annen sesjon senere.
Hvilken identitet du faktisk har
En statusfil i versjon 3 er det vanlige utgangspunktet. CLIENT_LIST-delen bærer common name, den ekte adressen, byttetellere og tilkoblingstid; ROUTING TABLE-delen knytter en virtuell adresse til et common name med tidsstempel for siste referanse. Common name er den stabile identiteten. Den virtuelle adressen er en tildeling, og den ekte adressen bak en NAT kan endre seg mellom sesjoner uten at noe på serveren endres.
Styringsgrensesnittet viser et lignende bilde gjennom kommandoen status og legger til en klient-ID per sesjon. Det er den ID-en client-kill forventer, og det er ikke tunneladressen. Hvis du må vite hvilket common name som fikk hvilken adresse ved tilkobling, har miljøet til et client-connect-skript begge, sammen med den klarerte ytre adressen, men det skriptet kjører som OpenVPN-bruker og trenger en skrivbar loggsti.
| 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 |
Drep nå, avvis ved innlogging, tilbakekall for godt
Begge fjerningskommandoene i styringsgrensesnittet er sesjonshandlinger. kill tar et common name eller en ekte adresse og port; client-kill tar klient-ID-en og avslutter den instansen umiddelbart. Ingen av dem er en blokkering: en utsparket klient med gyldig sertifikat og passord kobler til igjen i løpet av sekunder, noe som er greit når du resirkulerer en testpeer og ubrukelig når en bærbar PC er stjålet.
client-deny er en annen type beslutning. Det utstedes vanligvis fra en autentiserings- eller client-connect-krok og avviser sesjonen med en grunn, så det passer til en policy som avviser en innlogging snarere enn en som avbryter en tilkobling. Dokumentasjonen advarer også om at en avvisning utstedt under en TLS-reforhandling ugyldiggjør den reforhandlede nøkkelen mens den eksisterende sesjonen kan fortsette til overgangsvinduet lukkes. Hvis kravet er at klienten er borte nå, er det dokumenterte svaret client-kill.
Varig fjerning ligger under alt dette. Tilbakekall sertifikatet og sørg for at crl-verify peker på en liste serveren faktisk laster inn på nytt, slå av klientens spesifikke konfigurasjonsfil i ccd-mappen, eller slå av kontoen i den backenden autentiseringskroken spør. En tilbakekalling er heller ikke umiddelbar: med standardinnstillingene for reneg-sec kan en etablert sesjon fortsette til den reforhandler, så sesjonshandlingen og legitimasjonshandlingen utfyller hverandre, de er ikke alternativer.
Er styringssokkelen ledig?
Styringsgrensesnittet betjener én klient om gangen. Hvis et GUI eller en overvåkingsdaemon allerede holder tilkoblingen, kan ikke skriptet ditt koble seg ved siden av, og avhengig av klienten kan du kaste ut den eksisterende i stedet for å feile pent. Passordet reiser i klartekst på den sokkelen, så det hører til på en lokal adresse eller en unix-sokkel, aldri på et offentlig grensesnitt.
Når du ikke kan ta sokkelen, har du fortsatt valg, og alle er tregere. Slipp sesjonen til GUI-et først hvis du kontrollerer det, eller godta veien over legitimasjonslaget og vent på neste reforhandling. Det du ikke bør gjøre, er å starte tjenesten på nytt for å bli kvitt én klient, fordi det avslutter alle andre sesjoner også og ødelegger beviset i statusfilen for denne.
Rekkefølgen jeg kjører på en levende server
Koble til, les gjeldende tilstand, handle på ID-en du nettopp leste, og les den så igjen. Verdier kopiert fra et dokument er den vanligste måten å drepe feil 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 plassholdere, og ID-er brukes på nytt etter at andre klienter har koblet fra. Bekreft at raden mangler før du skriver noe som gjort, og kontroller at antallet tilkoblede klienter flyttet seg med én og ikke flere.
Bekreft at den ble borte
Noter common name, tunneladressen, den ytre adressen og minuttet for fjerningen. Hvis det samme common name dukker opp igjen et minutt senere, virket sesjonshandlingen og ikke legitimasjonslaget, noe som er en helt annen reparasjon enn en kommando som aldri fikk virkning.
Test deretter fra klientsiden. Et tilbakekalt sertifikat bør feile i neste håndtrykk; hvis det fortsatt kobler til, blir CRL ikke lest i det hele tatt, og det er funnet som er verdt å melde. Velg handlingen etter hva du må avslutte, bekreft med en andre status, og rett legitimasjonslaget når svaret må vare lenger enn sesjonen.