Ho letto che si consiglia di incapsulare pacchetti IPsec in pacchetti UDP (porta 4500) per aggirare il NAT. Qualcuno potrebbe fornire una spiegazione dettagliata delle ragioni alla base di questa soluzione?
Ho letto che si consiglia di incapsulare pacchetti IPsec in pacchetti UDP (porta 4500) per aggirare il NAT. Qualcuno potrebbe fornire una spiegazione dettagliata delle ragioni alla base di questa soluzione?
Le associazioni di sicurezza ESP (SA) sono unidirezionali. Quindi per comunicare bidirezionalmente sono richieste due SA, a ciascuna estremità una SA è per il traffico in entrata e una per il traffico in uscita (e viceversa all'altra estremità).
Queste SA sono identificate dal protocollo (ESP / AH), dall'indirizzo IP di destinazione e da un identificatore a 32 bit chiamato Security Parameters Index (SPI). E questa è tutta l'informazione contenuta in ogni pacchetto ESP (protocollo, indirizzo di destinazione e SPI di destinazione).
Quindi, a differenza delle porte di origine e di destinazione che fanno parte delle intestazioni UDP, solo una SPI è contenuta in un'intestazione ESP. Per un router NAT non è quindi possibile sapere quale host dietro il NAT deve inoltrare i pacchetti ESP in entrata. Se non ci fosse mai traffico in uscita, non lo saprebbe nemmeno se entrambi gli SPI fossero contenuti nell'intestazione ESP in quanto non conosce questi SPI, che vengono comunicati crittografati tramite il protocollo IKE (Internet Key Exchange) quando sono state stabilite le SA .
Quello che i router NAT hanno spesso è una funzionalità chiamata "IPsec passthrough". Il router NAT rileva il traffico IKE e quindi inoltra eventuali pacchetti ESP tra i due host che comunicano tramite IKE. Tuttavia, questo funziona solo per un client VPN dietro il NAT che comunica con un particolare indirizzo IP del server. Con più di un client, il NAT di nuovo non saprebbe a quale client inoltrare un particolare pacchetto ESP in entrata.
Per supportare questo scenario, le intestazioni UDP vengono aggiunte ai pacchetti ESP. Ciò consente al NAT di trattare questi pacchetti ESP-in-UDP come qualsiasi altro pacchetto UDP. Poiché vengono utilizzate le stesse porte già in uso per IKE, il NAT dispone già di mappature delle porte quando i peer iniziano a scambiare il traffico ESP (a meno che il router NAT esegua un'ispezione approfondita non possa distinguere questo traffico dal traffico IKE).
Per separare i pacchetti IKE dai pacchetti ESP incapsulati UDP sul destinatario, il primo ha quattro byte zero aggiunti tra l'header UDP e IKE (chiamato marker non ESP), che è dove lo SPI è memorizzato in pacchetti ESP (che non può essere 0 se è implementato RFC 3948 ). Questo formato di pacchetto modificato è anche il motivo per cui viene utilizzata una porta diversa per questo traffico (4500).
L'incapsulamento UDP funziona fondamentalmente sia per le modalità IPsec (tunnel / trasporto). Tuttavia, ci sono alcuni problemi (descritti in modo più dettagliato nelle RFC 3948 di sicurezza):
Quando si utilizza la modalità tunnel, gli indirizzi IP di due client che si trovano dietro NAT diversi potrebbero essere gli stessi, il che comporterebbe la creazione di duplicati di SA / policy sul gateway. Per evitare che i gateway in genere assegnino gli indirizzi IP virtuali dalle subnet designate ai client mobili (roadwarriors) durante la negoziazione IKE o tramite DHCP.
Con la modalità di trasporto, più client dietro lo stesso NAT sono problematici. Se utilizzano tutti lo stesso protocollo e selettori di porta, i criteri IPsec si sovrappongono (poiché condividono tutti lo stesso IP pubblico) e potrebbe essere difficile per il gateway decidere quale SA utilizzare per inviare il traffico. In alcuni casi, le porte utilizzate per l'incapsulamento UDP possono essere utilizzate per risolvere questo problema (questo è il plug-in del contrassegno di strongSwan cerca di fare). Altrettanto problematica è la situazione in cui non tutti i client dietro il NAT utilizzano IPsec per comunicare con un gateway (vedere la RFC per i dettagli).
AH è intrinsecamente incompatibile con NAT poiché il suo Integrity Check Value (ICV) include l'intestazione IP esterna (escludendo solo alcuni campi). Quindi qualsiasi modifica agli indirizzi IP da parte di un NAT invaliderà l'ICV.
Il problema è la modalità tunnel IPsec, che utilizza il protocollo ESP. ESP non funziona con NAT per due motivi:
La soluzione è incapsulare il traffico ESP in UDP. Il NAT può cambiare gli indirizzi UDP perché il checksum di UDP non è invocato. L'uso di udp / 4500 significa anche che il traffico ESP sarà limitato a una singola porta, consentendo al NAT di aggiungerlo al dizionario di traduzione.