Runbook: to OpenVPN-kunder tatt inn hver for seg

To kunder på én vert høres ut som én serverblokk til og en annen port. Det blir et annet prosjekt når du lister opp alt en kunde faktisk eier: en lytter, en tunnelpulje, en identitet, tillitsfiler, ruter og en tilbakekallingsplan. Hopper du over én av dem, arver den andre kunden stille en del av den første. Lag et kort per kunde og fyll det ut før den første klienten kobler til.

Tildel et fullstendig ressurskort per kunde

Reserver hele settet samlet: offentlig port, tunnelsubnett, konfigurasjonssti, loggdestinasjon, navnet på tjenesteinstansen og enhet. Det er navngivningen som gruppe som forhindrer den klassiske kopien av en fungerende fil som fortsatt inneholder den første kundens pulje eller grensesnitt. Verdiene er eksempler, ikke reserverte porter, så sjekk hva verten allerede bruker. En tjeneste som starter er ikke det samme som en kunde som er komplett.

Oppbevar kortet ved siden av konfigurasjonen og oppdater det hver gang en verdi endres. Dokumentasjon som driver bort fra virkeligheten er verre enn ingen.

Hold tillitsmateriale inne i hver kunde

En separat utstedende myndighet per kunde gjør grensen lett å resonnere om og holder signeringsnøkkelen borte fra verten som vender mot internett. En delt rot kan også fungere, men et felles anker gjør ikke to tjenester til ett medlemskapsdomene. Bestem hvilke kjeder hver lytter godtar og hvilke klientidentiteter den autoriserer, og skriv ned begge. Ikke fjern sertifikater fra en kjede ved prøving og feiling før noe kobler til.

Serverens egen private nøkkel hører hjemme i en beskyttet fil per kunde, ikke i en malmappe som replikeres sammen med konfigurasjonen.

Skill nettverkene like godt som prosessene

To prosesser på to porter deler fortsatt en vert og en rutetabell med mindre du skiller dem. Bekreft hva som 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 prosess som eier hver offentlig port, og verifiseringen viser om et klientsertifikat kjeder til det tiltenkte ankeret. Ingen av utdataene beviser at A sin klient ikke kan nå B sitt subnett, så definer kilde- og målpolitikk, returruter og enhver bevisst delt tjeneste. Nettverksnavnerom eller containere skiller rutekontekster og reduserer utilsiktet blanding, men de er ikke en fullstendig leietakergrense i seg selv. Velg en sterkere isolasjonsmekanisme når trusselmodellen krever det.

Lever tilbakekallingen før overlevering

En sertifikatutrulling er ikke komplett før tilbakekallingen har en leveringsvei. Kontroller CRL-ens utsteder og gyldighetsvindu som en del av innføringen.

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

CRL-kontrollen rapporterer når listen ble utstedt og når den utløper, og tjenestestatusen bekrefter at instansen som leser den kjører. Oppdater listen etter utstedelsespolitikkens tidsplan selv når ingenting nytt er tilbakekalt, fordi en utløpt CRL kan avvise hver klient. Publiser en komplett fil i stedet for å la lesere møte en delvis skriving, og valider signaturen før utrulling. Registrer hvem som eier utstedelse, drift av endepunktet og avvikling, slik at nedstenging av kunde A ikke forstyrrer B.

Kjør deretter akseptparet: en tillatt klient når sin egen tjeneste, og en A-legitimasjon avvises av B sin lytter. Det er grensen uttrykt som en test.