iPhone IKEv2 do RouterOS: ktorý identifikátor kam patrí
O tuneli IKEv2 na iOS rozhodujú štyri samostatné tvrdenia: vytáčaná adresa, očakávaná identita servera, deklarovaná identita klienta a certifikátový materiál.
Dosiahnutie brány MikroTik vyrieši len transportnú polovicu nasadenia IKEv2 a nič viac. Potom o vzniku tunela rozhodujú štyri samostatné tvrdenia: adresa, ktorú telefón vytáča, identita servera, ktorú očakáva, identita, ktorú tvrdí o sebe, a certifikátový materiál, ktorý toto tvrdenie podkladá. Kontrolujte ich v tomto poradí a zastavte sa pri prvom, ktoré sa nezhoduje s tým, čo predkladá brána. Každé sa upravuje na inom mieste, a preto chybná úprava zvyčajne poruchu presunie namiesto toho, aby ju 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 |
Skontrolujte polia profilu v poradí, v ktorom ich výmena používa
Vzdialená adresa je cieľom prvého paketu IKE a nič viac. Vzdialený identifikátor je to, čím má podľa telefónu brána preukázať svoju totožnosť, a je to meno, nie trasa. Vyplnenie oboch rovnakým názvom hostiteľa funguje, keď certifikát brány toto meno obsahuje, a zlyháva spôsobom, ktorý vyzerá ako problém smerovania, keď ho neobsahuje. Čítajte profil ako sled tvrdení, nie ako zoznam polí na vyplnenie.
Miestny identifikátor je vlastné tvrdenie telefónu a musí to byť meno, ktoré záznam identity v RouterOS prijíma pre klientsky certifikát, ktorý telefón predkladá. Ak sa obe nezhodujú, brána pripojenie odmietne po tom, čo sa certifikát sám overil, a log vyzerá ako problém autorizácie, nie pomenovania.
Skontrolujte identifikátory proti tomu, čo predkladá brána
Záznam partnera v RouterOS nastavený na autentifikáciu certifikátom predkladá vlastný certifikát a jeho identita sa berie z tohto certifikátu, ak ste nenastavili inak. Ak vzdialený identifikátor telefónu uvádza DNS meno brány, certifikát brány potrebuje toto meno na mieste, ktoré telefón prijme, zvyčajne v alternatívnom mene subjektu. Certifikát vydaný pre iné všeobecné meno neprejde overením, aj keď sú kľúč a reťaz bezchybné.
Spravované profily Apple môžu niesť aj obmedzenie mena certifikátu, ktoré sa vyhodnocuje navyše k poliam identifikátora. Preskúmajte obsah, namiesto toho aby ste meno na overenie odvodzovali z toho, čo zobrazuje obrazovka nastavení, pretože to nie sú rovnaké nastavenia.
Skontrolujte, či je klientsky certifikát kľúčom, a nie iba kotvou dôvery
Import certifikátu CA dá telefónu niečo, čím môže bránu overiť. Nedá mu klientsku identitu a autentifikácia certifikátom potrebuje klientsky koncový certifikát a jeho súkromný kľúč doručené spoločne schválenou cestou registrácie. PKCS#12 vytvorený bez súkromného kľúča vytvorí profil, ktorý sa čisto nainštaluje a nič neautentifikuje.
Klientsky koncový certifikát potrebuje aj identitu, ktorú očakáva strana RouterOS, čo znamená, že subjekt alebo alternatívne meno subjektu musí zodpovedať príslušnej konfigurácii identity. Vydávanie klientskych a serverových certifikátov z jednej CA robí reťaz pohodlným a nerobí oba koncové certifikáty zameniteľnými.
Skontrolujte, či politika RouterOS toto meno prijíma
Na bráne záznam partnera určuje režim výmeny a metódu autentifikácie a záznam identity spája prijatú vzdialenú identitu s certifikátom a s politikou, ktorá nasleduje. V RouterOS v7 sa táto dvojica vyjadruje záznamami partnera a identity v IPsec, napríklad partner IKEv2 s auth-method=digital-signature. Kontrolujte skutočný obsah ponuky v nainštalovanej verzii, nie návod písaný pre staršiu.
Tu je tiež nezhodu najlacnejšie opraviť, pretože brána vám môže povedať prijatú aj požadovanú identitu. Rozšírenie prijímanej identity, aby sa chyba umlčala, odstráni väzbu, ktorá dala nasadeniu zmysel.
Skontrolujte, ktorá fáza zlyhala, skôr než čokoľvek upravíte
Prečítajte si pokus na oboch koncoch a klasifikujte ho pred zmenou návrhu. Nezhoda návrhu, chýbajúci podpisový kľúč, nedôveryhodný vydavateľ, nesprávny identifikátor partnera a odmietnutá autorizácia klienta vyzerajú z telefónu všetky ako mŕtvy tunel a každé má iného vlastníka. Zmena všetkých piatich nastavení naraz zaručí, že sa z výsledku nič nedozviete.
Zaznamenajte predloženú identitu, očakávanú identitu, vydavateľa a sériové číslo certifikátu a názov príslušnej politiky, pričom súkromné kľúče a tajomstvá profilu držte mimo tohto záznamu. Keď autentifikácia uspeje, otestujte súkromnú službu a jej odpoveď, pretože prideľovanie adries, selektory, DNS a prístupová politika musia po skončení výmeny IKE stále fungovať.