Understanding IPSec tunnels (L2L)

Nel mio ruolo attuale, mi occupo di L2L (LAN to LAN) tunnel abbastanza frequentemente. Sono il modo “economico” per collegare due posizioni rispetto ai circuiti di accesso dedicati. L’unico requisito è avere l’hardware corretto e un IP statico “sempre attivo” in ogni posizione. Scherzo spesso che configurare un tunnel L2L su un ASA è facile e richiede solo 20 linee di configurazione nella CLI. Detto questo, come qualsiasi altra cosa nel mondo della rete, se non capisci come funziona la tecnologia, un giorno rimarrai bloccato. Digitare 20 linee di configurazione in una console e capire effettivamente cosa sta succedendo sono due cose completamente diverse. In questo post parlerò di IPSec basics, come si formano i tunnel e alcuni passaggi per la risoluzione dei problemi che puoi eseguire quando ti imbatti in problemi.

Terminologia
IPSec (Internet Protocol Security) – Di cosa stiamo parlando

IKE (Internet Key Exchange) – Pensate a IKE come il set di strumenti necessari per stabilire e mantenere una connessione sicura tra due endpoint. Fondamentalmente IKE consente alla connessione di formare e mantenere SAs (Associazioni di sicurezza) che sono la parte fondamentale di un tunnel IPSec

ISAKMP (Internet Security Association and Key Management Protocol) – ISAKMP è lo standard che definisce come lavorare con SAs. In altre parole, ISAKMP gestisce il modo in cui i SAS vengono creati, mantenuti, modificati e abbattuti. Hai notato la sovrapposizione? IKE e ISAKMP suonano terribilmente simili, vero? Questo perché lo sono. In realtà, Cisco nota anche questo nella loro documentazione.

” Internet Security Association and Key Management Protocol, chiamato anche IKE, è il protocollo di negoziazione che consente a due host di concordare come creare un’associazione di sicurezza IPSec. Ogni negoziazione ISAKMP è divisa in due sezioni chiamate Fase 1 e Fase 2.”

Indirizzo peer-A seconda del contesto, è l’indirizzo pubblico a un’estremità del tunnel o all’altra estremità del tunnel.

DH (Diffie-Hellman) – DH consente a due parti di condividere una chiave segreta su un canale insicuro. DH viene utilizzato durante la fase IKE 1 per scambiare chiavi e stabilire una chiave segreta sicura.

Set di criteri ISAKMP: un set di criteri che specifica l’algoritmo di crittografia IKE, l’algoritmo di autenticazione IKE, il tipo di autenticazione IKE, la versione DH e la durata del tunnel IKE. Il set di criteri ISAKMP viene utilizzato durante i negoziati IKE Phase 1. Per rendere questo ancora più confuso I set di criteri ISAKMP sono anche indicati come set di trasformazione ISAKMP, set di trasformazione IKE o semplicemente vecchi set di trasformazione

Set di trasformazione IPSec: un set di trasformazione è costituito da impostazioni rilevanti per la creazione del tunnel IPSec. Il set di trasformazione effettivo viene utilizzato durante la fase 2 di IKE e generalmente consiste solo nel tipo di crittografia e autenticazione IKE. Ancora una volta la parte confusa è che spesso alcune persone chiamano semplicemente questi set di trasformazione.

SAs (Associazioni di sicurezza) – Fondamentalmente è l’insieme di parametri IPSec su cui entrambi i lati del tunnel concordano. Farò una distinzione critica qui per quelli di noi in Cisco land. Ci saranno una ISAKMP SA e una IPSec SA. Ci sono diversi tunnel creati durante la creazione del tunnel IPSec. Basta ricordare che ISAKMP SA è considerato il risultato della fase IKE 1 e IPSec SA è considerato il risultato della fase IKE 2. Inoltre, una SA è solo una connessione a senso unico. Poiché la maggior parte del traffico tra endpoint richiede una comunicazione bidirezionale, ogni ASA creerà il proprio SA per parlare con l’altro peer.

Nonce – Un numero, solitamente utilizzato per una chiave di sicurezza, che viene utilizzato solo una volta. Se viene utilizzato una seconda volta di solito è un segno di un tentativo di connessione fraudolenta.

Terminology Summary-La terminologia VPN è davvero, davvero, davvero confusa. Basta provare a ricordare che ISAKMP e IKE sono talvolta usati in modo intercambiabile. Inoltre, transform-sets è un termine generale per un gruppo di impostazioni. Cerco di usare la frase solo quando mi riferisco a ciò che digito dopo “transform-set” nella CLI che viene utilizzata per specificare il tipo di autenticazione e crittografia per la fase 2 di IKE.

Il processo
Ora che conosciamo alcuni dei termini chiave possiamo iniziare a parlare di come si forma il tunnel IPSec. A mio parere, ci sono 4 fasi per la vita di un tunnel IPSec. Io li sotto e poi parleremo di loro

