iPhone IKEv2 verso RouterOS: quale identificatore va dove
Quattro affermazioni separate decidono un tunnel IKEv2 su iOS: l'indirizzo composto, l'identità server attesa, l'identità client rivendicata e il materiale del certificato.
Raggiungere il gateway MikroTik risolve solo la metà trasporto di una distribuzione IKEv2 e nient'altro. Poi quattro affermazioni separate decidono se il tunnel si forma: l'indirizzo composto dal telefono, l'identità del server che si aspetta, l'identità che rivendica per sé e il materiale del certificato che sostiene quella rivendicazione. Verificale in quest'ordine e fermati alla prima che non concorda con ciò che il gateway presenta. Ognuna si modifica in un punto diverso, ed è per questo che una modifica errata di solito sposta il guasto invece di risolverlo.
| 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 |
Verifica i campi del profilo nell'ordine in cui lo scambio li usa
L'indirizzo remoto è la destinazione del primo pacchetto IKE e nient'altro. L'identificatore remoto è ciò che il telefono si aspetta che il gateway dimostri di essere, ed è un nome, non una rotta. Compilare entrambi con lo stesso nome host funziona quando il certificato del gateway porta quel nome, e fallisce in un modo che sembra un problema di routing quando non lo porta. Leggi il profilo come una sequenza di affermazioni, non come un elenco di campi da compilare.
L'identificatore locale è la rivendicazione del telefono stesso, e deve essere un nome che la voce di identità di RouterOS accetta per il certificato client presentato dal telefono. Se i due non concordano, il gateway rifiuta la connessione dopo che il certificato stesso è stato validato, e il registro sembra un problema di autorizzazione anziché di denominazione.
Verifica gli identificatori rispetto a ciò che il gateway presenta
Una voce peer di RouterOS configurata per l'autenticazione con certificato presenta il proprio certificato, e la sua identità deriva da quel certificato salvo diversa configurazione. Se l'identificatore remoto del telefono nomina il nome DNS del gateway, il certificato del gateway ha bisogno di quel nome in un punto che il telefono accetterà, di solito un nome alternativo del soggetto. Un certificato emesso per un altro nome comune non verrà validato anche se la chiave e la catena sono perfette.
I profili Apple gestiti possono anche portare un vincolo sul nome del certificato valutato in aggiunta ai campi dell'identificatore. Ispeziona il payload invece di dedurre il nome di validazione da ciò che mostra la schermata delle impostazioni, perché le due cose non sono la stessa impostazione.
Verifica che il certificato client sia una chiave, non solo un'ancora di fiducia
Importare un certificato CA dà al telefono qualcosa con cui validare il gateway. Non gli dà un'identità client, e l'autenticazione con certificato richiede il certificato foglia client e la sua chiave privata consegnati insieme tramite il percorso di registrazione approvato. Un PKCS#12 creato senza la chiave privata produce un profilo che si installa pulito e non autentica nulla.
La foglia client ha bisogno anche di un'identità che il lato RouterOS si aspetta, il che significa che il soggetto o il nome alternativo del soggetto deve corrispondere alla configurazione di identità corrispondente. Emettere certificati client e server da un'unica CA rende comoda la catena e non rende intercambiabili le due foglie.
Verifica che la policy di RouterOS accetti quel nome
Sul gateway, la voce peer imposta la modalità di scambio e il metodo di autenticazione, e la voce di identità lega l'identità remota accettata a un certificato e alla policy che segue. In RouterOS v7 questa coppia si esprime tramite le voci peer e identità di IPsec, per esempio un peer IKEv2 con auth-method=digital-signature. Controlla il contenuto reale del menu della versione installata, non una guida scritta per una precedente.
Qui una discrepanza è anche la meno costosa da correggere, perché il gateway può dirti sia l'identità ricevuta sia quella desiderata. Ampliare l'identità accettata per zittire l'errore elimina il legame che dava senso alla distribuzione.
Verifica quale fase è fallita prima di modificare qualcosa
Leggi il tentativo su entrambi i lati e classificalo prima di cambiare una proposta. Una discrepanza di proposta, una chiave di firma mancante, un emittente non attendibile, un identificatore peer errato e un'autorizzazione client rifiutata sembrano tutte un tunnel morto dal telefono, e ognuna ha un responsabile diverso. Cambiare tutte e cinque le impostazioni insieme garantisce che non imparerai nulla dal risultato.
Annota l'identità presentata, l'identità attesa, l'emittente e il numero di serie del certificato e il nome della policy pertinente, tenendo le chiavi private e i segreti del profilo fuori da quel registro. Una volta riuscita l'autenticazione, prova un servizio privato e la sua risposta, perché assegnazione degli indirizzi, selettori, DNS e policy di accesso devono ancora funzionare dopo la fine dello scambio IKE.