iPhone IKEv2 do RouterOS: który identyfikator gdzie trafia
Cztery osobne twierdzenia rozstrzygają tunel IKEv2 na iOS: wybierany adres, oczekiwana tożsamość serwera, deklarowana tożsamość klienta i materiał certyfikatu.
Dotarcie do bramy MikroTik rozstrzyga tylko połowę transportową wdrożenia IKEv2 i nic więcej. Potem cztery osobne twierdzenia decydują, czy tunel powstanie: adres wybierany przez telefon, oczekiwana tożsamość serwera, tożsamość deklarowana za siebie i materiał certyfikatu, który to twierdzenie podtrzymuje. Sprawdzaj je w tej kolejności i zatrzymaj się na pierwszym, które nie zgadza się z tym, co przedstawia brama. Każde z nich edytuje się w innym miejscu, dlatego błędna zmiana zwykle przenosi usterkę zamiast ją naprawić.
| Setting | What it decides | What it has to agree with |
|---|---|---|
| Remote address | where IKE packets are sent | a reachable name or address for the gateway |
| Remote Identifier | which server identity is expected | the gateway certificate name and the peer identity RouterOS presents |
| Local Identifier | who the phone claims to be | the client certificate name and the RouterOS identity entry |
| Certificate payload | trust plus proof of key possession | the issuing chain and a usable client private key |
Sprawdź pola profilu w kolejności, w jakiej używa ich wymiana
Zdalny adres to cel pierwszego pakietu IKE i nic więcej. Zdalny identyfikator to to, czego telefon oczekuje od bramy jako dowodu tożsamości, i jest to nazwa, a nie trasa. Wypełnienie obu tą samą nazwą hosta działa, gdy certyfikat bramy zawiera tę nazwę, a zawodzi w sposób wyglądający jak problem routingu, gdy jej nie zawiera. Czytaj profil jako ciąg twierdzeń, a nie listę pól do wypełnienia.
Lokalny identyfikator to własne twierdzenie telefonu i musi być nazwą, którą wpis tożsamości w RouterOS akceptuje dla certyfikatu klienta przedstawianego przez telefon. Jeśli oba się nie zgadzają, brama odrzuca połączenie po zweryfikowaniu samego certyfikatu, a dziennik wygląda na problem autoryzacji, nie nazewnictwa.
Sprawdź identyfikatory wobec tego, co przedstawia brama
Wpis partnera w RouterOS skonfigurowany do uwierzytelniania certyfikatem przedstawia własny certyfikat, a jego tożsamość pochodzi z tego certyfikatu, o ile nie skonfigurowano inaczej. Jeśli zdalny identyfikator telefonu wskazuje nazwę DNS bramy, certyfikat bramy musi mieć tę nazwę w miejscu akceptowanym przez telefon, zwykle w alternatywnej nazwie podmiotu. Certyfikat wystawiony na inną nazwę powszechną nie przejdzie walidacji, nawet gdy klucz i łańcuch są bezbłędne.
Zarządzane profile Apple mogą też zawierać ograniczenie nazwy certyfikatu oceniane dodatkowo wobec pól identyfikatora. Sprawdź zawartość, zamiast wnioskować nazwę walidacji z tego, co pokazuje ekran ustawień, bo to nie jest to samo ustawienie.
Sprawdź, czy certyfikat klienta jest kluczem, a nie tylko kotwicą zaufania
Import certyfikatu CA daje telefonowi coś, czym może zweryfikować bramę. Nie daje mu tożsamości klienta, a uwierzytelnianie certyfikatem wymaga certyfikatu liścia klienta i jego klucza prywatnego dostarczonych razem zatwierdzoną ścieżką rejestracji. PKCS#12 zbudowany bez klucza prywatnego daje profil, który instaluje się czysto i niczego nie uwierzytelnia.
Liść klienta potrzebuje też tożsamości oczekiwanej przez stronę RouterOS, czyli podmiot lub alternatywna nazwa podmiotu musi odpowiadać właściwej konfiguracji tożsamości. Wydawanie certyfikatów klienta i serwera z jednego CA czyni łańcuch wygodnym i nie czyni obu liści wymiennymi.
Sprawdź, czy polityka RouterOS akceptuje tę nazwę
Na bramie wpis partnera ustawia tryb wymiany i metodę uwierzytelniania, a wpis tożsamości wiąże zaakceptowaną tożsamość zdalną z certyfikatem i z polityką, która następuje. W RouterOS v7 tę parę wyrażają wpisy partnera i tożsamości IPsec, na przykład partner IKEv2 z auth-method=digital-signature. Sprawdź rzeczywistą zawartość menu w zainstalowanej wersji, a nie przewodnik napisany dla starszej.
Tu również niezgodność najtaniej naprawić, bo brama może podać zarówno tożsamość odebraną, jak i oczekiwaną. Rozszerzenie akceptowanej tożsamości, aby uciszyć błąd, usuwa powiązanie, które nadawało wdrożeniu sens.
Sprawdź, który etap zawiódł, zanim cokolwiek zmienisz
Przeczytaj próbę po obu stronach i sklasyfikuj ją, zanim zmienisz propozycję. Niezgodność propozycji, brakujący klucz podpisu, niezaufany wystawca, błędny identyfikator partnera i odrzucona autoryzacja klienta wyglądają z telefonu jak martwy tunel, a każde ma innego właściciela. Zmiana wszystkich pięciu ustawień naraz gwarantuje, że niczego się z wyniku nie nauczysz.
Zapisz przedstawioną tożsamość, oczekiwaną tożsamość, wystawcę i numer seryjny certyfikatu oraz nazwę właściwej polityki, trzymając klucze prywatne i sekrety profilu poza tym zapisem. Gdy uwierzytelnianie się powiedzie, przetestuj usługę prywatną i jej odpowiedź, bo przydział adresów, selektory, DNS i polityka dostępu nadal muszą działać po zakończeniu wymiany IKE.