duplicate-cn dáva dvom zariadeniam jednu identitu, nie dve

Skopírujte profil do tabletu, pripojte sa — a notebook vypadne. Pridajte duplicate-cn, oba ostanú pripojené a problém vyzerá vyriešený, kým sa obe zariadenia nezačnú hádať o rovnakú adresu tunela alebo kým stratený tablet nevyradí celý účet zo siete. Táto voľba mení jednu vec a len jednu: či server povolí druhú reláciu pod menom, ktoré už videl. Všetko, čo od nej ľudia očakávajú — od nezávislosti zariadení cez adresovanie pre každé zariadenie až po selektívne odvolanie — sa stále deje cez identitu, a identitou je tu certifikát.

Mýtus: druhá relácia je druhá identita

Intuícia hovorí, že dve pripojenia musia byť dvaja klienti a dvaja klienti majú byť dve zariadenia s vlastnými právami. Server to tak nemodeluje. Vidí spoločné meno a s povoleným duplicate-cn prijme viac ako jednu živú reláciu nesúcu toto meno, pričom každá dostane v démonovi vlastný stav relácie.

Nič z toho prijatia sa nedotýka overovania certifikátu. Ten istý certifikát je stále poverenie, ten istý kľúč je stále súkromný kľúč a každá politika naviazaná na subjekt certifikátu sa stále dvakrát preloží na rovnakú hodnotu. Druhá relácia je druhý socket, nie druhá identita.

Ten rozdiel je neviditeľný, kým všetko funguje. Veľmi viditeľný je v okamihu, keď potrebujete obe zariadenia rozlíšiť, a to býva deň, keď sa jedno z nich stratí.

Čo sa skutočne zmení, keď dve relácie zdieľajú meno

Bez voľby nové pripojenie pod spoločným menom, ktoré je už pripojené, vytlačí predchádzajúcu reláciu. Preto notebook vypadne, keď sa pripojí tablet, a je to zámerná poistka proti nejednoznačnosti, nie chyba. S voľbou obe relácie zostanú živé a server ich sleduje oddelene podľa relácie, nie podľa zariadenia.

Každá relácia má stále vlastné vonkajšie pripojenie a vlastné vyjednané kľúče, takže súbežná priepustnosť je naozaj súbežná. Zdieľajú všetko, čo sa odvodzuje od poverenia: vyhľadávania politík, konfiguráciu špecifickú pre klienta, identitu v logoch a odvolanie. Stav relácie patrí pripojeniu a umiera s ním, kým fakty na úrovni poverenia pretrvávajú pre obe. Preto môže výstup stavu uviesť to isté meno dvakrát, aj keď počítadlá zostávajú oddelené.

Overte, čo vaše zostavenie skutočne robí, skôr než na tom postavíte návrh, pretože účinok voľby určuje sama voľba, a nie vyprávanie:

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

Statická adresa, o ktorej ste si mysleli, že ste ju pridelili

Konfigurácia pre jednotlivých klientov sa hľadá podľa mena, a v tom je pasca. Súbor client-config-dir pomenovaný podľa spoločného mena sa použije na každé zariadenie, ktoré toto meno používa, takže ifconfig-push v ňom dá obom zariadeniam rovnakú adresu tunela. Druhá relácia sa buď nenadviaže, alebo koliduje tak, že to vyzerá ako chyba smerovania.

Dynamický fond sa správa lepšie náhodou, pretože každej relácii sa adresa z fondu prideľuje nezávisle. Stále vám to nedá stabilnú adresu pre každé zariadenie a rozhodne vám to nedá politiku pre jednotlivé zariadenia naviazanú na túto adresu.

Ak nasadenie používa username-as-common-name, vyhľadávacím kľúčom sa stane overené používateľské meno namiesto subjektu certifikátu a tá istá kolízia postihne každého, kto sa prihlási dvakrát. Meno, ktoré riadi konfiguráciu, musí byť pre každé zariadenie jedinečné, aby konfigurácia pre jednotlivé zariadenia niečo znamenala.

Čo zdieľaná identita nedokáže pri odstránení

Odvolanie pôsobí na certifikát, nie na zobrazované meno a nie na reláciu. Odvolajte ten certifikát a každé zariadenie s kópiou stratí prístup naraz, vrátane toho v kancelárii, ktoré nikto nechce rušiť. Ponechajte ho a stratené zariadenie funguje ďalej, pretože nič v protokole ho neodlíši od schválenej kópie.

Logy dedia rovnakú nejednoznačnosť. Výstup stavu ukazuje spoločné meno a skutočnú adresu a oboje môže patriť ktorémukoľvek z dvoch zariadení. Pri vyšetrovaní incidentu, ktoré má zistiť, ktorý stroj čo urobil, z vlastných záznamov VPN odpovedať nemožno, nech úroveň logovania poskytuje akékoľvek podrobnosti.

Neexistuje na to kryptografická obchádzka. Dve zariadenia, ktoré predložia ten istý certifikát, sú pre server ten istý účastník dvakrát, a každá schéma, ktorá tvrdí opak, je menná konvencia, nie kontrola.

Kedy je zdieľanie správne a ako ho obmedziť

Zdieľanie má legitímne využitie: laboratórny účet, ktorý používa niekoľko testovacích strojov, alebo domácnosť, kde sa zariadenia spravujú spolu a jemnosť odvolania nehrá rolu. V takých prípadoch voľbu zapnite vedome, držte zdieľané poverenie mimo politiky pre jednotlivé zariadenia a nechajte fondu priestor, aby relácie nemohli kolidovať na adrese.

Pre všetko, čo potrebuje samostatné adresy, samostatné logy alebo samostatné odstránenie, vydávajte samostatné certifikáty bežnou cestou registrácie. Každý nadväzujúci systém tak dostane odlišný objekt, o ktorý sa môže oprieť, a voľba prestane byť dôležitá, pretože mená sú už jedinečné.

Nech zvolíte ktorúkoľvek cestu, testujte model správy, nie prihlásenie. Pripojte obe zariadenia, overte, že majú rôzne adresy, potom simulujte stratu a skontrolujte, či dokážete odstrániť práve jedno z nich. Manuál openvpn(8) vymedzuje rozsah voľby; váš postup odstránenia určuje, či je zdieľanie skutočne prijateľné.