iPhone IKEv2 naar RouterOS: welke identificatie hoort waar
Vier afzonderlijke claims bepalen een IKEv2-tunnel op iOS: het gekozen adres, de verwachte serveridentiteit, de opgeëiste clientidentiteit en het certificaatmateriaal.
De MikroTik-gateway bereiken lost alleen de transporthelft van een IKEv2-implementatie op en niets anders. Daarna bepalen vier afzonderlijke claims of de tunnel tot stand komt: het adres dat de telefoon kiest, de serveridentiteit die hij verwacht, de identiteit die hij voor zichzelf opeist, en het certificaatmateriaal dat die claim onderbouwt. Controleer ze in die volgorde, en stop bij de eerste die niet overeenkomt met wat de gateway presenteert. Elk wordt op een andere plek bewerkt, waardoor een verkeerde bewerking de fout meestal verplaatst in plaats van haar te verhelpen.
| 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 |
Controleer de profielvelden in de volgorde waarin de uitwisseling ze gebruikt
Het externe adres is de bestemming van het eerste IKE-pakket en niets meer. De externe identificatie is wat de telefoon verwacht dat de gateway bewijst te zijn, en het is een naam, geen route. Beide vullen met dezelfde hostnaam werkt wanneer het certificaat van de gateway die naam draagt, en mislukt op een manier die op een routeringsprobleem lijkt wanneer dat niet zo is. Lees het profiel als een reeks claims, niet als een lijst met velden om in te vullen.
De lokale identificatie is de eigen claim van de telefoon, en het moet een naam zijn die de identiteitsvermelding van RouterOS accepteert voor het clientcertificaat dat de telefoon presenteert. Als de twee niet overeenkomen, weigert de gateway de verbinding nadat het certificaat zelf is gevalideerd, en de log lijkt op een autorisatieprobleem in plaats van een naamprobleem.
Controleer de identificaties tegen wat de gateway presenteert
Een RouterOS-peervermelding die is ingesteld voor certificaatauthenticatie presenteert zijn eigen certificaat, en de identiteit ervan komt uit dat certificaat tenzij u anders hebt geconfigureerd. Als de externe identificatie van de telefoon de DNS-naam van de gateway noemt, heeft het certificaat van de gateway die naam nodig op een plek die de telefoon accepteert, meestal een alternatieve subjectnaam. Een certificaat dat voor een andere common name is uitgegeven, valideert niet, zelfs niet als de sleutel en de keten perfect zijn.
Beheerde Apple-profielen kunnen ook een certificaatnaambeperking bevatten die naast de identificatievelden wordt geëvalueerd. Inspecteer de payload in plaats van de validatienaam af te leiden uit wat het instellingenscherm toont, want dat zijn niet dezelfde instelling.
Controleer dat het clientcertificaat een sleutel is, niet alleen een vertrouwensanker
Het importeren van een CA-certificaat geeft de telefoon iets om de gateway mee te valideren. Het geeft de telefoon geen clientidentiteit, en certificaatauthenticatie vereist het clientbladeertificaat en de bijbehorende persoonlijke sleutel, samen geleverd via het goedgekeurde registratiepad. Een PKCS#12 zonder de persoonlijke sleutel levert een profiel op dat netjes installeert en niets authenticeert.
Het clientblad heeft ook een identiteit nodig die de RouterOS-kant verwacht, wat betekent dat het subject of de alternatieve subjectnaam moet overeenkomen met de bijbehorende identiteitsconfiguratie. Client- en servercertificaten van één CA uitgeven maakt de keten handig en maakt de twee bladeren niet uitwisselbaar.
Controleer dat het RouterOS-beleid die naam accepteert
Op de gateway stelt de peervermelding de uitwisselingsmodus en de authenticatiemethode in, en de identiteitsvermelding bindt de geaccepteerde externe identiteit aan een certificaat en aan het beleid dat volgt. In RouterOS v7 wordt dat paar uitgedrukt via de IPsec-peer- en identiteitsvermeldingen, bijvoorbeeld een IKEv2-peer met auth-method=digital-signature. Controleer de werkelijke menu-inhoud van uw geïnstalleerde release, niet een handleiding die voor een oudere is geschreven.
Hier is een afwijking ook het goedkoopst te verhelpen, omdat de gateway u zowel de ontvangen als de gewenste identiteit kan noemen. Het accepteren van een bredere identiteit om de fout te dempen verwijdert de binding die de implementatie betekenis gaf.
Controleer welke fase is mislukt voordat u iets bewerkt
Lees de poging aan beide kanten en classificeer die voordat u een voorstel wijzigt. Een afwijking in het voorstel, een ontbrekende ondertekeningssleutel, een niet-vertrouwde uitgever, een verkeerde peer-identificatie en een geweigerde clientautorisatie zien er vanaf de telefoon allemaal uit als een dode tunnel, en elk heeft een andere eigenaar. Alle vijf instellingen tegelijk wijzigen garandeert dat u niets van het resultaat leert.
Noteer de gepresenteerde identiteit, de verwachte identiteit, de uitgever en het serienummer van het certificaat en de naam van het relevante beleid, en houd persoonlijke sleutels en profielgeheimen buiten die registratie. Als de authenticatie slaagt, test dan een particuliere dienst en het antwoord ervan, want adrestoewijzing, selectors, DNS en toegangsbeleid moeten na afloop van de IKE-uitwisseling nog steeds werken.