Procedură: integrarea separată a doi clienți OpenVPN

Doi clienți pe o singură gazdă sună ca încă un bloc de server și un al doilea port. Devine alt proiect de îndată ce listezi tot ce deține cu adevărat un client: un ascultător, un pool de tuneluri, o identitate, fișiere de încredere, rute și un calendar de revocare. Sari peste unul dintre ele și al doilea client moștenește în tăcere o parte din primul. Construiește o fișă pentru fiecare client și completeaz-o înainte ca primul client să se conecteze.

Atribuie o fișă completă de resurse pentru fiecare client

Rezervă întregul set împreună: port public, subrețea de tunel, cale de configurare, destinație a jurnalelor, numele instanței de serviciu și dispozitivul. Numirea lor ca grup este ceea ce împiedică copia clasică a unui fișier funcțional care mai conține pool-ul sau interfața primului client. Valorile sunt exemple, nu porturi rezervate, așa că verifică ce folosește deja gazda. Un serviciu care pornește nu este același lucru cu un client complet.

Păstrează fișa lângă configurație și actualizeaz-o ori de câte ori se schimbă o valoare. Documentația care se îndepărtează de realitate este mai rea decât lipsa ei.

Păstrează materialul de încredere în interiorul fiecărui client

O autoritate emitentă separată pentru fiecare client face granița ușor de analizat și ține cheia de semnare departe de gazda expusă la internet. O rădăcină comună poate funcționa și ea, dar o ancoră comună nu transformă două servicii într-un singur domeniu de apartenență. Decide ce lanțuri acceptă fiecare ascultător și ce identități de client autorizează, apoi notează ambele. Nu scoate certificate dintr-un lanț prin încercări și erori până când ceva se conectează.

Cheia privată a serverului însuși aparține unui fișier protejat pentru fiecare client, nu unui director de șabloane replicat împreună cu configurația.

Separă rețelele la fel ca procesele

Două procese pe două porturi împart în continuare o gazdă și un tabel de rutare dacă nu le separi. Confirmă ce ascultă înainte de a avea încredere în proiect.

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

Verificarea ascultătorului arată ce proces deține fiecare port public, iar validarea arată dacă un certificat de client se înlănțuie la ancora dorită. Niciuna dintre ieșiri nu demonstrează că clientul lui A nu poate ajunge în subrețeaua lui B, așa că definește politica de sursă și destinație, rutele de retur și orice serviciu partajat în mod deliberat. Spațiile de nume de rețea sau containerele separă contexte de rutare și reduc amestecarea accidentală, dar nu sunt o graniță completă de chiriaș singure. Alege un mecanism de izolare mai puternic atunci când modelul de amenințare o cere.

Livrează revocarea înainte de predare

O implementare de certificate nu este completă până când revocarea nu are o cale de livrare. Verifică emitentul și fereastra de valabilitate a CRL ca parte a integrării.

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

Inspecția CRL raportează când a fost emisă lista și când expiră, iar starea serviciului confirmă că instanța care o citește rulează. Reîmprospătează lista conform calendarului politicii de emitere chiar și când nu s-a revocat nimic nou, deoarece un CRL expirat poate respinge fiecare client. Publică un fișier complet în loc să lași cititorii să întâlnească o scriere parțială, și validează semnătura înainte de implementare. Înregistrează cine deține emiterea, operarea punctului final și retragerea, astfel încât oprirea clientului A să nu îl deranjeze pe B.

Apoi rulează perechea de acceptare: un client permis ajunge la propriul serviciu, iar o acreditare a lui A este respinsă de ascultătorul lui B. Aceasta este granița exprimată ca test.