VPN Android verso Cisco IOS: il contratto da ottenere per primo

Il telefono deve raggiungere un gateway Cisco. Qualcuno ha già indicato il client da installare. È la parte sbagliata del processo, ed è per questo che il tunnel fallisce dopo un'ora passata a ridigitare le credenziali.

La prima cosa che serve è un contratto di connessione: protocollo, autenticazione, identità, materiale di fiducia, assegnazione degli indirizzi e routing, scritto da chi gestisce il gateway.

Ottienilo per iscritto e la scelta del client diventa una ricerca. Saltalo e ogni guasto sembra una password sbagliata.

Fate la raccolta prima di installare qualcosa

Inviate al responsabile del gateway un elenco e chiedete risposte, non un nome di prodotto. Nove punti coprono completamente un profilo di accesso remoto:

1. Il nome host o l'indirizzo del gateway che il client deve chiamare, e se è raggiungibile dall'esterno.
2. Il protocollo e la versione: IKEv2, un'altra generazione di IPsec o un servizio basato su TLS.
3. L'identità del peer attesa dal gateway, e ciò che esso stesso presenta in cambio.
4. Materiale di fiducia: quale CA firma il certificato del gateway, o se si usa una chiave precondivisa.
5. Autenticazione utente: certificato, nome utente e password EAP, oppure una chiave precondivisa.
6. Il pool di indirizzi in cui atterra il client, con maschera e gateway.
7. I server DNS da usare dentro il tunnel, e se il client deve accettarli.
8. I prefissi di destinazione consentiti, e se il traffico esterno a essi va bloccato.
9. Le versioni client supportate e le versioni del sistema operativo del telefono, più eventuali requisiti di registrazione.

Due di questi punti causano la maggior parte dei guasti evitabili. Senza il materiale di fiducia non potete validare il gateway, quindi un client corretto sembra guasto. Senza i prefissi consentiti non potete distinguere una restrizione di routing da un problema di servizio.

Il nome del fornitore non è un protocollo

Cisco IOS e IOS XE offrono diverse soluzioni di accesso remoto, e non condividono un unico formato di trasmissione. IKEv2 con un profilo in stile FlexVPN non è lo stesso servizio di una configurazione IKEv1 più vecchia, e un servizio client basato su TLS è ancora un altro prodotto, spesso su un'altra piattaforma nello stesso ambiente.

Quindi un client il cui nome cita il fornitore del router non dimostra nulla. Può implementare bene uno di quei servizi e nessuno degli altri. Chiedete quale servizio è configurato, poi verificate se la documentazione del client nomina quel servizio come supportato.

La documentazione IKEv2 di Cisco separa la proposta, la policy, il profilo e il portachiavi come oggetti distinti. Questa struttura è utile quando leggete una configurazione che qualcuno vi incolla: vi dice quale oggetto contiene le impostazioni che contano per un telefono remoto, invece di trattare l'intero file come un blocco unico.

Cosa copre lo stack integrato di Android

Android espone un profilo IKEv2/IPsec di piattaforma tramite Ikev2VpnProfile, con tipi di autenticazione separati per una chiave precondivisa, un certificato RSA e nome utente e password EAP. Il riferimento a Ikev2VpnProfile è l'autorità su ciò che il builder accetta, inclusi il nome host del gateway e la CA radice del server usata per validarlo.

Quell'API è una dichiarazione di capacità, non una promessa di compatibilità. Dice che la piattaforma sa fare IKEv2 con quei tipi di autenticazione. Non dice che una data schermata Impostazioni OEM esponga ogni campo, né che un file di profilo esportato da un altro prodotto venga importato.

Significa anche che lo stack integrato non vi salverà se il gateway esegue un servizio che la piattaforma non implementa. In quel caso serve il client del fornitore supportato dall'operatore, installato e configurato come documenta l'operatore, invece di una soluzione improvvisata su un protocollo che il telefono non parla.

Testate nell'ordine in cui è scritto il contratto

Validate uno strato alla volta e fermatevi al primo guasto, perché i test successivi sono privi di senso finché i precedenti non passano.

Fiducia. Se il client rifiuta il certificato del gateway, nient'altro conta. Confermate che la CA ricevuta firmi il certificato presentato dal gateway e che il nome host chiamato vi compaia. Lasciate attiva la validazione; disattivarla trasforma un problema di identità in un rischio di intercettazione.

Autenticazione. Credenziali rifiutate e una proposta non corrispondente producono errori diversi ma guasti dall'aspetto simile. Il log del gateway è decisivo: dirà se la proposta era accettabile prima di dire qualcosa sull'utente.

Indirizzo e DNS. Confermate che il telefono abbia ricevuto un indirizzo dal pool documentato, poi risolvete un nome interno. Un tunnel che sale con un indirizzo e senza resolver sembra connesso e si comporta come se nulla funzionasse.

Raggiungibilità. Testate una destinazione consentita per indirizzo, poi per nome. Se l'indirizzo funziona e il nome no, siete tornati al DNS. Se non funziona nessuno dei due, confrontate il prefisso che state testando con l'elenco consentito prima di toccare il client.

Modalità di guasto e il rollback

Tenete il profilo funzionante precedente esportato e documentato prima di cambiare qualcosa, incluso l'alias della CA e il pool di indirizzi. Il rollback allora significa ripristinare un profilo noto, non ricostruirlo a memoria durante un'interruzione.

Quando funziona, annotate le nove risposte della raccolta accanto al profilo. Il prossimo telefono, il prossimo aggiornamento del sistema e la prossima modifica del gateway diventano un confronto con un documento invece di un altro pomeriggio di congetture.