duplicate-cn dává dvěma zařízením jednu identitu, ne dvě

Zkopírujte profil do tabletu, připojte se — a notebook vypadne. Přidejte duplicate-cn, oba zůstanou připojené a problém vypadá vyřešený, dokud se obě zařízení nezačnou přetahovat o stejnou adresu tunelu nebo dokud ztracený tablet nevyřadí celý účet ze sítě. Volba mění jednu věc a jen jednu: zda server povolí druhou relaci pod jménem, které už viděl. Všechno, co od ní lidé čekají — od nezávislosti zařízení přes adresování pro každé zařízení až po selektivní odvolání — se pořád děje přes identitu a identitou je tady certifikát.

Mýtus: druhá relace je druhá identita

Intuice říká, že dvě připojení musí být dva klienti a dva klienti mají být dvě zařízení s vlastními právy. Server to tak nemodeluje. Vidí společné jméno a s povoleným duplicate-cn přijme víc než jednu živou relaci nesoucí toto jméno, přičemž každá dostane v démonu vlastní stav relace.

Nic z toho přijetí se nedotýká ověřování certifikátu. Stejný certifikát je pořád pověření, stejný klíč je pořád soukromý klíč a každá politika navázaná na subjekt certifikátu se pořád dvakrát přeloží na stejnou hodnotu. Druhá relace je druhý socket, ne druhá identita.

Ten rozdíl je neviditelný, dokud všechno funguje. Velmi viditelný je v okamžiku, kdy potřebujete obě zařízení rozlišit, což bývá den, kdy se jedno z nich ztratí.

Co se skutečně změní, když dvě relace sdílejí jméno

Bez volby nové připojení pod společným jménem, které je už připojené, vytlačí dřívější relaci. Proto notebook vypadne, když se připojí tablet, a je to záměrná pojistka proti nejednoznačnosti, ne chyba. S volbou obě relace zůstanou živé a server je sleduje odděleně podle relace, ne podle zařízení.

Každá relace má pořád vlastní vnější připojení a vlastní vyjednané klíče, takže souběžná propustnost je skutečně souběžná. Sdílejí vše, co se odvozuje od pověření: vyhledávání politik, konfiguraci specifickou pro klienta, identitu v logu a odvolání. Stav relace patří připojení a umírá s ním, zatímco fakta na úrovni pověření přetrvávají pro obě. Proto může výstup stavu vypsat stejné jméno dvakrát, i když počítadla zůstávají oddělená.

Ověřte, co vaše sestavení skutečně dělá, než na tom postavíte návrh, protože účinek volby určuje sama volba, a ne vyprávění:

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

Statická adresa, o které jste si mysleli, že jste ji přidělili

Konfigurace pro jednotlivé klienty se hledá podle jména, a v tom je past. Soubor client-config-dir pojmenovaný podle společného jména se použije na každé zařízení, které toto jméno používá, takže ifconfig-push v něm dá oběma zařízením stejnou adresu tunelu. Druhá relace se buď nenaváže, nebo koliduje tak, že to vypadá jako chyba směrování.

Dynamický fond se chová lépe náhodou, protože každé relaci se adresa z fondu přiděluje nezávisle. Pořád vám to nedá stabilní adresu pro každé zařízení a rozhodně vám to nedá politiku pro jednotlivá zařízení navázanou na tuto adresu.

Pokud nasazení používá username-as-common-name, vyhledávacím klíčem se stane ověřené uživatelské jméno místo subjektu certifikátu a stejná kolize postihne každého, kdo se přihlásí dvakrát. Jméno, které řídí konfiguraci, musí být pro každé zařízení jedinečné, aby konfigurace pro jednotlivá zařízení něco znamenala.

Co sdílená identita nedokáže při odebrání

Odvolání působí na certifikát, ne na zobrazované jméno a ne na relaci. Odvolejte ten certifikát a každé zařízení s kopií ztratí přístup naráz, včetně toho v kanceláři, které nikdo nechce rušit. Ponechte ho a ztracené zařízení funguje dál, protože nic v protokolu ho neodliší od schválené kopie.

Logy dědí stejnou nejednoznačnost. Výstup stavu ukazuje společné jméno a skutečnou adresu a obojí může patřit kterémukoli z obou zařízení. Při šetření incidentu, které má zjistit, který stroj co udělal, z vlastních záznamů VPN odpovědět nelze, ať úroveň logování poskytuje jakékoli podrobnosti.

Neexistuje na to kryptografická objížďka. Dvě zařízení, která předloží stejný certifikát, jsou pro server tentýž účastník dvakrát, a každé schéma, které tvrdí opak, je jmenná konvence, nikoli kontrola.

Kdy je sdílení správné a jak ho omezit

Sdílení má legitimní využití: laboratorní účet, který používá několik testovacích strojů, nebo domácnost, kde se zařízení spravují společně a jemnost odvolání nehraje roli. V takových případech volbu zapněte vědomě, držte sdílené pověření mimo politiku pro jednotlivá zařízení a nechte fondu prostor, aby relace nemohly kolidovat na adrese.

Pro cokoli, co potřebuje samostatné adresy, samostatné logy nebo samostatné odebrání, vydávejte samostatné certifikáty běžnou cestou registrace. Každý navazující systém tak dostane odlišný objekt, o který se může opřít, a volba přestane být důležitá, protože jména jsou už jedinečná.

Ať zvolíte kteroukoli cestu, testujte model správy, ne přihlášení. Připojte obě zařízení, ověřte, že mají různé adresy, pak simulujte ztrátu a zkontrolujte, zda dokážete odebrat právě jedno z nich. Manuál openvpn(8) vymezuje rozsah volby; váš postup odebrání určuje, zda je sdílení skutečně přijatelné.