Runbook: to OpenVPN-kunder hver for sig

To kunder på én vært lyder som endnu en serverblok og endnu en port. Det bliver et andet projekt, når du oplister alt, hvad en kunde faktisk ejer: en lytter, en tunnelpool, en identitet, tillidsfiler, ruter og en tilbagekaldelsesplan. Springer du én af dem over, arver den anden kunde stille en del af den første. Byg et kort pr. kunde, og udfyld det, før den første klient forbinder.

Tildel et komplet ressourcekort pr. kunde

Reservér hele sættet samlet: offentlig port, tunnelsubnet, konfigurationssti, logdestination, tjenesteinstansens navn og enhed. Det er navngivningen som gruppe, der forhindrer den klassiske kopi af en fungerende fil, som stadig indeholder den første kundes pool eller interface. Værdierne er eksempler, ikke reserverede porte, så kontroller, hvad værten allerede bruger. En tjeneste, der starter, er ikke det samme som en kunde, der er komplet.

Opbevar kortet ved siden af konfigurationen, og opdater det, hver gang en værdi ændres. Dokumentation, der driver væk fra virkeligheden, er værre end ingen.

Hold tillidsmateriale inde i hver kunde

En separat udstedende myndighed pr. kunde gør grænsen let at resonere om og holder signeringsnøglen væk fra værten, der vender mod internettet. En delt rod kan også fungere, men et fælles anker gør ikke to tjenester til ét medlemskabsdomæne. Beslut, hvilke kæder hver lytter accepterer, og hvilke klientidentiteter den autoriserer, og skriv begge ned. Fjern ikke certifikater fra en kæde ved forsøg og fejl, indtil noget forbinder.

Serverens egen private nøgle hører til i en beskyttet fil pr. kunde, ikke i en skabelonmappe, der replikeres sammen med konfigurationen.

Adskil netværkene såvel som processerne

To processer på to porte deler stadig en vært og en routingtabel, medmindre du adskiller dem. Bekræft, hvad der lytter, før du stoler på designet.

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

Lytterkontrollen viser, hvilken proces der ejer hver offentlig port, og verifikationen viser, om et klientcertifikat kæder til det tilsigtede anker. Ingen af outputtene beviser, at A’s klient ikke kan nå B’s subnet, så definer kilde- og destinationspolitik, returruter og enhver bevidst delt tjeneste. Netværksnavnerum eller containere adskiller routingkontekster og reducerer utilsigtet sammenblanding, men de er ikke en komplet lejergrænse i sig selv. Vælg en stærkere isoleringsmekanisme, når trusselsmodellen kræver det.

Lever tilbagekaldelse før overdragelse

En certifikatudrulning er ikke komplet, før tilbagekaldelse har en leveringsvej. Kontroller CRL’ens udsteder og gyldighedsvindue som en del af onboarding.

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

CRL-inspektionen rapporterer, hvornår listen blev udstedt, og hvornår den udløber, og tjenestestatus bekræfter, at den instans, der læser den, kører. Opdater listen efter udstedelsespolitikkens tidsplan, selv når intet nyt er tilbagekaldt, fordi en udløbet CRL kan afvise hver klient. Publicér en komplet fil i stedet for at lade læsere møde en delvis skrivning, og valider signaturen før udrulning. Registrér, hvem der ejer udstedelse, drift af endepunkt og nedlæggelse, så nedlukning af kunde A ikke forstyrrer B.

Kør derefter acceptparret: en tilladt klient når sin egen tjeneste, og en A-legitimation afvises af B’s lytter. Det er grænsen udtrykt som en test.