Pianificare impostazioni IKEv2 adatte a più di un client

Un profilo funzionante su un desktop è un test riuscito di un solo client. Non è una distribuzione multipiattaforma, e trattarlo come tale produce il noto schema di assistenza: Windows si connette, il telefono fallisce il controllo dell’identità e il portatile gestito si riconnette ogni volta che si riattiva. Le differenze sono reali e in gran parte prevedibili, per questo il piano deve essere una matrice e non uno screenshot.

Prima decidete il contratto di identità

Documentate l’identità del server, la fiducia nel certificato e il metodo di autenticazione del client prima di parlare di algoritmi. Questi tre elementi decidono se un client può autenticarsi, e sono le parti che le piattaforme esprimono in modo diverso.

Verificate come ogni piattaforma nomina l’identificatore atteso e come gestisce i nomi alternativi del soggetto. Un profilo che accetta un nome server su un client può rifiutare lo stesso certificato su un altro, perché il campo dell’identificatore viene compilato con un valore diverso.

Poi scegliete l’intersezione crittografica

Confrontate le proposte che ogni client supportato può offrire e scegliete un’intersezione moderna che il gateway consenta anche. Non abilitate una lista legacy sovradimensionata solo perché un vecchio dispositivo si connetta, perché quella lista diventa l’impostazione predefinita del gateway per tutti quelli che seguono. Annotate perché ogni opzione legacy è ancora lì. Se nessuno sa indicare il dispositivo che ne ha bisogno, non è un requisito.

Tenete separate le impostazioni IKE e CHILD nel piano. Una proposta accettabile per lo scambio IKE non è automaticamente accettabile per il traffico protetto, e le due vengono negoziate separatamente. Un gateway che accetta una proposta a uno strato può comunque rifiutarla all’altro, e il registro mostrerà un errore che sembra il primo strato sia riuscito.

Fornite le credenziali tramite un processo verificato e tenete password utente, segreto condiviso e chiave privata del client nei rispettivi campi. Prove ed errori su caselle dai nomi simili sono il modo in cui un test funzionante diventa non riproducibile.

Provate il ciclo di vita, non lo stato stabile

Per ogni client, provate l’autenticazione iniziale, l’applicazione prevista, la risoluzione DNS e la copertura delle famiglie di indirizzi. Poi esercitate le parti che compaiono solo più tardi: rinnovo, sospensione e un normale cambio di rete.

Il supporto MOBIKE e il comportamento di riautenticazione possono differire dal risultato stabile appena misurato. Registrate l’evento e lo stato dell’associazione in quel momento, non solo se l’interfaccia alla fine sembra connessa.

Definite cosa può fare il traffico diretto mentre la VPN non è disponibile. È una decisione di policy separata dal fatto che il client si riconnetta, e la maggior parte delle distribuzioni risponde alla seconda domanda ignorando la prima. Scrivete la risposta nelle note di distribuzione accanto ai nomi dei profili. Qualcuno ne avrà bisogno durante un’interruzione e non avrà tempo di ricostruirla.

Usate i controlli di identità del server quando una piattaforma non è d’accordo

Quando un profilo funziona su una piattaforma e un’altra rifiuta il suo nome, confrontate l’identificatore che il client ha realmente inviato con gli identificatori che il certificato porta. Questo confronto risolve la maggior parte di questi casi più in fretta che cambiare gli elenchi di cifratura.

Conservate la matrice testata con l’origine della configurazione e la procedura di aggiornamento. Quando termina il supporto per un vecchio client, rimuovete la sua eccezione deliberatamente invece di lasciare impostazioni di compatibilità più deboli nascoste nel gateway per il prossimo audit. La documentazione IKEv2 di strongSwan è un riferimento utile su come si configurano gli scambi.