Eén OpenVPN-client eruit trappen: kill, deny of een certificaat intrekken?

Je hebt een common name en een adres in je notities, en drie commando's die allemaal een client lijken te verwijderen. Slechts één doet wat je wilt, en de keuze hangt ervan af of je de nu lopende sessie moet beëindigen, de volgende login moet weigeren of het recht om te verbinden helemaal moet afnemen. Lees de identiteit die je werkelijk hebt voordat je iets aanraakt, want een OpenVPN-pool geeft hetzelfde tunneladres later aan een andere sessie.

Welke identiteit je werkelijk hebt

Een statusbestand van versie 3 is het gebruikelijke startpunt. De sectie CLIENT_LIST bevat de common name, het echte adres, bytetellers en verbindingstijd; de sectie ROUTING TABLE koppelt een virtueel adres aan een common name met een tijdstempel van de laatste verwijzing. De common name is de stabiele identiteit. Het virtuele adres is een toewijzing, en het echte adres achter een NAT kan tussen sessies veranderen zonder dat er iets op de server verandert.

De beheerinterface toont een vergelijkbaar beeld via zijn commando status en voegt per sessie een client-ID toe. Die ID verwacht client-kill, en het is niet het tunneladres. Als je wilt weten welke common name bij het verbinden welk adres kreeg, heeft de omgeving van een client-connect-script beide, samen met het vertrouwde buitenadres, maar dat script draait als de OpenVPN-gebruiker en heeft een beschrijfbaar logpad nodig.

Nu doden, weigeren bij het inloggen, voorgoed intrekken

Beide verwijdercommando's in de beheerinterface zijn sessieacties. kill neemt een common name of een echt adres en poort; client-kill neemt de client-ID en beëindigt die instantie onmiddellijk. Geen van beide is een blokkade: een eruit getrapte client met een geldig certificaat en wachtwoord verbindt binnen seconden opnieuw, wat prima is als je een testpeer hergebruikt en nutteloos als een laptop is gestolen.

client-deny is een ander soort beslissing. Het wordt meestal uitgegeven vanuit een authenticatie- of client-connect-hook en weigert de sessie met een reden, dus het past bij een beleid dat een login weigert in plaats van een dat een verbinding onderbreekt. De documentatie waarschuwt ook dat een weigering tijdens een TLS-heronderhandeling de opnieuw onderhandelde sleutel ongeldig maakt, terwijl de bestaande sessie kan doorlopen tot het overgangsvenster sluit. Als de eis is dat de client er nu weg is, is het gedocumenteerde antwoord client-kill.

Duurzaam verwijderen ligt onder dit alles. Trek het certificaat in en zorg dat crl-verify naar een lijst wijst die de server echt opnieuw laadt, schakel het clientspecifieke configuratiebestand in de ccd-map uit, of schakel het account uit in de backend die de authenticatie-hook bevraagt. Een intrekking is ook niet direct: met de standaardinstellingen van reneg-sec kan een bestaande sessie doorlopen tot die opnieuw onderhandelt, dus de sessieactie en de credentialactie vullen elkaar aan, het zijn geen alternatieven.

Is de beheersocket vrij?

De beheerinterface bedient één client tegelijk. Als een GUI of een monitoringdaemon de verbinding al vasthoudt, kan je script zich er niet naast aansluiten, en afhankelijk van de client kun je de bestaande eruit werken in plaats van netjes te falen. Het wachtwoord reist in platte tekst over die socket, dus het hoort op een lokaal adres of een unix-socket, nooit op een openbare interface.

Als je de socket niet kunt overnemen, heb je nog opties, en die zijn allemaal langzamer. Laat eerst de sessie van de GUI los als je die beheert, of accepteer de route via de credentiallaag en wacht op de volgende heronderhandeling. Wat je niet moet doen is de dienst herstarten om één client kwijt te raken, want dat beëindigt ook elke andere sessie en vernietigt het statusbestand als bewijs voor deze.

De volgorde die ik op een live server draai

Verbind, lees de huidige toestand, handel op de ID die je net hebt gelezen en lees die daarna opnieuw. Waarden die uit een document zijn gekopieerd, zijn de meest voorkomende manier om de verkeerde persoon te doden.

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

De naam en het nummer hierboven zijn plaatsaanduidingen, en ID's worden hergebruikt nadat andere clients zijn losgekoppeld. Bevestig dat de rij ontbreekt voordat je iets als gedaan opschrijft, en controleer dat het aantal verbonden clients met één verschoof en niet met meerdere.

Bevestig dat hij wegbleef

Noteer de common name, het tunneladres, het buitenadres en de minuut van verwijdering. Als dezelfde common name een minuut later weer verschijnt, werkte de sessieactie en niet de credentiallaag, wat een heel andere reparatie is dan een commando dat nooit effect had.

Test daarna vanaf de clientkant. Een ingetrokken certificaat hoort de volgende handshake te falen; als het nog verbindt, wordt de CRL helemaal niet gelezen, en dat is de bevinding die het melden waard is. Kies de actie op wat je moet beëindigen, bevestig met een tweede status, en repareer de credentiallaag wanneer het antwoord langer moet duren dan de sessie.