Udhëzues operativ: dy klientë OpenVPN të veçantë
Dy klientë në një host OpenVPN kanë nevojë për dëgjues, pool-e, skedarë besimi dhe dërgim të shfuqizimit të veçantë, bashkë me një test pranimi që i mban të ndarë.
Dy klientë në një host tingëllojnë si një bllok serveri më shumë dhe një port i dytë. Bëhet një projekt tjetër sapo renditni gjithçka që klienti zotëron në të vërtetë: një dëgjues, një pool tunelesh, një identitet, skedarë besimi, rrugë dhe një plan shfuqizimi. Lini jashtë një prej tyre dhe klienti i dytë trashëgon në heshtje një pjesë të të parit. Ndërtoni një kartë për çdo klient dhe plotësojeni përpara se klienti i parë të lidhet.
Caktoni një kartë të plotë burimesh për çdo klient
Rezervoni të gjithë grupin së bashku: port publik, nënrrjet tuneli, shteg konfigurimi, destinacion regjistrash, emri i instancës së shërbimit dhe pajisja. Emërtimi i tyre si grup është ajo që pengon kopjen klasike të një skedari funksional që ende përmban pool-in ose ndërfaqen e klientit të parë. Vlerat janë shembuj, jo porte të rezervuara, prandaj kontrolloni çfarë përdor tashmë hosti. Një shërbim që niset nuk është e njëjta gjë si një klient i plotë.
Mbajeni kartën pranë konfigurimit dhe përditësojeni sa herë që ndryshon një vlerë. Dokumentacioni që largohet nga realiteti është më keq se asnjë.
Mbajeni materialin e besimit brenda çdo klienti
Një autoritet lëshues i veçantë për çdo klient e bën kufirin të lehtë për t’u arsyetuar dhe mban çelësin e nënshkrimit larg hostit të ekspozuar ndaj internetit. Edhe një rrënjë e përbashkët mund të funksionojë, por një ankorë e përbashkët nuk i kthen dy shërbime në një domen të vetëm anëtarësie. Vendosni cilat zinxhirë pranon çdo dëgjues dhe cilat identitete klienti autorizon, pastaj shkruani të dyja. Mos i hiqni certifikatat nga një zinxhir me prova dhe gabime derisa diçka të lidhet.
Çelësi privat i vetë serverit i përket një skedari të mbrojtur për çdo klient, jo një drejtorie shabllonësh që replikohet bashkë me konfigurimin.
Ndani rrjetet ashtu si proceset
Dy procese në dy porte ende ndajnë një host dhe një tabelë rrugëtimi nëse nuk i ndani. Konfirmoni çfarë po dëgjon përpara se t’i besoni dizajnit.
ss -lunp | grep -E '1194|1195'
openssl verify -CAfile customer-a/ca.crt customer-a/client.pemKontrolli i dëgjuesit tregon cili proces zotëron çdo port publik, dhe verifikimi tregon nëse një certifikatë klienti zinxhirohet te ankora e synuar. Asnjë prej daljeve nuk provon që klienti i A nuk mund të arrijë nënrrjetin e B, prandaj përcaktoni politikën e burimit dhe destinacionit, rrugët e kthimit dhe çdo shërbim të ndarë me qëllim. Hapësirat e emrave të rrjetit ose kontejnerët ndajnë kontekstet e rrugëtimit dhe zvogëlojnë përzierjen aksidentale, por ato nuk janë një kufi i plotë qiradhënësi më vete. Zgjidhni një mekanizëm izolimi më të fortë kur modeli i kërcënimit e kërkon.
Dërgoni shfuqizimin përpara dorëzimit
Vendosja e certifikatave nuk është e plotë derisa shfuqizimi të ketë një rrugë dërgimi. Kontrolloni lëshuesin dhe dritaren e vlefshmërisë të CRL-së si pjesë e pranimit.
openssl crl -in customer-a/crl.pem -noout -lastupdate -nextupdate
systemctl status openvpn@customer-aInspektimi i CRL-së raporton kur lista u lëshua dhe kur skadon, dhe statusi i shërbimit konfirmon që instanca që e lexon është në punë. Rifreskoni listën sipas orarit të politikës së lëshimit edhe kur nuk është shfuqizuar asgjë e re, sepse një CRL e skaduar mund të refuzojë çdo klient. Publikoni një skedar të plotë në vend që t’i lini lexuesit të hasin një shkrim të pjesshëm, dhe validoni nënshkrimin përpara vendosjes. Regjistroni kush zotëron lëshimin, funksionimin e pikës fundore dhe tërheqjen, në mënyrë që fikja e klientit A të mos e shqetësojë B.
Pastaj ekzekutoni çiftin e pranimit: një klient i lejuar arrin shërbimin e vet, dhe një kredencial i A refuzohet nga dëgjuesi i B. Ky është kufiri i shprehur si test.