duplicate-cn dă două dispozitive o singură identitate, nu două

Copiați profilul pe tabletă, conectați-vă, și laptopul cade. Adăugați duplicate-cn, ambele rămân conectate, și problema pare rezolvată până când cele două dispozitive se ceartă pe aceeași adresă de tunel sau o tabletă pierdută scoate offline întregul cont. Opțiunea schimbă un singur lucru: dacă serverul permite o a doua sesiune sub un nume pe care l-a văzut deja. Tot ce oamenii se așteaptă să repare, de la independența dispozitivelor la adresarea pe dispozitiv și revocarea selectivă, se face în continuare prin identitate, iar identitatea aici este certificatul.

Mitul: o a doua sesiune este o a doua identitate

Intuiția spune că două conexiuni trebuie să fie doi clienți, iar doi clienți ar trebui să fie două dispozitive cu drepturi proprii. Serverul nu modelează astfel. Vede un nume comun și, cu duplicate-cn activat, acceptă mai mult de o sesiune activă cu acel nume, fiecare primind propriul statut de sesiune în daemon.

Nimic din acea acceptare nu atinge verificarea certificatului. Același certificat rămâne acreditarea, aceeași cheie rămâne cheia privată, iar orice politică bazată pe subiectul certificatului se rezolvă în continuare de două ori la aceeași valoare. O a doua sesiune este un al doilea socket, nu o a doua identitate.

Această distincție este invizibilă cât timp totul funcționează. Devine foarte vizibilă în momentul în care trebuie să distingeți cele două dispozitive, care este de obicei ziua în care unul dintre ele se pierde.

Ce se schimbă cu adevărat când două sesiuni împart un nume

Fără opțiune, o conexiune nouă sub un nume comun deja conectat o înlocuiește pe cea anterioară. De aceea laptopul cade când tableta se conectează, iar aceasta este o protecție deliberată împotriva ambiguității, nu un defect. Cu opțiunea, ambele sesiuni rămân active, iar serverul le urmărește separat pe sesiune, nu pe dispozitiv.

Fiecare sesiune primește în continuare propria conexiune exterioară și propriile chei negociate, deci debitul simultan este cu adevărat simultan. Ceea ce împart este tot ce derivă din acreditare: căutări de politică, configurare specifică clientului, identitate în jurnale și revocare. Starea sesiunii aparține conexiunii și moare cu ea, în timp ce faptele la nivel de acreditare persistă pentru ambele. De aceea ieșirea de stare poate lista același nume de două ori, în timp ce contoarele rămân separate.

Verificați ce face de fapt compilarea dumneavoastră înainte de a proiecta pe baza ei, pentru că efectul opțiunii este definit de opțiune însăși, nu de folclor:

grep -n 'duplicate-cn\|client-config-dir\|username-as-common-name' /etc/openvpn/server.conf

Adresa statică pe care credeați că ați atribuit-o

Configurarea pe client este căutată după nume, și aici este capcana. Un fișier client-config-dir numit după numele comun se aplică fiecărui dispozitiv care folosește acel nume, așa că un ifconfig-push din el le dă ambelor dispozitive aceeași adresă de tunel. A doua sesiune fie nu se stabilește, fie se ciocnește într-un mod care arată ca o defecțiune de rutare.

Un bazin dinamic se comportă mai bine din întâmplare, pentru că fiecărei sesiuni i se alocă independent o adresă din bazin. Asta tot nu vă dă o adresă stabilă pe dispozitiv și cu siguranță nu vă dă o politică pe dispozitiv legată de acea adresă.

Dacă implementarea folosește username-as-common-name, cheia de căutare devine numele de utilizator autentificat în locul subiectului certificatului, iar aceeași coliziune apare pentru oricine se autentifică de două ori. Numele care conduce configurarea trebuie să fie unic pe dispozitiv pentru ca configurarea pe dispozitiv să însemne ceva.

Ce nu poate face o identitate partajată la momentul eliminării

Revocarea acționează asupra certificatului, nu asupra numelui afișat și nu asupra sesiunii. Revocați acel certificat și fiecare dispozitiv care deține o copie pierde accesul dintr-odată, inclusiv cel din birou pe care nimeni nu vrea să-l deranjeze. Păstrați-l și dispozitivul pierdut continuă să funcționeze, pentru că nimic din protocol nu îl distinge de copia aprobată.

Jurnalele moștenesc aceeași ambiguitate. Ieșirea de stare arată un nume comun și o adresă reală, iar ambele pot aparține oricăruia dintre cele două dispozitive. O analiză de incident care trebuie să știe ce mașină a făcut ce nu poate răspunde la această întrebare din înregistrările proprii ale VPN-ului, oricât de mult detaliu ar oferi nivelul de jurnalizare.

Nu există o soluție criptografică pentru asta. Două dispozitive care prezintă același certificat sunt, pentru server, același participant de două ori, iar orice schemă care pretinde altceva este o convenție de denumire, nu un control.

Când partajarea este corectă și cum să o limitezi

Partajarea are utilizări legitime: un cont de laborator folosit de mai multe mașini de test, sau o gospodărie în care dispozitivele sunt administrate împreună și granularitatea revocării nu contează. În aceste cazuri, activați opțiunea deliberat, țineți acreditarea partajată în afara politicii pe dispozitiv și lăsați loc bazinului ca sesiunile să nu se poată ciocni pe o adresă.

Pentru orice are nevoie de adrese separate, jurnale separate sau eliminare separată, emiteți certificate separate prin calea normală de înregistrare. Asta dă fiecărui sistem din aval un obiect distinct pe care să se sprijine, iar opțiunea nu mai contează pentru că numele sunt deja unice.

Orice cale ați alege, testați modelul de administrare și nu autentificarea. Conectați ambele dispozitive, confirmați că au adrese diferite, apoi simulați o pierdere și verificați că puteți elimina exact unul dintre ele. Manualul openvpn(8) definește sfera opțiunii; procedura dumneavoastră de eliminare definește dacă partajarea este într-adevăr acceptabilă.