Dwie nazwy są w grze, zanim klient w ogóle się połączy: nazwa pliku na laptopie (nuc.ovpn) i tożsamość, którą serwer wyprowadza z poświadczenia. Wyszukiwanie w client-config-dir używa drugiej. Zmiana nazwy profilu na kliencie albo dodanie .conf do pliku serwera niczego nie zmienia w tym, który plik serwer otworzy.

Użyteczne porównanie to nie „jakiej nazwy użyłem”, ale „którą regułę stosuje serwer”, ponieważ uwierzytelnianie certyfikatem i uwierzytelnianie nazwą użytkownika/hasłem mogą dawać różne nazwy efektywne z tego samego logowania.

Nazwa profilu a nazwa wspólna certyfikatu

W domyślnej konfiguracji opartej na certyfikatach serwer bierze nazwę wspólną X.509 i szuka pliku o dokładnie tej nazwie wewnątrz client-config-dir. Profil o nazwie nuc.ovpn, którego certyfikat mówi tester, rozwiązuje się do /etc/openvpn/server/ccd/tester. Nazwa pliku klienta nigdy nie wchodzi do obliczeń. To pierwsze miejsce, w którym ukrywa się niezgodność.

Katalog pełen starannie nazwanych profili może więc chybiać za każdym razem. Plik nie jest dopasowywany po subject, po adresie e-mail ani po nazwie widocznej w GUI; jest dopasowywany po łańcuchu nazwy wspólnej.

W systemie plików rozróżniającym wielkość liter Tester i tester to dwa różne pliki i otwierany jest tylko jeden. Sprawdzaj nazwę wspólną z certyfikatu, który klient rzeczywiście przedstawia, a nie z kopii w notatkach.

username-as-common-name odwraca regułę

Gdy serwer używa uwierzytelniania nazwą użytkownika/hasłem z username-as-common-name, uwierzytelniona nazwa użytkownika zastępuje nazwę wspólną certyfikatu w tym wyszukiwaniu.

Porównaj oba przypadki bezpośrednio: przy tożsamości z certyfikatu plik podąża za certyfikatem i zmiana hasła nie ma znaczenia; przy tożsamości z nazwy użytkownika plik podąża za nazwą logowania i ponowne wydanie certyfikatu nie ma znaczenia. To, które pole serwer zastępuje, wyznacza nazwę do zmiany. Certyfikat ponownie wydany z nowym CN po cichu zmienia cel wyszukiwania, a stary plik CCD zostaje na dysku i wygląda poprawnie.

Istnieją konfiguracje mieszane i właśnie tam zaczyna się większość zamieszania. Jeśli jeden blok usługi włącza podstawienie, a inny nie, nazwa efektywna zależy od tego, która instancja obsłużyła połączenie. Potwierdź aktywną konfigurację, zamiast zakładać, że obowiązuje plik globalny. Pierwotna dokumentacja opcji serwera opisuje wyszukiwanie po nazwanym pliku i opcjonalny wariant zapasowy.

Co serwer czyta, a co po cichu pomija

O tym, czy plik zostanie wybrany, decydują dwie małe różnice. Pierwsza to dodane rozszerzenie. Druga to zabłąkany znak w nazwie.

OpenVPN nie dodaje .conf do szukanej nazwy, więc tester.conf nie pasuje do tester. Edytor ukrywający rozszerzenia może zostawić plik, który w listingu wygląda poprawnie i nigdy nie pasuje.

Gdy nie ma pasującego pliku, serwer może sięgnąć po plik o nazwie DEFAULT. Dotarcie niektórych ustawień nie jest więc dowodem, że użyto pliku dla danego klienta. Porównaj przydzielony adres lub wypchnięte trasy z tym, co dałby plik dla danego klienta. Uprawnienia to trzeci filtr, bo serwer otwiera plik po zrzuceniu uprawnień; powłoka root, która potrafi go odczytać, niczego nie dowodzi.

Poprawna nazwa pliku nie waliduje zawartości

Wybór i zawartość to osobne awarie. Po otwarciu właściwego pliku jego dyrektywy nadal muszą być poprawne dla tego klienta.

ifconfig-push musi przydzielić adres, którego topologia naprawdę może użyć, a iroute ma sens tylko dla trasowanej podsieci za tym klientem.

Jedna tożsamość, kilka urządzeń

Dwa laptopy przedstawiające tę samą nazwę wspólną wybierają ten sam plik i otrzymują te same ustawienia specyficzne dla klienta. Jeśli potrzebujesz osobnych adresów lub osobnego unieważnienia, potrzebujesz osobnych tożsamości, a nie dwóch kopii jednego pliku.

Porównanie dotyczy współdzielenia tożsamości i wydawania jednego certyfikatu na urządzenie. Współdzielenie jest prostsze w administracji i grubsze przy unieważnianiu, natomiast certyfikaty na urządzenie wymagają więcej konfiguracji i dają czystą jednostkę do wyłączenia.

Powiązane artykuły