Poate o legătură OpenVPN cu cheie statică să deservească mai mulți clienți?

Modul cu cheie statică conectează exact doi parteneri egali, iar aceasta este construcția lui, nu o limitare pe care cineva a uitat să o ridice. client-to-client este o opțiune de redirecționare din modul server, așa că adăugarea ei într-o configurație --secret nu schimbă nimic în privința numărului de clienți care se pot conecta. Decizia nu este ce indicator să adăugăm, ci dacă implementarea are nevoie de o legătură punct la punct sau de un serviciu pentru mai mulți clienți. Dacă mai multe dispozitive trebuie să se conecteze independent, modul de protecție se schimbă și fiecare dispozitiv primește o identitate.

Doi parteneri, o cheie și nicio stare pentru fiecare client: această formă este toată povestea modului.

Pentru ce este modul cu cheie statică

În modul secret, ambii parteneri împart un singur fișier de cheie, iar cheia respectivă protejează direct traficul. Nu există strângere de mână, nici schimb de certificate și nicio sesiune pentru fiecare client, pentru că nu există clienți în sensul de server, doar două puncte finale.

Modul rămâne util pentru o pereche fixă de mașini cu un proces documentat de rotație a cheilor, iar OpenVPN 2.6 îl marchează ca învechit tocmai pentru că modul TLS acoperă acele cazuri cu proprietăți mai bune. Ce nu poate face este să distingă un dispozitiv care se conectează de altul, deoarece deținerea fișierului este întreaga poveste a autentificării. Adăugarea unui al treilea dispozitiv înseamnă partajarea aceleiași chei cu el, după care primele două nu mai pot să îl distingă de ele însele.

De aceea limita de doi parteneri este structurală și nu o setare care poate fi schimbată.

De ce client-to-client nu este piesa lipsă

client-to-client controlează dacă clienții conectați pot schimba trafic prin server. Nu admite clienți, nu atribuie identități și nu creează un mod server care nu a fost configurat, iar într-o configurație cu cheie statică nu există o listă de clienți pe care să o guverneze.

Cealaltă confuzie obișnuită privește materialul tls-crypt sau tls-auth. Un server TLS poate partaja una dintre acele chei între toți clienții, pentru că protejează canalul de control în loc să dovedească cine este fiecare client. O cheie partajată de canal de control în modul TLS este un obiect diferit de o cheie de date statică partajată, deși ambele sosesc ca fișiere care arată similar.

Alegerea între moduri se reduce la două întrebări. Mai mult de un dispozitiv trebuie să se conecteze independent, iar implementarea are nevoie de revocare pentru fiecare dispozitiv? Un nu la ambele menține viabil modul cu cheie statică; un da la oricare dintre ele indică TLS. Nu există o a treia opțiune în care un al doilea client este admis fără propria identitate.

Construirea serverului pentru mai mulți clienți

Un server pentru mai mulți clienți are nevoie de modul TLS, de un certificat pe partea serverului și de o identitate pentru fiecare client. Asistentul de server configurează grupul de adrese și modul pentru mai mulți clienți, dar nu furnizează configurația TLS, ancora de încredere sau certificatele de client care fac admiterea semnificativă.

Înregistrați fiecare dispozitiv prin autoritatea de certificare existentă în loc să copiați acreditările unui singur client. Identitățile distincte sunt ceea ce face posibile revocarea, rutarea pentru fiecare client și jurnalele utile, iar un singur certificat de client partajat le prăbușește pe toate trei.

Dacă implementarea autentifică utilizatorii printr-un director extern sau un al doilea factor, acel design rămâne așa cum este. Trecerea la modul server TLS decide cum partenerii se dovedesc la nivelul tunelului și nu dictează backendul conturilor. Țineți cele două decizii separate, astfel încât o schimbare într-una să nu o modifice în tăcere pe cealaltă.

Apoi decideți deliberat politica de redirecționare. client-to-client activează traficul între clienți pe calea serverului în spațiul utilizatorului, ceea ce multe implementări doresc și unele nu trebuie să aibă. Este un comutator de politică, nu un mecanism de identitate, și ar trebui activat pentru că designul îl cere, nu pentru că un tutorial l-a inclus.

Verificarea că clienții sunt într-adevăr independenți

Conectați doi clienți și confirmați că primesc adrese diferite și apar cu identități diferite în jurnalul serverului. Apoi revocați unul și confirmați că celălalt continuă să funcționeze, ceea ce este testul practic că identitățile nu au fost partajate.

Testați serviciul permis între parteneri și unul care ar trebui să rămână blocat. Două autentificări reușite dovedesc admiterea, nu izolarea, iar diferența contează când implementarea ar trebui să separe grupuri de utilizatori.

În final, citiți modul server din configurația care rulează, nu din memorie. O configurație cu cheie statică și opțiuni suplimentare rămâne o legătură punct la punct, iar un server TLS corect este singura aranjare în care mai mulți clienți sunt parteneri cu adevărat separați.

Dacă jurnalul arată un singur nume comun pentru fiecare dispozitiv, problema nu este modul. Problema este procesul de înregistrare.