Körbok: två OpenVPN-kunder separat

Två kunder på en värd låter som ännu ett serverblock och en andra port. Det blir ett annat projekt så snart du listar allt en kund faktiskt äger: en lyssnare, en tunnelpool, en identitet, tillitsfiler, rutter och ett återkallningsschema. Hoppa över en av dem och den andra kunden ärver tyst en del av den första. Bygg ett kort per kund och fyll i det innan den första klienten ansluter.

Tilldela ett komplett resurskort per kund

Reservera hela uppsättningen tillsammans: publik port, tunnelnät, konfigurationsväg, loggmål, namn på tjänstinstansen och enhet. Det är namngivningen som grupp som hindrar den klassiska kopian av en fungerande fil som fortfarande innehåller den första kundens pool eller gränssnitt. Värdena är exempel, inte reserverade portar, så kontrollera vad värden redan använder. En tjänst som startar är inte samma sak som en kund som är komplett.

Förvara kortet bredvid konfigurationen och uppdatera det varje gång ett värde ändras. Dokumentation som glider ifrån verkligheten är värre än ingen.

Håll tillitsmaterial inuti varje kund

En separat utfärdande myndighet per kund gör gränsen lätt att resonera om och håller signeringsnyckeln borta från värden som vetter mot internet. En delad rot kan också fungera, men ett gemensamt ankare gör inte två tjänster till en enda medlemskapsdomän. Bestäm vilka kedjor varje lyssnare accepterar och vilka klientidentiteter den auktoriserar, och skriv ned båda. Ta inte bort certifikat från en kedja genom trial and error förrän något ansluter.

Serverns egen privata nyckel hör hemma i en skyddad fil per kund, inte i en mallkatalog som replikeras tillsammans med konfigurationen.

Separera näten likaväl som processerna

Två processer på två portar delar fortfarande en värd och en routingtabell om du inte separerar dem. Bekräfta vad som lyssnar innan du litar på designen.

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

Lyssnarkontrollen visar vilken process som äger varje publik port, och verifieringen visar om ett klientcertifikat kedjar till det avsedda ankaret. Ingen av utskrifterna bevisar att A:s klient inte kan nå B:s nät, så definiera käll- och målpolicy, returrutter och varje medvetet delad tjänst. Nätverksnamnrymder eller containrar separerar routingkontexter och minskar oavsiktlig blandning, men de är inte en fullständig hyresgästgräns i sig själva. Välj en starkare isoleringsmekanism när hotmodellen kräver det.

Leverera återkallningen före överlämningen

En certifikatutrullning är inte komplett förrän återkallningen har en leveransväg. Kontrollera CRL:ns utfärdare och giltighetsfönster som en del av introduktionen.

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

CRL-kontrollen rapporterar när listan utfärdades och när den löper ut, och tjänstestatusen bekräftar att instansen som läser den körs. Uppdatera listan enligt utfärdandepolicyens schema även när inget nytt har återkallats, eftersom en utgången CRL kan avvisa varje klient. Publicera en komplett fil i stället för att låta läsare möta en delvis skrivning, och validera signaturen före utrullning. Registrera vem som äger utfärdande, drift av slutpunkten och avveckling, så att avstängning av kund A inte stör B.

Kör sedan acceptansparet: en tillåten klient når sin egen tjänst, och en A-legitimation avvisas av B:s lyssnare. Det är gränsen uttryckt som ett test.