A duplicate-cn egy identitást ad két eszköznek, nem kettőt

Másolja a profilt a táblagépre, csatlakozzon, és a laptop kiesik. Adja hozzá a duplicate-cn beállítást, mindkettő kapcsolva marad, és a probléma megoldottnak tűnik — amíg a két eszköz nem kezd el verekedni ugyanazért az alagútcímért, vagy egy elveszett táblagép nem viszi offline állapotba az egész fiókot. A beállítás egy dolgot változtat meg, és csak egyet: hogy a kiszolgáló engedélyezi-e a második munkamenetet egy olyan név alatt, amelyet már látott. Minden, amit az emberek tőle várnak — az eszközfuggetlenségtől kezdve az eszközönkénti címzésen át a szelektív visszavonásig — továbbra is identitás alapján történik, és az identitás itt a tanúsítvány.

A mítosz: a második munkamenet második identitás

A megérzés szerint két kapcsolat két kliens kell legyen, két kliens pedig két eszköz saját jogokkal. A kiszolgáló nem így modellezi. Egy közös nevet lát, és ha a duplicate-cn engedélyezve van, egynél több élő munkamenetet is elfogad ezzel a névvel, és mindegyik saját munkamenet-állapotot kap a daemonban.

Ennek az elfogadásnak semmi köze a tanúsítvány ellenőrzéséhez. Ugyanaz a tanúsítvány marad a hitelesítő adat, ugyanaz a kulcs marad a privát kulcs, és a tanúsítvány tárgyára épülő bármely házirend továbbra is kétszer ugyanarra az értékre oldódik fel. A második munkamenet egy második socket, nem második identitás.

Ez a különbség láthatatlan, amíg minden működik. Nagyon láthatóvá válik abban a pillanatban, amikor meg kell különböztetnie a két eszközt — és ez általában az a nap, amikor az egyik elveszik.

Mi változik valójában, ha két munkamenet megoszt egy nevet

A beállítás nélkül egy már csatlakozott közös név alatti új kapcsolat kiszorítja a korábbi munkamenetet. Ezért esik ki a laptop, amikor a táblagép csatlakozik, és ez szándékos kétértelműség-védelem, nem hiba. A beállítással mindkét munkamenet életben marad, és a kiszolgáló külön követi őket munkamenet szerint, nem eszköz szerint.

Minden munkamenet továbbra is saját külső kapcsolatot és saját egyeztetett kulcsokat kap, tehát az egyidejű átvitel valóban egyidejű. Amit megosztanak, az minden, ami a hitelesítő adatból származik: házirend-keresések, kliensspecifikus konfiguráció, naplóidentitás és visszavonás. A munkamenet-állapot a kapcsolathoz tartozik és vele hal meg, míg a hitelesítő adat szintjén lévő tények mindkettőre érvényben maradnak. Ezért listázhatja a státuszkimenet ugyanazt a nevet kétszer, miközben a számlálók külön maradnak.

Ellenőrizze, mit tesz valójában a build, mielőtt erre építene, mert a beállítás hatását maga a beállítás határozza meg, nem a szóbeszéd:

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

A statikus cím, amelyet úgy hitt, hogy kiosztott

Az ügyfelenkénti konfigurációt név alapján keresi a rendszer, és itt van a csapda. Egy client-config-dir fájl, amelyet a közös névről neveztek el minden olyan eszközre vonatkozik, amely ezt a nevet használja, ezért a benne lévő ifconfig-push mindkét eszköznek ugyanazt az alagútcímet adja. A második munkamenet vagy nem jön létre, vagy úgy ütközik, hogy útválasztási hibának látszik.

Egy dinamikus címkészlet véletlenül jobban viselkedik, mert minden munkamenet önállóan kap címet a készletből. Ez még mindig nem ad stabil eszközönkénti címet, és biztosan nem ad az adott címhez kötött eszközönkénti házirendet.

Ha a telepítés username-as-common-name beállítást használ, a keresési kulcs a hitelesített felhasználónév lesz a tanúsítvány tárgya helyett, és ugyanaz az ütközés következik be mindenkinél, aki kétszer jelentkezik be. A konfigurációt vezérlő névnek eszközönként egyedinek kell lennie ahhoz, hogy az eszközönkénti konfigurációnak értelme legyen.

Mit nem tud a megosztott identitás eltávolításkor

A visszavonás a tanúsítványra hat, nem a megjelenített névre és nem a munkamenetre. Vonja vissza azt a tanúsítványt, és minden példányt tartó eszköz azonnal elveszíti a hozzáférést, beleértve azt is, amelyik az irodában van, és amelyet senki sem akar zavarni. Tartsa meg, és az elveszett eszköz tovább működik, mert a protokollban semmi sem különbözteti meg a jóváhagyott példánytól.

A naplók ugyanezt a kétértelműséget öröklik. A státuszkimenet egy közös nevet és egy valódi címet mutat, és mindkettő tartozhat bármelyik eszközhöz. Egy incidensvizsgálat, amelynek tudnia kell, melyik gép mit tett, nem tud válaszolni a kérdésre a VPN saját nyilvántartásaiból, bármennyi részletet is ad a naplózási szint.

Erre nincs kriptográfiai megkerülő út. Két eszköz, amely ugyanazt a tanúsítványt mutatja be, a kiszolgáló számára ugyanaz a résztvevő kétszer, és minden séma, amely mást állít, névkonvenció, nem ellenőrzés.

Mikor helyes a megosztás, és hogyan kell korlátozni

A megosztásnak vannak jogszerű felhasználásai: egy laborfiók, amelyet több tesztgép használ, vagy egy háztartás, ahol az eszközöket együtt kezelik, és a visszavonás részletessége nem számít. Ezekben az esetekben tudatosan kapcsolja be a beállítást, tartsa a megosztott hitelesítő adatot az eszközönkénti házirenden kívül, és adjon helyet a készletnek, hogy a munkamenetek ne ütközhessenek egy címen.

Mindenhez, ami külön címeket, külön naplókat vagy külön eltávolítást igényel, külön tanúsítványokat adjon ki a szokásos regisztrációs úton. Ez minden további rendszernek külön objektumot ad, amelyre támaszkodhat, és a beállítás jelentőségét veszti, mert a nevek már egyediek.

Bármelyik utat választja, a kezelési modellt tesztelje, nem a bejelentkezést. Csatlakoztassa mindkét eszközt, erősítse meg, hogy különböző címeik vannak, majd szimuláljon egy elvesztést, és ellenőrizze, hogy pontosan az egyiket tudja eltávolítani. Az openvpn(8) kézikönyv meghatározza a beállítás hatókörét; az ön eltávolítási eljárása határozza meg, hogy a megosztás valóban elfogadható-e.