Remote ID w VPN na iPhonie: co to pole naprawdę oznacza

Jesteś w Ustawieniach i dodajesz konfigurację IKEv2, a dwa pola proszą o tekst, którego nikt ci nie dał: Remote ID i Local ID. Żadne z nich nie jest twoją nazwą użytkownika i żadne nie jest drugą kopią pola Server. Remote ID to tożsamość, którą brama musi udowodnić twojemu iPhone’owi; Local ID to tożsamość, którą twój iPhone deklaruje bramie. Pomylisz jedno z nich, a tunel padnie po tym, jak serwer już odpowiedział, i dlatego błąd wygląda jak problem z hasłem, choć nim nie jest.

Gdzie są te pola w iOS

Otwórz Ustawienia > Ogólne > VPN i zarządzanie urządzeniami > VPN i dodaj konfigurację IKEv2. W sekcji Uwierzytelnianie wybierasz Nazwę użytkownika albo Certyfikat, i dopiero wtedy pojawiają się Remote ID i Local ID jako pola swobodnego tekstu. To identyfikatory, nie adresy: iOS przenosi je w wymianie IKE_AUTH, gdzie IKEv2 nazywa tożsamość inicjatora IDi, a tożsamość odpowiadającego IDr.

Po zapisaniu iOS zwija konfigurację w jeden wiersz i przestaje pokazywać wartości. Dotknij przycisku informacji albo otwórz profil ponownie, zanim uznasz, że pola są puste. Konfiguracja wysłana przez MDM może je całkowicie wyszarzyć, a to zmienia to, kto może naprawić problem.

Remote ID to nazwa bramy

To wartość, której twój iPhone oczekuje od serwera jako dowodu. Przy uwierzytelnianiu certyfikatem jest porównywana z nazwą w certyfikacie serwera, zwykle z subject lub wpisem subjectAltName. Jeśli certyfikat wystawiono dla vpn.example.com, ta nazwa hosta jest Remote ID, nawet gdy docierasz do maszyny po gołym adresie IP.

Ta niezgodność to klasyczny błąd: pakiety docierają, serwer odpowiada, a połączenie i tak się rozpada, bo tożsamość w certyfikacie nie odpowiada temu, czego wymagał profil. Wskazanie pola Server na surowy adres IP nie pomaga, a na wielu bramach serwer po prostu przestaje odpowiadać tożsamości, której nie potrafi dopasować.

Brama ma odpowiednie ustawienie. Serwer strongSwan wysyła własną tożsamość przez leftid i może ograniczyć tożsamość klienta przez rightid; jeśli obie strony nie zgadzają się co do ciągu, IKE_AUTH zawodzi w obu kierunkach. Zapytaj operatora, dla jakiej tożsamości wystawiono certyfikat, zamiast przepisywać adres URL z paska przeglądarki.

Apple dokumentuje klucze ładunku jako RemoteIdentifier i LocalIdentifier w swojej referencji ustawień IKEv2. Oba są zwykłymi ciągami, więc wielkość liter i spacja na końcu mogą mieć znaczenie.

Local ID to to, co deklaruje twój iPhone

Przy uwierzytelnianiu nazwą użytkownika EAP sprawdza nazwę i hasło, a Local ID to osobna tożsamość IKE, której niektóre bramy również wymagają. Brama może żądać, aby Local ID było równe nazwie użytkownika, było adresem e-mail lub odpowiadało wpisowi w jej polityce połączeń; inne to ignorują. Zostawienie go pustego jest bezpieczne tylko wtedy, gdy operator tak mówi.

Przy uwierzytelnianiu certyfikatem Local ID powinno odpowiadać tożsamości, którą brama akceptuje dla tego certyfikatu klienta, często nazwie powszechnej certyfikatu lub wartości powiązanej z rekordem urządzenia. Skopiowanie profilu kolegi kopiuje też jego tożsamość. W najlepszym razie brama zaloguje niewłaściwe urządzenie, w najgorszym polityka dla pojedynczego urządzenia cię odrzuci.

Pułapką jest założenie, że puste oznacza brak tożsamości. Nie wypełniaj pustego pola swoim adresem e-mail tylko dlatego, że wygląda na niedokończone. Potwierdź zamierzoną wartość i wpisz ją dokładnie tak, jak podano.

Pięciominutowa kontrola przed zapisaniem

Przejdź je po kolei; pierwszy krok, który zawiedzie, jest tym do naprawienia.

1. Uzyskaj od operatora trzy ciągi: nazwę w certyfikacie serwera, oczekiwane Local ID i metodę uwierzytelniania.
2. Dopasuj metodę uwierzytelniania. Remote ID i Local ID nie zastępują nazwy użytkownika i hasła, a profil z certyfikatem nie przyjmie hasła.
3. Wpisz wartości dokładnie, z wielkością liter, bez spacji na końcu.
4. Zostaw włączoną walidację certyfikatów. Instalowanie niepowiązanego certyfikatu głównego, by wyciszyć ostrzeżenie, ukrywa niezgodność nazw zamiast ją naprawiać.
5. Testuj na danych komórkowych, nie na Wi-Fi biurowym, żeby portal przechwytujący czy dzielony DNS nie udawały problemu z tożsamością.

Czytaj tabelę od góry. Przekroczenie czasu w wierszu Server oznacza, że pól tożsamości nigdy nie testowano, więc zatrzymaj się tam. Błąd, który pojawia się dopiero po odpowiedzi serwera, to prawie zawsze niezgodność Remote ID lub Local ID.

Błędy wskazujące niewłaściwe pole

Komunikat typu "User authentication failed" dotyczy danych logowania lub EAP, nie Remote ID. Ostrzeżenie o certyfikacie dotyczy nazwy w certyfikacie i tam spotykają się Remote ID oraz pole Server. "The VPN server did not respond" zwykle oznacza, że UDP 500 i 4500 nigdy się nie zakończyły albo przejście przez NAT zawiodło, i żadna tożsamość nie została porównana.

Po stronie bramy awarie tożsamości wyglądają inaczej: peer jest odrzucany podczas IKE_AUTH albo log podaje ID wysłane przez klienta i stwierdza, że nie pasuje do żadnego połączenia. Ta linia logu to najszybszy sposób rozstrzygnięcia sporu, bo pokazuje dokładny ciąg wysłany przez telefon.

Zresetowanie hasła nie naprawi oczekiwanej tożsamości serwera, a zmiana Remote ID nie naprawi błędnego hasła. Najpierw rozdziel etap, potem edytuj pole należące do tego etapu.

Gdy profil jest zarządzany

Jeśli pola są wyszarzone, konfiguracja pochodzi z MDM i telefon nie jest miejscem, by to naprawiać. Ładunek VPN niesie identyfikatory, więc właściwa zmiana jest w profilu na serwerze zarządzania, a następnie trzeba go zainstalować ponownie na urządzeniu.

Sprawdź w Ustawienia > Ogólne > VPN i zarządzanie urządzeniami, czy profil jest zarządzany i kto go podpisał. Jeśli nie możesz go usunąć, nie możesz edytować identyfikatorów lokalnie, a drugi profil lokalny tworzy tylko sprzeczną konfigurację.

Zanim zamkniesz Ustawienia, zapisz trzy ciągi, które wpisałeś, i skąd pochodzą. Następnym razem, gdy tunel zawiedzie, porównaj ID odebrane w logu bramy z tą notatką: jeśli się różni, patrzysz na pole, nie na hasło.