Draaiboek: twee OpenVPN-klanten apart onboarden

Twee klanten op één host klinkt als nog een serverblok en een tweede poort. Het wordt een ander project zodra je alles opnoemt wat een klant werkelijk bezit: een listener, een tunnelpool, een identiteit, vertrouwensbestanden, routes en een intrekkingsschema. Sla één daarvan over en de tweede klant erft stil een stuk van de eerste. Bouw een kaart per klant en vul die in voordat de eerste client verbindt.

Wijs per klant een complete resourcekaart toe

Reserveer de hele set samen: openbare poort, tunnelsubnet, configuratiepad, logbestemming, naam van de service-instantie en apparaat. Ze als groep benoemen is wat de klassieke kopie voorkomt van een werkend bestand dat nog de pool of interface van de eerste klant bevat. De waarden zijn voorbeelden, geen gereserveerde poorten, dus controleer wat de host al gebruikt. Een service die start is niet hetzelfde als een klant die compleet is.

Bewaar de kaart naast de configuratie en werk hem bij telkens wanneer een waarde verandert. Documentatie die van de werkelijkheid afdrijft is erger dan geen.

Houd vertrouwensmateriaal binnen elke klant

Een aparte uitgevende autoriteit per klant maakt de grens makkelijk te beredeneren en houdt de ondertekeningssleutel weg van de host die aan het internet blootstaat. Een gedeelde root kan ook werken, maar een gemeenschappelijk anker maakt van twee services nog geen enkel lidmaatschapsdomein. Bepaal welke ketens elke listener accepteert en welke clientidentiteiten hij autoriseert, en schrijf beide op. Strip geen certificaten uit een keten door vallen en opstaan tot er iets verbindt.

De eigen privésleutel van de server hoort in een beveiligd bestand per klant, niet in een sjabloonmap die met de configuratie wordt gerepliceerd.

Scheid de netwerken net als de processen

Twee processen op twee poorten delen nog steeds een host en een routingtabel, tenzij je ze scheidt. Bevestig wat er luistert voordat je het ontwerp vertrouwt.

ss -lunp | grep -E '1194|1195'
openssl verify -CAfile customer-a/ca.crt customer-a/client.pem

De listenercontrole laat zien welk proces elke openbare poort bezit, en de verificatie laat zien of een clientcertificaat naar het bedoelde anker ketent. Geen van beide uitvoer bewijst dat de client van A het subnet van B niet kan bereiken, dus definieer bron- en bestemmingsbeleid, retourroutes en elke bewust gedeelde service. Netwerknaamruimten of containers scheiden routeringscontexten en verminderen toevallige vermenging, maar ze zijn geen volledige tenantgrens op zichzelf. Kies een sterker isolatiemechanisme wanneer het dreigingsmodel dat vereist.

Lever intrekking vóór de overdracht

Een certificaatuitrol is niet compleet tot intrekking een leverpad heeft. Controleer de uitgever en het geldigheidsvenster van de CRL als onderdeel van het onboarden.

openssl crl -in customer-a/crl.pem -noout -lastupdate -nextupdate
systemctl status openvpn@customer-a

De CRL-inspectie meldt wanneer de lijst is uitgegeven en wanneer die verloopt, en de servicestatus bevestigt dat de instantie die hem leest draait. Vernieuw de lijst volgens de planning van het uitgeefbeleid, zelfs wanneer er niets nieuws is ingetrokken, want een verlopen CRL kan elke client weigeren. Publiceer een compleet bestand in plaats van lezers een gedeeltelijke schrijfactie te laten tegenkomen, en valideer de handtekening vóór de uitrol. Leg vast wie eigenaar is van uitgifte, endpointbeheer en uitfasering, zodat het uitschakelen van klant A B niet verstoort.

Voer daarna het acceptatiepaar uit: een toegestane client bereikt zijn eigen service, en een A-referentie wordt door de listener van B geweigerd. Dat is de grens als test uitgedrukt.