Fase 1 – Interessante il traffico genera la creazione del tunnel
Fase 2 – IKE Fase 1
Fase 3 – IKE Fase 2
Fase 4 – Terminazione del Tunnel

Alcune persone gettano una fase tra la mia fase 3 e 4 e l’elenco come ‘IPSec tunnel creato’, che il mio punto di vista non è in realtà una fase. Elencare il prodotto delle fasi da 1 a 3 non sembra giustificare la propria fase nella mia mente. In ogni caso, andiamo nel dettaglio su ciascuno di essi.

Fase 1 – Traffico interessante genera la creazione del tunnel
Quello che molte persone non sanno di IPSec è che è quello che io chiamo un servizio ‘on demand’. Cioè, una volta creato un tunnel, non è sempre attivo e funzionante. Quello che noi chiamiamo ‘traffico interessante’, innesca la creazione di un tunnel. La creazione del tunnel non richiede molto tempo ma può, nella maggior parte dei casi, essere notato quando si utilizza ping per testare. Nella maggior parte dei casi, quando provo a eseguire il ping da una macchina client attraverso il tunnel, la prima richiesta ICMP fallirà perché il tunnel viene caricato. Gli ICMP successivi passano correttamente. Il traffico interessante è definito sull’ASA con un ACL. Quindi l’ACL viene specificato all’interno della mappa crittografica dei tunnel con un comando “corrispondenza indirizzo”. Un esempio di ACL potrebbe essere simile a questo ip

access-list L2LCryptoMap extended permit ip <Local subnet> <Local mask> <Destination subnet>

Si dice all’ASA di abbinare il traffico proveniente dalla propria sottorete alla sottorete dall’altra parte del tunnel. Questo porta in primo piano la questione delle sottoreti private duplicate. Se la tua sottorete sull’interfaccia interna di entrambi gli ASA è la stessa, avrai problemi. Pensalo in questo modo, quando un client da un lato tenta di accedere a una risorsa dall’altra sottorete, non andrà da nessuna parte. Per impostazione predefinita, il client eseguirà l’ARP per una risposta perché ritiene che il client remoto a cui si sta tentando di accedere si trovi nella sua sottorete locale. Dal momento che non tenta di uscire dalla sottorete, il client non contatterà mai il gateway predefinito (l’interfaccia interna dell’ASA) e non formerai mai un tunnel. Anche se lo facessi, il traffico non fluirebbe ancora. Ci sono alcune cose’ difficili ‘ che possiamo fare per risolvere questo problema, ma non rientrano nel regno di questo blog. La situazione migliore è avere reti private uniche in ogni posizione.

Fase 2 – IKE Fase 1
Una volta che l’ASA riceve una richiesta per una subnet remota, che corrisponde a una mappa crittografica, inizia la fase 1 di IKE. L’obiettivo di IKE phase 1 è quello di impostare la connessione per IKE phase 2. Fondamentalmente, IKE phase 1 pone il lavoro di base per la connessione effettiva. In realtà crea una propria SA che a volte viene definita management SA. Questa gestione SA viene utilizzato da IKE fase 2 per creare i tunnel di dati effettivi. Da un punto di vista tecnico ci sono tre passi per IKE fase 1. Il primo passo è chiamato negoziazione politica. La negoziazione dei criteri si riduce alla ricerca di set di trasformazioni corrispondenti su ciascun endpoint. Prima dei moduli ISAKMP SA, ciascun endpoint deve concordare un set di criteri IKE corrispondente. I seguenti elementi devono corrispondere all’interno del criterio impostato su ciascun lato del tunnel.

-L’algoritmo di crittografia IKE
-L’algoritmo di autenticazione IKE
-La definizione della chiave IKE
-La versione Diffie Hellman
-La durata IKE

Ricorda, i set di criteri IKE sono associati al completamento della fase 1 di IKE. Un endpoint può avere un numero qualsiasi di set di criteri che vengono valutati in un ordine. Ad esempio, potresti avere il set di criteri 10, 20 e 30. Gli endpoint scorreranno i set di criteri in ordine, iniziando dal primo più basso fino a trovare una corrispondenza. Quindi, ha senso definire prima set di politiche più forti. Se sono definiti dopo i set di criteri più deboli, potresti trovare prima una corrispondenza più debole.

Ora, prima di andare troppo oltre nella fase 1 di IKE, è pertinente spiegare che ci sono due diversi tipi di fase 1 di IKE. Quello usato più spesso è chiamato ‘modalità principale’ e consiste di 6 messaggi scambiati tra pari. L’altro tipo è chiamato modalità ‘aggressiva’ e condensa i messaggi inviati tra peer in 3 messaggi. La modalità principale è più lenta nella configurazione ma più sicura. La modalità aggressiva è più veloce nella configurazione ma meno sicura. Non citarmi su questo, ma credo che la modalità principale sia usata di default. Non ho intenzione di immergermi nello specifico qui, entrambi compiono la stessa cosa e i dettagli che ho elencato sopra dovrebbero farti capire le grandi differenze.

