duplicate-cn da dvema napravama eno identiteto, ne dve

Kopirajte profil na tablico, povežite se in prenosnik odpade. Dodajte duplicate-cn, oba ostaneta povezana in problem je videti rešen — dokler se napravi ne začneta prepirati za isti naslov tunela ali izgubljena tablica ne spravi celotnega računa brez povezave. Ta možnost spremeni eno stvar in samo eno: ali strežnik dovoli drugo sejo pod imenom, ki ga je že videl. Vse, kar ljudje pričakujejo, da bo popravila — od neodvisnosti naprav do naslavljanja na napravo in selektivnega preklica — se še vedno dela prek identitete, identiteta pa je tu certifikat.

Mit: druga seja je druga identiteta

Intuicija pravi, da morata biti dve povezavi dva odjemalca, dva odjemalca pa dve napravi z lastnimi pravicami. Strežnik tega ne modelira tako. Vidi skupno ime in ob vključenem duplicate-cn sprejme več kot eno živo sejo s tem imenom, vsaka pa dobi svoje stanje seje v demonu.

Nič pri tem sprejemu se ne dotakne preverjanja certifikata. Isti certifikat ostaja poverilnica, isti ključ ostaja zasebni ključ in vsaka politika, vezana na subjekt certifikata, se še vedno dvakrat razreši na isto vrednost. Druga seja je druga vtičnica, ne druga identiteta.

Ta razlika je nevidna, dokler vse deluje. Postane zelo vidna v trenutku, ko morate napravi razlikovati, in to je običajno dan, ko se ena od njiju izgubi.

Kaj se resnično spremeni, ko si dve seji delita ime

Brez možnosti nova povezava pod skupnim imenom, ki je že povezano, izrine prejšnjo sejo. Zato prenosnik odpade, ko se poveže tablica, in to je namerna zaščita pred dvoumnostjo, ne napaka. Z možnostjo obe seji ostaneta živi in strežnik ju spremlja ločeno po seji, ne po napravi.

Vsaka seja še vedno dobi svojo zunanjo povezavo in svoje dogovorjene ključe, zato je hkratna prepustnost resnično hkratna. Kar si delita, je vse, kar izhaja iz poverilnice: poizvedbe politik, konfiguracija, specifična za odjemalca, identiteta v dnevnikih in preklic. Stanje seje pripada povezavi in umre z njo, medtem ko dejstva na ravni poverilnice ostanejo za obe. Zato lahko izpis stanja navede isto ime dvakrat, medtem ko števci ostanejo ločeni.

Preverite, kaj vaša gradnja v resnici počne, preden se na to zanesete, ker učinek možnosti določa možnost sama, ne izročilo:

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

Statični naslov, za katerega ste mislili, da ste ga dodelili

Konfiguracija za posameznega odjemalca se išče po imenu, in tu je past. Datoteka client-config-dir, poimenovana po skupnem imenu velja za vsako napravo, ki uporablja to ime, zato ifconfig-push v njej obema napravama dodeli isti naslov tunela. Druga seja se bodisi ne vzpostavi bodisi trči tako, da je videti kot napaka pri usmerjanju.

Dinamični sklad se obnaša bolje po naključju, ker se vsaki seji naslov iz sklada dodeli neodvisno. To vam še vedno ne da stabilnega naslova na napravo in zagotovo ne da politike na napravo, vezane na ta naslov.

Če namestitev uporablja username-as-common-name, iskalni ključ postane overjeno uporabniško ime namesto subjekta certifikata, in ista kolizija doleti vsakogar, ki se prijavi dvakrat. Ime, ki vodi konfiguracijo, mora biti za vsako napravo edinstveno, da ima konfiguracija na napravo sploh pomen.

Česa skupna identiteta ne more pri odstranitvi

Preklic deluje na certifikat, ne na prikazano ime in ne na sejo. Prekličite ta certifikat in vsaka naprava s kopijo takoj izgubi dostop, vključno s tisto v pisarni, ki je nihče ne želi motiti. Pustite ga in izgubljena naprava deluje naprej, ker je v protokolu nič ne razlikuje od odobrene kopije.

Dnevniki podedujejo isto dvoumnost. Izpis stanja pokaže skupno ime in resničen naslov, in oba lahko pripadata kateri koli od naprav. Pregled dogodka, ki mora vedeti, kateri stroj je kaj naredil, ne more odgovoriti na to vprašanje iz lastnih zapisov VPN, ne glede na podrobnosti, ki jih ponuja raven dnevnika.

Za to ni nobene kriptografske rešitve. Dve napravi, ki predložita isti certifikat, sta za strežnik isti udeleženec dvakrat, in vsaka shema, ki trdi drugače, je dogovor o poimenovanju in ne nadzor.

Kdaj je deljenje pravilno in kako ga omejiti

Deljenje ima legitimne uporabe: laboratorijski račun, ki ga uporablja več testnih strojev, ali gospodinjstvo, kjer se naprave upravljajo skupaj in podrobnost preklica ni pomembna. V takih primerih možnost vklopite zavestno, hranite skupno poverilnico zunaj politike na napravo in pustite skladu dovolj prostora, da se seje ne morejo zaleteti na istem naslovu.

Za vse, kar potrebuje ločene naslove, ločene dnevnike ali ločeno odstranitev, izdajte ločene certifikate po običajni poti registracije. To vsakemu nadaljnjemu sistemu da ločen predmet, na katerega se lahko opre, in možnost preneha biti pomembna, ker so imena že edinstvena.

Ne glede na pot, ki jo izberete, preizkusite model upravljanja in ne prijave. Povežite obe napravi, potrdite, da imata različna naslova, nato simulirajte izgubo in preverite, ali lahko odstranite natanko eno od njiju. Priročnik openvpn(8) določa obseg možnosti; vaš postopek odstranitve določa, ali je deljenje res sprejemljivo.