Profil pokazuje twoje imię, widoczna etykieta certyfikatu mówi coś innego, a dziennik bramy zapisuje trzeci identyfikator. Żaden z nich nie kłamie i właśnie w tym tkwi problem: trzy różne pola są czytane tak, jakby odpowiadały na jedno pytanie. Połączenie przedstawia poświadczenie, identyfikator IKEv2 i konto, a brama decyduje, które z nich co autoryzuje.

Trzy tożsamości w jednym połączeniu

Widoczna nazwa profilu to etykieta dla ludzi. Wybiera połączenie i nic więcej. Certyfikat to poświadczenie, a to, czy może coś udowodnić, zależy od tego, czy klient ma pasujący klucz prywatny. Pole konta to twierdzenie o podmiocie, a serwer może je swobodnie zmapować na inną tożsamość lokalną.

Gdy uwierzytelnianie się nie udaje, zapytaj, którego z trzech dotyczy błąd. Odrzucone poświadczenie, nieznany identyfikator i wyłączone konto dają różne komunikaty, a traktowanie ich jako jednego „problemu z certyfikatem” kieruje cię do niewłaściwej konsoli.

Czytaj pola natywne według ich zadania

W zarządzanej natywnej konfiguracji IKEv2 odwołanie ładunku Apple rozdziela wartości, a metoda uwierzytelniania decyduje, która kombinacja jest wymagana:

FieldIdentifiesCommon misreading
AuthNameUsername for the configured arrangementAssuming it is the certificate subject
LocalIdentifierIKEv2 client identifierAssuming it must equal the username
PayloadCertificateUUIDReferenced credential payloadAssuming any installed certificate will do

Certyfikat i logowanie EAP mogą mieć różne role w tym samym połączeniu. Nie zmuszaj każdego pola do przechowywania tego samego tekstu tylko dlatego, że jedno z nich tak robi, i nie zakładaj, że zmiana jednego unieważnia pozostałe. Aplikacja VPN innego dostawcy może pokazywać zupełnie inny model; użyj jej udokumentowanego wyboru tożsamości zamiast przenosić tam natywne nazwy pól.

Certyfikat serwera nie jest tożsamością klienta

Certyfikat, który waliduje bramę, jest kotwicą zaufania. Dowodzi, że dotarłeś do serwera, którego oczekiwałeś. Tożsamość klienta to inny obiekt: obejmuje dostęp do klucza prywatnego, który dowodzi, że łącząca się strona jest tym, za kogo się podaje. Zmiana nazwy widocznego konta nie może zamienić jednego w drugie.

Tu dobrze intencjonowana poprawka idzie na manowce. Import certyfikatu CA bramy do magazynu klienta nic nie daje dla uwierzytelniania klienta, a oznaczenie tego wpisu nazwą użytkownika nie czyni go tożsamością użytkownika. Oba obiekty żyją w różnych częściach profilu i odpowiadają na różne pytania.

Prześledź podmiot aż do mapowania na bramie

Potwierdź, do czego wydano poświadczenie: dla tego użytkownika, tego urządzenia czy wspólnej roli. Konto logowania Maca nie jest automatycznie tym podmiotem, a certyfikat skopiowany z innej maszyny zachowuje tożsamość maszyny, dla której go wydano.

Następnie porównaj rzeczywiste poświadczenie, nie etykietę. Wystawca, numer seryjny i odcisk palca pozwalają tobie i administratorowi potwierdzić, że mówicie o tym samym obiekcie. Wyświetlane nazwy można edytować i często się powtarzają, co czyni je najgorszym możliwym identyfikatorem podczas incydentu.

Ostatni krok jest po stronie bramy. Poproś jej właściciela o skorelowanie jednego połączenia z przedstawionymi identyfikatorami i z regułą mapowania kont, która je wykorzystała. Etykieta po stronie klienta nie może ustalić, co zdecydował serwer, a reguła mapująca certyfikat na wyłączone konto będzie zawodzić, gdy wszystkie pola po stronie klienta wyglądają poprawnie.

Napraw warstwę, do której należy niezgodność

Jeśli profil wskazuje niewłaściwe poświadczenie, popraw jego odwołanie lub wybór. Jeśli poświadczenie należy do innego podmiotu, przejdź przez ponowną rejestrację u wystawcy zamiast edytować etykiety. Jeśli brama wiąże ważne poświadczenie z niewłaściwym kontem, jej właściciel polityki musi poprawić mapowanie. To trzy różne zmiany z trzema różnymi osobami zatwierdzającymi.

Odnowienie zasługuje na taką samą staranność. Wymiana certyfikatu, zmiana nazwy jego widocznej etykiety i przenoszenie osoby między systemami kont nie wpływają koniecznie na mapowanie w ten sam sposób. Zanotuj, którą z trzech rzeczy zmieniłeś, ponieważ następna awaria będzie wyglądać identycznie od strony klienta i inaczej w dzienniku bramy.

Udostępniaj tylko minimalne publiczne identyfikatory, których potrzebuje wsparcie. Klucz prywatny ani pełny pakiet tożsamości nigdy nie są częścią tej wymiany, niezależnie od tego, jak bardzo ułatwiłoby to diagnozę.

Powiązane artykuły