iPhone IKEv2 a RouterOS felé: melyik azonosító hova kerül
Négy különálló állítás dönt az iOS-es IKEv2-alagútról: a tárcsázott cím, az elvárt kiszolgálóidentitás, az igényelt ügyfélidentitás és a tanúsítvány-anyag.
A MikroTik átjáró elérése egy IKEv2-telepítésnek csak a szállítási felét rendezi, semmi mást. Ezután négy különálló állítás dönti el, létrejön-e az alagút: a telefon által tárcsázott cím, az elvárt kiszolgálóidentitás, a magának igényelt identitás és az igényt alátámasztó tanúsítvány-anyag. Ebben a sorrendben ellenőrizze őket, és álljon meg az elsőnél, amely nem egyezik azzal, amit az átjáró bemutat. Mindegyik máshol szerkeszthető, ezért a hibás szerkesztés rendszerint elmozdítja a hibát ahelyett, hogy javítaná.
| 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 |
Ellenőrizze a profil mezőit abban a sorrendben, ahogy a csere használja őket
A távoli cím az első IKE-csomag célja és semmi több. A távoli azonosító az, amiről a telefon elvárja, hogy az átjáró bizonyítsa: ő az, és ez név, nem útvonal. Mindkettőt ugyanazzal a gazdanévvel kitölteni akkor működik, ha az átjáró tanúsítványa tartalmazza ezt a nevet, és útvonalproblémának látszó módon hiúsul meg, ha nem. A profilt állítások sorozataként olvassa, ne kitöltendő mezők listájaként.
A helyi azonosító a telefon saját állítása, és olyan névnek kell lennie, amelyet a RouterOS identitásbejegyzése elfogad a telefon által bemutatott ügyféltanúsítványhoz. Ha a kettő nem egyezik, az átjáró a kapcsolatot a tanúsítvány sikeres érvényesítése után utasítja el, és a napló engedélyezési, nem pedig elnevezési problémának látszik.
Ellenőrizze az azonosítókat azzal szemben, amit az átjáró bemutat
A tanúsítványos hitelesítésre beállított RouterOS-partnerbejegyzés a saját tanúsítványát mutatja be, és identitása abból a tanúsítványból származik, hacsak nem állított be mást. Ha a telefon távoli azonosítója az átjáró DNS-nevét nevezi meg, az átjáró tanúsítványának erre a névre olyan helyen van szüksége, amelyet a telefon elfogad, jellemzően a tulajdonos alternatív nevében. Egy másik köznévhez kiállított tanúsítvány akkor sem érvényesül, ha a kulcs és a lánc kifogástalan.
A felügyelt Apple-profilok az azonosítómezőkön felül értékelt tanúsítványnév-korlátot is hordozhatnak. Vizsgálja meg a hasznos terhet, ne a beállítások képernyőjén láthatóból következtessen az érvényesítési névre, mert a kettő nem ugyanaz a beállítás.
Ellenőrizze, hogy az ügyféltanúsítvány kulcs, nem csupán bizalmi horgony
Egy CA-tanúsítvány importálása ad a telefonnak valamit, amivel az átjárót érvényesítheti. Nem ad neki ügyfélidentitást, a tanúsítványos hitelesítéshez pedig az ügyfél levéltanúsítványára és annak titkos kulcsára van szükség, együtt, a jóváhagyott regisztrációs úton. A titkos kulcs nélkül épített PKCS#12 olyan profilt ad, amely tisztán települ és semmit nem hitelesít.
Az ügyfél levéltanúsítványának olyan identitásra is szüksége van, amelyet a RouterOS-oldal elvár, vagyis a tulajdonosnak vagy a tulajdonos alternatív nevének egyeznie kell a megfelelő identitáskonfigurációval. Az ügyfél- és kiszolgálótanúsítványok egy CA-ból történő kiállítása kényelmessé teszi a láncot, és nem teszi a két levelet egymással felcserélhetővé.
Ellenőrizze, hogy a RouterOS-szabályzat elfogadja ezt a nevet
Az átjárón a partnerbejegyzés állítja be a csere módját és a hitelesítési módszert, az identitásbejegyzés pedig az elfogadott távoli identitást tanúsítványhoz és a következő szabályzathoz köti. A RouterOS v7-ben ezt a párost az IPsec partner- és identitásbejegyzések fejezik ki, például egy IKEv2-partner a auth-method=digital-signature beállítással. A telepített kiadás tényleges menütartalmát ellenőrizze, ne egy régebbihez írt útmutatót.
Itt a legolcsóbb az eltérést javítani, mert az átjáró meg tudja mondani a fogadott és a kívánt identitást is. Az elfogadott identitás kiszélesítése a hiba elnémítására eltávolítja azt a kötést, amely értelmet adott a telepítésnek.
Ellenőrizze, melyik szakasz hiúsult meg, mielőtt bármit szerkesztene
Olvassa el a kísérletet mindkét oldalon, és osztályozza, mielőtt módosít egy javaslatot. A javaslat eltérése, hiányzó aláírókulcs, nem megbízható kibocsátó, hibás partnerazonosító és elutasított ügyfél-engedélyezés mind halott alagútnak látszik a telefonról, és mindegyiknek más a felelőse. Mind az öt beállítás egyszerre történő módosítása garantálja, hogy semmit nem tanul az eredményből.
Jegyezze fel a bemutatott identitást, az elvárt identitást, a tanúsítvány kibocsátóját és sorozatszámát, valamint a vonatkozó szabályzat nevét, és tartsa a titkos kulcsokat és a profil titkait ezen a feljegyzésen kívül. Ha a hitelesítés sikerül, teszteljen egy privát szolgáltatást és annak válaszát, mert a címkiosztásnak, a szelektoroknak, a DNS-nek és a hozzáférési szabályzatnak az IKE-csere után is működnie kell.