iPhone IKEv2 drejt RouterOS: cili identifikues shkon ku
Katër pretendime të veçanta vendosin një tunel IKEv2 në iOS: adresa e telefonuar, identiteti i pritur i serverit, identiteti i klientit i pretenduar dhe materiali i certifikatës.
Arritja e gateway-t MikroTik zgjidh vetëm gjysmën e transportit të një vendosjeje IKEv2 dhe asgjë tjetër. Më pas katër pretendime të veçanta vendosin nëse tuneli formohet: adresa që telefonon telefoni, identiteti i serverit që pret, identiteti që pretendon për vete dhe materiali i certifikatës që mbështet atë pretendim. Kontrollojini në atë rend dhe ndaluni te i pari që nuk përputhet me atë që paraqet gateway-i. Secili redaktohet në një vend tjetër, prandaj një redaktim i gabuar zakonisht e zhvendos dështimin në vend që ta rregullojë.
| 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 |
Kontrolloni fushat e profilit në rendin që përdor shkëmbimi
Adresa e largët është destinacioni i paketës së parë IKE dhe asgjë më shumë. Identifikuesi i largët është ajo që telefoni pret që gateway-i të provojë se është, dhe është emër, jo rrugë. Plotësimi i të dyjave me të njëjtin emër hosti funksionon kur certifikata e gateway-t e mban atë emër, dhe dështon në një mënyrë që duket si problem rrugëtimi kur nuk e mban. Lexojeni profilin si një sekuencë pretendimesh, jo si një listë fushash për t'u plotësuar.
Identifikuesi lokal është pretendimi i vetë telefonit, dhe duhet të jetë një emër që hyrja e identitetit në RouterOS e pranon për certifikatën e klientit që paraqet telefoni. Nëse të dy nuk përputhen, gateway-i e refuzon lidhjen pasi vetë certifikata është vlefshmëruar, dhe regjistri duket si problem autorizimi e jo emërtimi.
Kontrolloni identifikuesit kundrejt asaj që paraqet gateway-i
Një hyrje partneri në RouterOS e konfiguruar për vërtetim me certifikatë paraqet certifikatën e vet, dhe identiteti i saj nxirret nga ajo certifikatë nëse nuk keni konfiguruar ndryshe. Nëse identifikuesi i largët i telefonit përmend emrin DNS të gateway-t, certifikata e gateway-t e kërkon atë emër në një vend që telefoni do ta pranojë, zakonisht në një emër alternativ të subjektit. Një certifikatë e lëshuar për një emër tjetër të përbashkët nuk do të vlefshmërohet edhe pse çelësi dhe zinxhiri janë të përsosur.
Profilet e Apple të menaxhuara mund të mbajnë gjithashtu një kufizim emri certifikate që vlerësohet përveç fushave të identifikuesit. Inspektoni ngarkesën në vend që të nxirrni emrin e vlefshmërimit nga ajo që tregon ekrani i cilësimeve, sepse të dyja nuk janë e njëjta cilësim.
Kontrolloni se certifikata e klientit është çelës, jo vetëm ankorë besimi
Importimi i një certifikate CA i jep telefonit diçka me të cilën të vlefshmërojë gateway-in. Nuk i jep një identitet klienti, dhe vërtetimi me certifikatë kërkon certifikatën gjethe të klientit dhe çelësin e saj privat të dorëzuar së bashku përmes rrugës së miratuar të regjistrimit. Një PKCS#12 i ndërtuar pa çelësin privat prodhon një profil që instalohet pastër dhe nuk vërteton asgjë.
Gjethja e klientit ka nevojë edhe për një identitet që pret ana e RouterOS, që do të thotë se subjekti ose emri alternativ i subjektit duhet të përputhet me konfigurimin përkatës të identitetit. Lëshimi i certifikatave të klientit dhe të serverit nga një CA e bën zinxhirin të përshtatshëm dhe nuk i bën dy gjethet të këmbyeshme.
Kontrolloni se politika e RouterOS e pranon atë emër
Në gateway, hyrja e partnerit përcakton mënyrën e shkëmbimit dhe metodën e vërtetimit, dhe hyrja e identitetit lidh identitetin e largët të pranuar me një certifikatë dhe me politikën që vijon. Në RouterOS v7 ai çift shprehet përmes hyrjeve të partnerit dhe të identitetit të IPsec, për shembull një partner IKEv2 me auth-method=digital-signature. Kontrolloni përmbajtjen reale të menysë në versionin e instaluar, jo një udhëzues të shkruar për një më të vjetër.
Këtu mospërputhja rregullohet edhe më lirë, sepse gateway-i mund t'ju thotë si identitetin e marrë ashtu edhe atë të dëshiruar. Zgjerimi i identitetit të pranuar për të heshtur gabimin heq lidhjen që i dha kuptim vendosjes.
Kontrolloni cila fazë dështoi përpara se të redaktoni çdo gjë
Lexoni përpjekjen në të dy skajet dhe klasifikojeni përpara se të ndryshoni një propozim. Mospërputhja e propozimit, një çelës nënshkrimi që mungon, një lëshues jo i besueshëm, një identifikues i gabuar partneri dhe një autorizim klienti i refuzuar duken të gjitha si tunel i vdekur nga telefoni, dhe secili ka një përgjegjës tjetër. Ndryshimi i të pesë cilësimeve përnjëherë garanton që nuk do të mësoni asgjë nga rezultati.
Regjistroni identitetin e paraqitur, identitetin e pritur, lëshuesin dhe numrin serik të certifikatës dhe emrin e politikës përkatëse, duke mbajtur çelësat privatë dhe sekretet e profilit jashtë atij regjistri. Kur vërtetimi të ketë sukses, provoni një shërbim privat dhe përgjigjen e tij, sepse ndarja e adresave, përzgjedhësit, DNS dhe politika e aksesit duhet të funksionojnë akoma pasi shkëmbimi IKE të përfundojë.