Il nostro primo passo verso la fase 1 di IKE è stata la negoziazione delle politiche: i pari devono concordare un insieme di politiche corrispondenti. Lo fanno inviando i set di criteri l’uno all’altro per il confronto e trovando il set di criteri di corrispondenza più basso. Una volta completato, possiamo passare al passo successivo che è lo scambio di chiavi DH. Durante questo processo i peer si scambiano chiavi pubbliche che vengono utilizzate per stabilire il segreto condiviso. Al termine di questo processo, viene formata la Fase 1 SA (ISAKMP SA) e passiamo all’ultimo passaggio che è l’autenticazione peer.

Durante l’autenticazione peer, il metodo di autenticazione definito viene utilizzato per garantire che i dispositivi non autorizzati non formino connessioni sicure nella rete. Il più delle volte questo viene fatto con chiavi pre-condivise. Questo passaggio è piuttosto semplice, i peer controllano per assicurarsi che le chiavi corrispondano. Se non lo fanno, l’autenticazione non riesce. Se corrispondono passiamo alla fase 2 di IKE.

Fase 3 – IKE Fase 2
Mi piace pensare a IKE fase 2 come la costruzione effettiva del tunnel dati. Il lavoro fino a questo punto è stato principalmente quello di garantire che abbiamo un canale di comunicazione sicuro in atto in modo da poter costruire l’attuale IPSec SAs. Rispetto a IKE phase 1, IKE phase 2 ha solo un tipo di modalità che si chiama “modalità rapida”. La modalità rapida utilizza l’ISAKMP SA esistente creato in IKE phase 1 e crea l’IPSec SAs e gestisce gli scambi di chiavi. Il primo passo della modalità rapida consiste nel negoziare i set di trasformazione IPSec (non uguali ai set di criteri ISAKMP!!). I seguenti elementi devono corrispondere su entrambe le estremità per il SAs IPSec da formare.

-Il protocollo IPSec
-Il tipo di crittografia IPSec
-Il tipo di autenticazione IPSec
-La modalità IPSec
-La durata IPSec SA

Ora consente di prendere un breve momento per confrontare i transform-set da IKE fase 1 e fase 2. Di seguito è riportata una configurazione tipica di un ASA.

ISAKMP Policy Set
crypto isakmp policy 10
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400

IPSec transform
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

Vedi qualcosa di strano? Nel set di criteri ISAKMP è possibile vedere chiaramente i 5 pezzi richiesti del set di trasformazione che devono essere concordati. Nella trasformazione IPSec non è così chiaro. Questo perché la trasformazione definisce solo 3 dei 5 pezzi richiesti. L’esempio sopra definisce il protocollo IPSec (ESP), il tipo di autenticazione IPSec (SHA) e il tipo di crittografia IPSec (3DES). Non è necessario definire la modalità IPSec e la durata IPSec SA. Quando non lo sono, l’ASA assume semplicemente i seguenti valori di 28.800 per la durata SA e la modalità “tunnel” per tutti i set di trasformazioni. Di solito non cambio questi valori a meno che l’altro lato non li abbia cambiati.

Quindi, una volta che i set di trasformazione sono stati negoziati e abbinati, possiamo creare IPSec SAs. Come detto sopra, un SA è una connessione unidirezionale. Quindi, affinché il traffico fluisca in ogni modo, è necessario formare due SAS IPSec. L’ASA fa questo lavoro per voi, naturalmente, quindi non c’è molto dettaglio da condividere qui. Modalità rapida utilizza nonces per generare nuovo materiale chiave che impedisce attacchi di replay. Il terzo passo è il processo di rinegoziare periodicamente la connessione. Il SAS deve essere rigenerato prima della scadenza della durata del tunnel. La modalità rapida monitora questo e genera nuovi SAS prima che quelli vecchi scadano.

Fase 4-Terminazione tunnel
A questo punto abbiamo un tunnel VPN completamente funzionale! Il traffico dovrebbe passare in entrambe le direzioni. L’unica cosa che resta da fare è abbattere il tunnel se non c’è traffico interessante. I SAS vengono rigenerati solo se il traffico interessante continua a fluire. Se il traffico interessante smette di venire in SA è permesso di scadere dopo la sua vita è stata raggiunta. Se la SA è autorizzata a scadere, TUTTI i dati relativi alla SAS vengono eliminati dalla SA. La prossima volta che viene generato traffico interessante l’intero processo inizierà da zero.

