Je laptop is weg, en de VPN vermeldt hem nog steeds als client. De dringende vraag is niet hoe je het profiel verwijdert op een machine die je niet meer hebt, maar welke identiteit de server nog accepteert. WireGuard controleert een openbare sleutel, een PKI-gebaseerde OpenVPN configuratie controleert een clientcertificaat, en een VPN met SSO controleert een account en het sessietoken ervan. Die drie worden op verschillende plaatsen en met verschillende snelheid ingetrokken, en één repareren terwijl je de andere negeert is hoe een verloren apparaat verbonden blijft.

Drie identiteiten en wat elk ervan beheert

Elk mechanisme beantwoordt een andere vraag. Een peersleutel beantwoordt of dit de machine is die je hebt ingeschreven. Een certificaat beantwoordt of het door je CA is ondertekend en niet is ingetrokken. Een account beantwoordt of deze persoon recent genoeg heeft geauthenticeerd. Een uitrol die er twee stapelt, bijvoorbeeld certificaat plus directoryaanmelding, sluit de deur pas als tegen elke laag die het apparaat iets heeft uitgegeven is gezegd dat ze het niet meer mag accepteren.

De praktische valkuil is dat de ontbrekende machine de privéhelft van elk bewijsstuk bevat, dus niets wat je lokaal doet bereikt de server.

WireGuard: verwijder de peer, want er is geen intrekkingslijst

WireGuard houdt geen verbodslijst bij. De interface accepteert precies de openbare sleutels die als peer zijn geconfigureerd, dus intrekken is verwijderen: voer wg set wg0 peer <public-key> remove uit, de vorm die is gedocumenteerd in wg(8), en verwijder daarna het bijbehorende [Peer]-blok uit wg0.conf. Doe beide. Een verwijdering alleen tijdens runtime overleeft tot de volgende herstart of het opnieuw laden van de configuratie, waarna het bestand de sleutel terugzet.

Bestaande sessies hebben geen timer nodig om te sterven. Het verwijderen van de peer laat de handshake en het sleutelmateriaal vallen, dus verkeer stopt zodra weer een geldig sleutelpaar nodig is. Controleer wg show wg0 latest-handshakes op de server: de vermelding van de verloren sleutel hoort te verdwijnen en weg te blijven, terwijl de andere peers recente tijdvakken blijven melden.

Eén waarschuwing is belangrijker dan hij lijkt. Als het verloren apparaat een sleutel deelde met andere apparaten omdat iemand één configuratiebestand kopieerde, verbreekt het verwijderen van die sleutel ze allemaal; dat is nog steeds de juiste zet, en je geeft daarna sleutels per apparaat opnieuw uit in plaats van de gedeelde te herstellen.

Certificaten: een CRL telt alleen als de daemon hem leest

Toegang op basis van certificaten voegt een stap toe die mensen overslaan. easyrsa revoke laptop-01 markeert het certificaat als ingetrokken in de CA-database, maar de VPN leert niets uit die database. Daarna voer je easyrsa gen-crl uit om crl.pem te schrijven, kopieer je het naar het pad dat in de optie crl-verify van de server staat, en bevestig je dat de draaiende daemon het nieuwe bestand gebruikt. Intrekken zonder de CRL opnieuw te genereren en te verspreiden is zonder effect.

Timing is de tweede helft. Een CRL wordt geraadpleegd wanneer een client verbindt of opnieuw onderhandelt, dus een bestaande tunnel kan tot dan blijven doorsturen. Als het apparaat onmiddellijk moet worden afgesneden, beëindig die sessie dan expliciet via de beheerinterface van OpenVPN in plaats van te wachten op de volgende handshake. De dienst herladen of herstarten, afhankelijk van hoe de uitrol de CRL laadt, hoort bij de wijziging en is geen optionele extra.

Verificatie is de moeite waard vanaf een andere machine: presenteer het ingetrokken certificaat en verwacht een handshakefout, meestal VERIFY ERROR: depth=0, error=certificate revoked. Als de verbinding toch slaagt, leest de client een andere CRL dan degene die je hebt bijgewerkt.

Accounts en sessies: deactiveren is niet hetzelfde als eruit zetten

Directory- of SSO-aanmeldingen worden op het moment van authenticatie gecontroleerd. Het account deactiveren blokkeert de volgende aanmelding, maar het refreshtoken en de bestaande tunnel kunnen blijven werken tot ze verlopen. Trek de sessies en tokens van die gebruiker in, of verhoog een sessieversie als de identiteitsprovider dat ondersteunt. Verwijder het verloren apparaat ook uit de MFA-inschrijving, want een geregistreerde authenticator is op zichzelf een toegangsweg.

RADIUS-gebaseerde VPN's kunnen een verbrekingsbericht of een autorisatiewijziging sturen om een actieve sessie te laten vallen, maar niet elke netwerktoegangsserver respecteert dat. Bij twijfel beëindig je de sessie van de gebruiker aan de serverkant en bevestig je in de logs dat de oude sessie is gesloten.

Volgorde van handelingen voor het komende uur

Begin bij de inventaris, niet bij de client: lijst elke identiteit op die aan het apparaat is gekoppeld, of dat nu peersleutel, certificaatserienummer of account is. Trek in elk uitgevend systeem in volgens de volgorde waarin de verbinding wordt opgebouwd, dus eerst account, dan certificaat, dan peer. Bewijs daarna de weigering vanaf een machine die je beheert.

Twee vervolgstappen worden makkelijk vergeten. Ten eerste draai je alles wat het apparaat nog had, vooral SSH-sleutels, cloudconsole-gegevens en een gedeelde vooraf gedeelde WireGuard-sleutel. Ten tweede controleer je of configuratiebeheer, snapshots of gouden images de verwijderde client bij de volgende herbouw niet opnieuw kunnen binnenhalen.

De duurzame oplossing is één identiteit per apparaat. Wanneer elke laptop zijn eigen peersleutel of certificaat draagt, kost een verlies één intrekkingscommando en een heruitgifte in plaats van een herbouw van de hele vloot.

Gerelateerde artikelen