duplicate-cn daje dwóm urządzeniom jedną tożsamość, nie dwie

Skopiuj profil na tablet, połącz się, a laptop wypada. Dodaj duplicate-cn, oba zostają połączone, i problem wygląda na rozwiązany — dopóki dwa urządzenia nie zaczną walczyć o ten sam adres tunelu albo zgubiony tablet nie odłączy całego konta. Ta opcja zmienia jedną rzecz i tylko jedną: czy serwer pozwala na drugą sesję pod nazwą, którą już widział. Wszystko, czego ludzie oczekują, że naprawi — od niezależności urządzeń przez adresowanie na urządzenie po selektywne unieważnianie — nadal odbywa się przez tożsamość, a tożsamością jest tutaj certyfikat.

Mit: druga sesja to druga tożsamość

Intuicja mówi, że dwa połączenia muszą być dwoma klientami, a dwaj klienci powinni być dwoma urządzeniami z własnymi prawami. Serwer tego tak nie modeluje. Widzi wspólną nazwę i przy włączonym duplicate-cn akceptuje więcej niż jedną żywą sesję z tą nazwą, a każda dostaje własny stan sesji w demonie.

Nic w tej akceptacji nie dotyka weryfikacji certyfikatu. Ten sam certyfikat nadal jest poświadczeniem, ten sam klucz nadal jest kluczem prywatnym, a każda polityka oparta na podmiocie certyfikatu nadal rozwiązuje się dwa razy do tej samej wartości. Druga sesja to drugi socket, nie druga tożsamość.

Ta różnica jest niewidoczna, dopóki wszystko działa. Staje się bardzo widoczna w chwili, gdy trzeba odróżnić oba urządzenia, a to zwykle ten dzień, w którym jedno z nich ginie.

Co naprawdę się zmienia, gdy dwie sesje dzielą nazwę

Bez tej opcji nowe połączenie pod wspólną nazwą, która jest już połączona, wypiera wcześniejszą sesję. Dlatego laptop wypada, gdy łączy się tablet, i jest to celowe zabezpieczenie przed niejednoznacznością, a nie błąd. Z opcją obie sesje pozostają żywe, a serwer śledzi je osobno według sesji, nie według urządzenia.

Każda sesja nadal dostaje własne połączenie zewnętrzne i własne wynegocjowane klucze, więc równoczesna przepustowość jest naprawdę równoczesna. Wspólne jest wszystko, co wynika z poświadczenia: wyszukiwania polityk, konfiguracja specyficzna dla klienta, tożsamość w logach i unieważnianie. Stan sesji należy do połączenia i ginie razem z nim, podczas gdy fakty na poziomie poświadczenia trwają dla obu. Dlatego wyjście statusu może wymienić tę samą nazwę dwa razy, a liczniki pozostają osobne.

Sprawdź, co naprawdę robi twoja kompilacja, zanim zaczniesz na tym projektować, bo efekt opcji określa sama opcja, a nie przekazy ustne:

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

Statyczny adres, który sądziłeś, że przydzieliłeś

Konfiguracja dla każdego klienta jest wyszukiwana po nazwie i tu jest pułapka. Plik client-config-dir nazwany od wspólnej nazwy dotyczy każdego urządzenia używającego tej nazwy, więc ifconfig-push w nim daje obu urządzeniom ten sam adres tunelu. Druga sesja albo się nie zestawia, albo koliduje w sposób wyglądający jak awaria routingu.

Pula dynamiczna zachowuje się lepiej przypadkiem, bo każdej sesji adres z puli jest przydzielany niezależnie. To nadal nie daje stabilnego adresu na urządzenie i z pewnością nie daje polityki na urządzenie powiązanej z tym adresem.

Jeśli wdrożenie używa username-as-common-name, kluczem wyszukiwania staje się uwierzytelniona nazwa użytkownika zamiast podmiotu certyfikatu, i ta sama kolizja dotyczy każdego, kto zaloguje się dwa razy. Nazwa sterująca konfiguracją musi być unikalna na urządzenie, żeby konfiguracja na urządzenie cokolwiek znaczyła.

Czego wspólna tożsamość nie potrafi przy usuwaniu

Unieważnianie działa na certyfikat, nie na wyświetlaną nazwę i nie na sesję. Unieważnij ten certyfikat, a każde urządzenie z kopią natychmiast traci dostęp, łącznie z tym w biurze, którego nikt nie chce niepokoić. Zostaw go, a zgubione urządzenie nadal działa, bo nic w protokole go nie odróżnia od zatwierdzonej kopii.

Logi dziedziczą tę samą niejednoznaczność. Wyjście statusu pokazuje wspólną nazwę i rzeczywisty adres, a oba mogą należeć do każdego z dwóch urządzeń. Przegląd incydentu, który musi wiedzieć, która maszyna co zrobiła, nie odpowie na to pytanie na podstawie własnych zapisów VPN, niezależnie od poziomu szczegółowości logów.

Nie ma na to obejścia kryptograficznego. Dwa urządzenia przedstawiające ten sam certyfikat są dla serwera tym samym uczestnikiem dwa razy, a każdy schemat twierdzący inaczej jest konwencją nazewniczą, a nie kontrolą.

Kiedy współdzielenie jest właściwe i jak je ograniczyć

Współdzielenie ma uzasadnione zastosowania: konto laboratoryjne używane przez kilka maszyn testowych albo gospodarstwo domowe, w którym urządzeniami zarządza się razem i szczegółowość unieważniania nie ma znaczenia. W takich przypadkach włącz opcję świadomie, trzymaj wspólne poświadczenie poza polityką na urządzenie i daj puli zapas, żeby sesje nie mogły kolidować na jednym adresie.

Dla wszystkiego, co wymaga osobnych adresów, osobnych logów lub osobnego usuwania, wystawiaj osobne certyfikaty zwykłą ścieżką rejestracji. To daje każdemu dalszemu systemowi odrębny obiekt, na którym może się oprzeć, a opcja przestaje mieć znaczenie, bo nazwy są już unikalne.

Niezależnie od wybranej drogi testuj model zarządzania, a nie logowanie. Połącz oba urządzenia, potwierdź, że mają różne adresy, następnie zasymuluj utratę i sprawdź, czy potrafisz usunąć dokładnie jedno z nich. Podręcznik openvpn(8) określa zakres opcji; twoja procedura usuwania określa, czy współdzielenie jest naprawdę dopuszczalne.