Risoluzione dei problemi
Il problema più comune nella connettività IPSec è la mancata ricerca di corrispondenze trasformate per IKE phase 1 e 2. Se ti imbatti in problemi, la prima cosa che dovresti sempre fare è ricontrollare le impostazioni su entrambi i lati per assicurarti che corrispondano al 100%. La prossima cosa che puoi fare è dare un’occhiata al SAS sull’ASA e determinare se sono stati creati e se lo sono, quale stato hanno.

Per vedere la IKE Phase 1 SA emettere questo comando
ASA# show crypto isakmp sa

Per vedere la IKE Phase 2 SA emettere questo comando
ASA# show crypto ipsec sa

Se non hai una phase 1 SA allora non andrai molto lontano. Lo stato della SA ti dice un paio di cose. Ti dice se la SA è stato creato con la modalità principale o aggressivo, da che parte ha portato il tunnel, e ti dice anche lo stato dei negoziati. Uno sguardo a una tipica fase 1 SA è mostrato di seguito.

ASA # mostra crypto isakmp sa
Active SA: 1
Rekey SA: 0 (Un tunnel segnalerà 1 Attivo e 1 Rekey SA durante rekey)
Totale IKE SA: 1

1 IKE Peer: <Indirizzo IP peer>
Tipo : L2L Ruolo : responder
Rekey : no Stato : MM_ACTIVE

Come si può vedere dall’output di cui sopra, abbiamo una fase IKE 1 SA. Il tipo è ‘ L2L ‘(che indica che è un tunnel IPSec da sito a sito), il ruolo è’ responder ‘ (il che significa che il peer ha sollevato il tunnel) e lo stato è MM_Active (il che significa che sta usando la modalità principale (MM) e la fase IKE 1 sta funzionando (ATTIVA)). MM_ACTIVE è ciò che vogliamo vedere in una fase 1 IKE SA. Ciò significa che tutto è pronto per IKE fase 2 a verificarsi. Quindi cosa dovresti fare se non hai lo stato ATTIVO? O nessun SA a tutti?

Ci sono molti altri stati che possono farti capire cosa sta succedendo con ISAKMP SA.

Nota: Questi codici di stato sono solo per la versione ASA più recente, il codice IPSec precedente utilizzato diversi messaggi di stato.
Le prime due lettere indicano se la connessione è stata effettuata con la modalità principale (MM) o la modalità aggressiva (AM). Dal momento che può essere la modalità principale o aggressiva, elencherò semplicemente come ” XX ” di seguito. Certo vedrai solo alcuni di loro con la modalità principale o aggressiva. Le definizioni che elenco in ogni stato sono ciò che ho trovato essere il problema nella maggior parte dei casi.

XX_Active Collegato
XX_KEY_EXCH – errore di Autenticazione, controllare il metodo di autenticazione
XX_INIT_EXCH – errore di Autenticazione, controllare il metodo di autenticazione
XX_NO_STATE – Grado di corrispondenza IKE Fase 1 politiche, verificare su ogni lato
XX_WAIT_MSG2 – in Attesa di risposta dal peer

Inoltre se non si dispone di una SA a tutti, iniziare controllando l’ovvio. Inizia al livello 1 e fatti strada assicurando che entrambe le unità abbiano connettività e che gli indirizzi peer siano corretti.

il 99% delle volte un problema è con l’IKE phase 1 SA. Se stai ottenendo uno stato di ATTIVO sulla fase 1 probabilmente sei in buona forma. Se hai ancora problemi, dai un’occhiata al tuo IKE phase 2 SA. Non ho intenzione di mostrare un esempio di uno poiché è per lo più solo statistiche. Lo stesso concetto si applica però, se non si dispone di un IPSec SA non si dispone di un tunnel VPN.

Debug
Se si riscontrano ancora problemi, come qualsiasi altra cosa sull’ASA, provare a eseguire il debug. I due comandi che stai cercando sarebbero

ASA# debug crypto isakmp
ASA# debug crypto ipsec
ASA # terminal monitor

Assicurati di abilitare terminal monitor se non sei sulla porta della console

La grande correzione
Non posso dirti quante volte ho passato ore a cercare di caricare un tunnel senza assolutamente successo. Alla fine, due comandi hanno sempre risolto i miei problemi. Quando tutto il resto fallisce, cancella tutto il tuo ISAKMP e IPSEC SAs. Questo ovviamente spazzerà via QUALSIASI connessione IPSec alla scatola. Qualcosa su come soffiare via tutte le altre connessioni e partire da zero sembra risolverlo. Per fare questo….

ASA# clear crypto ipsec sa
ASA# clear crypto isakmp sa

Conclusione
Spero che tu abbia visto, attraverso questo articolo, che avere una comprensione di base di come funziona IPSec fa un mondo di differenza. Sapere dove cercare gli errori e come interpretarli è la chiave per la risoluzione dei problemi dei tunnel IPSec L2L.