Runbok: to OpenVPN-kundar tekne inn kvar for seg

To kundar på éin vert høyrest ut som ein serverblokk til og ein annan port. Det blir eit anna prosjekt når du listar opp alt ein kunde faktisk eig: ein lyttar, ein tunnelpulje, ein identitet, tillitsfiler, ruter og ein tilbakekallingsplan. Hoppar du over éin av dei, arvar den andre kunden stille ein del av den første. Lag eit kort per kunde og fyll det ut før den første klienten koplar til.

Tildel eit fullstendig ressurskort per kunde

Reserver heile settet saman: offentleg port, tunnelsubnett, konfigurasjonssti, loggmål, namnet på tenesteinstansen og eining. Det er namngjevinga som gruppe som hindrar den klassiske kopien av ei fungerande fil som framleis inneheld puljen eller grensesnittet til den første kunden. Verdiane er døme, ikkje reserverte portar, så sjekk kva verten alt brukar. Ei teneste som startar er ikkje det same som ein kunde som er fullstendig.

Oppbevar kortet ved sida av konfigurasjonen og oppdater det kvar gong ein verdi blir endra. Dokumentasjon som driv bort frå røyndomen er verre enn ingen.

Hald tillitsmateriale inne i kvar kunde

Ei separat utferdande styresmakt per kunde gjer grensa lett å resonnere om og held signeringsnøkkelen borte frå verten som vender mot internett. Ei delt rot kan også fungere, men eit felles anker gjer ikkje to tenester til eitt medlemskapsdomene. Bestem kva kjeder kvar lyttar godtek og kva klientidentitetar han autoriserer, og skriv ned begge. Ikkje fjern sertifikat frå ei kjede ved prøving og feiling før noko koplar til.

Den private nøkkelen til serveren sjølv høyrer heime i ei verna fil per kunde, ikkje i ei malmappe som blir replikert saman med konfigurasjonen.

Skil netta like godt som prosessane

To prosessar på to portar deler framleis ein vert og ei rutetabell med mindre du skil dei. Stadfest kva som lyttar før du stolar på designet.

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

Lyttarkontrollen viser kva prosess som eig kvar offentleg port, og verifiseringa viser om eit klientsertifikat kjeder til det tiltenkte ankeret. Ingen av utdataa beviser at klienten til A ikkje kan nå subnettet til B, så definer kjelde- og målpolitikk, returruter og kvar medvite delt teneste. Nettverksnamnerom eller containerar skil rutekontekstar og reduserer utilsikta blanding, men dei er ikkje ei fullstendig leigetakargrense i seg sjølv. Vel ein sterkare isolasjonsmekanisme når trugselmodellen krev det.

Lever tilbakekallinga før overlevering

Ein sertifikatutrulling er ikkje komplett før tilbakekallinga har ein leveringsveg. Kontroller utferdar og gyldigheitsvindauge for CRL-en som ein del av innføringa.

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

CRL-kontrollen rapporterer når lista vart utferda og når ho går ut, og tenestestatusen stadfestar at instansen som les ho køyrer. Oppdater lista etter tidsplanen til utferdarpolitikken sjølv når ingenting nytt er tilbakekalla, fordi ein utlopen CRL kan avvise kvar klient. Publiser ei fullstendig fil i staden for å la lesarar møte ei delvis skriving, og valider signaturen før utrulling. Registrer kven som eig utferding, drift av endepunktet og avvikling, slik at nedstenging av kunde A ikkje forstyrrar B.

Køyr deretter akseptparet: ein tillaten klient når si eiga teneste, og ein A-legitimasjon blir avvist av lyttaren til B. Det er grensa uttrykt som ein test.