Come utilizzare la modalità di trasporto IPsec tra due gateway

Question

Come utilizzare la modalità di trasporto IPsec tra due gateway

#1 da (2 voti)

2

Ho letto molti confronti tra la modalità IPsec Transport e Tunnel, e c'è una chiara comprensione del fatto che quando due gateway si scambiano il traffico indirizzato, dovrebbero utilizzare la modalità Tunnel. In altre parole, la modalità di trasporto dovrebbe essere utilizzata solo tra due host (o due gateway se comunicano tra loro, non il routing del traffico). Quello che cerco di capire è se la modalità di trasporto può essere utilizzata in un'impostazione gateway-to-gateway, anche se non consigliata.

Le mie impostazioni sono le seguenti:

LAN1 < - > GW1 < - > GW2 < - > LAN2

Nel mio caso, voglio proteggere il collegamento tra GW1 e GW2 (contenente traffico IP da / a LAN1 a / da LAN2). È una connessione diretta, nessun routing coinvolto, nessun NAT, niente. Tutti i motivi per cui la modalità Tunnel è raccomandata (e la modalità di trasporto non lo è) non si applicano al mio caso - Sono OK a lasciare le intestazioni IP non crittografate e così via. Voglio risparmiare i byte overhead, quindi mi piacerebbe utilizzare la modalità di trasporto anche se in questo caso non è consigliabile.

Sto usando Ubuntu Linux con il pacchetto Strongswan e IPsec in modalità ESP.

La mia domanda è: è possibile ?

C'è una ragione "fondamentale" che lo rende impossibile, o è semplicemente "non raccomandato / di solito non fatto / non nel manuale Cisco" ma fattibile?

Qualcuno ha un file di configurazione che funziona?

vpn ipsec

posta Danielik 30.08.2018 - 18:31

fonte

1 risposta

Leggi altre domande sui tag vpn ipsec

Le autorità governative possono recuperare i dati dal volume LUKS quando vengono accesi mentre sono attivati? [duplicare] C'è un modo per dimostrare che un programma è stato eseguito sul mio PC Windows?

score 2 · Answer 1

Il problema sta applicando IPsec in modo trasparente.

Gli SPI utilizzati per identificare le Security Associations (SA) non sono univoci a livello mondiale, sono allocati dall'host ricevente, quindi per identificare in modo univoco un SA nel Database delle associazioni di sicurezza (SAD), il tuple SPI, protocol (ESP o AH) e viene utilizzato l'indirizzo IP di destinazione. Questo è anche il modo in cui un host elabora un pacchetto IPsec in entrata, per impostazione predefinita cerca semplicemente una voce SAD con una tupla che corrisponde ai dati del pacchetto ricevuto (è anche possibile controllare se l'indirizzo di destinazione è locale e quindi eseguire la ricerca nel SAD con solo SPI e protocollo, questo è ciò che descrive sezione 5.2 di RFC 4301 ).

Tuttavia, nello scenario descritto la destinazione non è un singolo indirizzo IP noto locale all'host (come nel caso in modalità tunnel e modalità di trasporto da host a host) invece potrebbe richiedere un intero intervallo di valori come potrebbe essere l'indirizzo di uno qualsiasi degli host dietro il gateway di ricezione. Quindi la ricerca predefinita non può essere utilizzata.

È necessaria una ricerca che ignori l'indirizzo di destinazione (che potrebbe potenzialmente causare discrepanze se un host dietro il gateway utilizza IPsec stesso e ha assegnato lo stesso SPI) o qualche tipo di subnet / intervallo per gli indirizzi IP .

Per quanto riguarda il kernel di Linux, nessuna delle due opzioni è disponibile. Il codice che cerca una voce SAD per un pacchetto IPsec in entrata ( __xfrm_state_lookup ) insiste sull'abbinamento dell'indirizzo di destinazione memorizzato nella voce SAD. Quindi, a meno che tu non modifichi il codice sorgente del kernel in un modo che cambi il modo in cui viene trattato l'indirizzo di destinazione, non puoi evitare di utilizzare la modalità tunnel.

Per gli indirizzi IP singoli dietro ciascun gateway esiste la cosiddetta modalità BEET, che supporta il kernel Linux (e strongSwan). In questa modalità i pacchetti vengono inviati in modalità di trasporto (tra gli indirizzi del gateway) ma prima / dopo l'elaborazione, gli indirizzi nell'intestazione IP vengono modificati in base agli indirizzi di mappatura (i selettori di traffico a indirizzo singolo negoziati, vedi draft-nikander-esp-beet-mode per i dettagli).

Nota a margine: esiste un flag per le SA nel kernel Linux chiamato XFRM_STATE_WILDRECV che consente l'abbinamento di alcuni caratteri jolly per IPv6 ma viene utilizzato solo per IPv6 mobile tramite una funzione di ricerca separata (per elaborare i pacchetti con Opzioni di destinazione e Sembra che le intestazioni di estensione di tipo 2 per l'instradamento).