Vecchio IOS SSL VPN: pacchetto, profilo, gateway e sessione

Trovate un programma di installazione client sulla memoria flash del router e concludete che l’SSL VPN è configurata. È un componente su quattro, e gli altri tre decidono se qualcuno può connettersi. Nel vecchio IOS SSL VPN le parti sono oggetti distinti: il pacchetto client di testa, un profilo client opzionale, il gateway WebVPN che termina TLS, e il contesto più la politica di gruppo che contengono l’autenticazione e le impostazioni di sessione. Se ne manca uno, il guasto appare identico dall’esterno.

L’esempio di configurazione IOS SSL VPN di Cisco, costruito su IOS 15.3 con AnyConnect 3.1, è utile proprio perché tiene separati quegli oggetti. Leggetelo come descrizione di quella vecchia implementazione, non come raccomandazione a distribuire quelle versioni.

Primo, il pacchetto: che cosa è e che cosa non è

Il pacchetto di testa fornisce il software client per una sola piattaforma. Non è né il profilo né il listener, e un file che giace sulla memoria flash dimostra solo che qualcuno ha caricato qualcosa. Non dimostra che una sessione lo abbia mai usato, che la piattaforma corrisponda al dispositivo dell’utente, né che il gateway vi faccia riferimento.

Verificate il nome esatto del file, la piattaforma a cui è destinato e il punto in cui la configurazione lo indica. Un pacchetto Windows non vi dice nulla sui telefoni, e un file caricato che nessun oggetto gateway menziona è archiviazione, non configurazione. Un pacchetto che corrisponde alla piattaforma ma non viene mai associato al servizio non sarà offerto a nessun utente. Nemmeno uno il cui nome file differisce dal valore atteso dalla configurazione.

Secondo, il profilo: impostazioni, non software

Un profilo client opzionale porta impostazioni che un amministratore prepara separatamente, come elenchi di server o preferenze del client. Confonderlo con un programma di installazione è comune perché entrambi arrivano come file con nomi simili. Se la distribuzione si aspetta un profilo, la sua assenza cambia ciò che il client fa dopo la connessione, non se si connette.

Inventariate entrambi gli artefatti e annotate a quale il gateway fa realmente riferimento. Quella singola riga evita un’intera classe di ticket di assistenza in cui due persone parlano di file diversi.

Terzo, il listener e l’identità TLS

L’oggetto gateway definisce l’indirizzo e la porta raggiunti dal mondo esterno e il certificato presentato durante la stretta di mano. Un browser che raggiunge una pagina di portale, un client che completa l’autenticazione e un’applicazione che raggiunge un server privato sono tre osservazioni distinte, e solo la prima è un test del listener. Quando la stretta di mano fallisce, nulla a valle conta ancora, quindi verificate la catena dei certificati e il nome prima di modificare qualsiasi politica.

Scrivete da qualche parte l’identità attesa. Un certificato rinnovato o sostituito è il motivo più frequente per cui una distribuzione che funzionava il mese scorso smette di funzionare questo mese.

Quarto, il contesto e la politica con il suo modello virtuale

Il contesto e la politica di gruppo legano l’autenticazione al comportamento della sessione: pool di indirizzi, route separate, DNS e quali reti interne un utente può raggiungere. L’esempio documentato collega il suo contesto a un modello virtuale che fornisce il comportamento dell’interfaccia per sessione, e questi oggetti lato server esistono indipendentemente da ciò che un utente scarica.

Quando un utente si autentica ma non raggiunge nulla, il guasto di solito sta qui e non nel client. Confrontate il pool, le route consegnate al client e l’ACL che consente il traffico successivo, e verificatele rispetto a ciò che l’utente riferisce, non a ciò che il progetto intendeva.

Verificate in ordine e fermatevi al primo guasto

Percorrete i quattro componenti nell’ordine in cui una connessione li incontra: listener, autenticazione, politica, poi comportamento del client. Confermate TLS con l’identità attesa, autenticate un account affidabile, leggete l’indirizzo e le route assegnati dalla sessione, e solo dopo confrontate la piattaforma del client con il pacchetto. Fermarsi al primo guasto tiene in gioco una sola variabile, ed è la differenza tra una riparazione e una supposizione.

Per un telefono o qualsiasi client fuori da quell’esempio storico da scrivania, ottenete il vero contratto client e gateway supportato invece di supporre che il flusso di lavoro Windows si generalizzi. Cambiare un protocollo richiesto non trasformerà un profilo IKEv2 in questo servizio SSL VPN, e installare un pacchetto desktop non dimostra nulla sul supporto mobile.