iPhone IKEv2 do RouterOS: který identifikátor kam patří
Čtyři samostatné nároky rozhodují o tunelu IKEv2 na iOS: vytáčená adresa, očekávaná identita serveru, deklarovaná identita klienta a certifikátový materiál.
Dosažení brány MikroTik vyřeší jen transportní polovinu nasazení IKEv2 a nic víc. Poté o vzniku tunelu rozhodují čtyři samostatné nároky: adresa, kterou telefon vytáčí, identita serveru, kterou očekává, identita, kterou tvrdí o sobě, a certifikátový materiál, který tento nárok podkládá. Kontrolujte je v tomto pořadí a zastavte se u prvního, který se neshoduje s tím, co brána předkládá. Každý se upravuje na jiném místě, a proto chybná úprava obvykle poruchu přesune, místo aby ji opravila.
| 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 |
Zkontrolujte pole profilu v pořadí, v jakém je výměna používá
Vzdálená adresa je cíl prvního paketu IKE a nic víc. Vzdálený identifikátor je to, čím má podle telefonu brána prokázat svou totožnost, a je to jméno, ne trasa. Vyplnění obou stejným názvem hostitele funguje, když certifikát brány toto jméno obsahuje, a selhává způsobem, který vypadá jako problém směrování, když ho neobsahuje. Čtěte profil jako sled nároků, ne jako seznam polí k vyplnění.
Místní identifikátor je vlastní nárok telefonu a musí to být jméno, které záznam identity v RouterOS přijímá pro klientský certifikát, jenž telefon předkládá. Pokud se oba neshodují, brána připojení odmítne poté, co se certifikát sám ověřil, a log vypadá jako problém autorizace, ne pojmenování.
Zkontrolujte identifikátory proti tomu, co brána předkládá
Záznam protějšku v RouterOS nastavený pro autentizaci certifikátem předkládá vlastní certifikát a jeho identita se bere z tohoto certifikátu, pokud jste nenastavili jinak. Pokud vzdálený identifikátor telefonu uvádí DNS jméno brány, potřebuje certifikát brány toto jméno na místě, které telefon přijme, obvykle v alternativním jménu subjektu. Certifikát vydaný pro jiné obecné jméno neprojde ověřením, i když jsou klíč a řetěz bezvadné.
Spravované profily Apple mohou nést také omezení jména certifikátu, které se vyhodnocuje navíc k polím identifikátoru. Prohlédněte obsah, místo abyste jméno pro ověření odvozovali z toho, co zobrazuje obrazovka nastavení, protože to nejsou stejná nastavení.
Zkontrolujte, že klientský certifikát je klíč, ne jen kotva důvěry
Import certifikátu CA dá telefonu něco, čím může bránu ověřit. Nedá mu klientskou identitu a autentizace certifikátem potřebuje klientský koncový certifikát a jeho soukromý klíč doručené společně schválenou cestou registrace. PKCS#12 vytvořený bez soukromého klíče vytvoří profil, který se čistě nainstaluje a nic neautentizuje.
Klientský koncový certifikát také potřebuje identitu, kterou strana RouterOS očekává, což znamená, že subjekt nebo alternativní jméno subjektu musí odpovídat příslušné konfiguraci identity. Vydání klientských a serverových certifikátů z jednoho CA dělá řetěz pohodlným a nečiní oba koncové certifikáty zaměnitelnými.
Zkontrolujte, že politika RouterOS toto jméno přijímá
Na bráně záznam protějšku určuje režim výměny a metodu autentizace a záznam identity svazuje přijatou vzdálenou identitu s certifikátem a s politikou, která následuje. V RouterOS v7 se tato dvojice vyjadřuje záznamy protějšku a identity v IPsec, například protějšek IKEv2 s auth-method=digital-signature. Kontrolujte skutečný obsah nabídky v nainstalované verzi, ne návod psaný pro starší.
Zde je také neshodu nejlevnější opravit, protože brána vám může sdělit jak identitu, kterou přijala, tak identitu, kterou chtěla. Rozšíření přijímané identity, aby se chyba umlčela, odstraní vazbu, která nasazení dávala smysl.
Zkontrolujte, která fáze selhala, než cokoli upravíte
Přečtěte si pokus na obou koncích a klasifikujte ho, než změníte návrh. Neshoda návrhu, chybějící podpisový klíč, nedůvěryhodný vydavatel, špatný identifikátor protějšku a odmítnutá autorizace klienta vypadají z telefonu všechny jako mrtvý tunel a každý má jiného vlastníka. Změna všech pěti nastavení najednou zaručí, že se z výsledku nic nedozvíte.
Zaznamenejte předloženou identitu, očekávanou identitu, vydavatele a sériové číslo certifikátu a název příslušné politiky, přičemž soukromé klíče a tajemství profilu držte mimo tento záznam. Když autentizace uspěje, otestujte soukromou službu a její odpověď, protože přiřazení adres, selektory, DNS a přístupová politika musí po skončení výměny IKE stále fungovat.