strongSwan ESP-in-UDP: quando non c'è alcun NAT da rilevare

Il rilevamento NAT risponde a una domanda: gli indirizzi o le porte sono cambiati durante il transito? Non risponde se un firewall consente il protocollo IP 50. I gateway di sito senza alcuna traduzione possono comunque trovarsi dietro una politica che scarta l'ESP nativo, e tale requisito va configurato anziché scoperto. Il meccanismo è ESP-in-UDP, ed è una decisione, non un ripiego che compaia da solo.

Il rilevamento è aritmetica sugli indirizzi, non una sonda del firewall

IKEv2 trasporta carichi utili di rilevamento NAT contenenti hash degli indirizzi e delle porte di origine e destinazione. Ogni lato confronta ciò che ha ricevuto con ciò che vede localmente, e una discrepanza gli dice che qualcosa ha tradotto il pacchetto. Nulla in quello scambio verifica se un router intermedio inoltra il protocollo 50.

Vale la pena dire la conseguenza pratica senza giri di parole. Un tunnel che funzionava con ESP nativo non scoprirà da solo un firewall nuovo più restrittivo, e il suo tentativo successivo fallisce nella fase dati mentre IKE continua ad avere successo. Vedrete associazioni di sicurezza IKE stabilite e nessun traffico protetto, il che sembra un guasto di routing finché non catturate sul filo.

L'incapsulamento è quindi una proprietà della connessione che configurate, non un esito che i peer negoziano dal comportamento della rete.

Come encap cambia lo scambio

In un moderno deployment di strongSwan gestito tramite swanctl.conf, l'impostazione encap = yes sulla connessione influenza lo scambio di rilevamento NAT affinché entrambi i peer usino l'incapsulamento UDP per ESP. I pacchetti protetti viaggiano poi dentro UDP, convenzionalmente sulla porta 4500, ed entrambi gli estremi devono concordare questa disposizione.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

Quel frammento appartiene a una vera definizione di connessione e non è un profilo di sito completo. Mantenete gli indirizzi dei peer, l'autenticazione e i selettori di traffico child che già eseguite; l'unica chiave aggiunta cambia come vengono incapsulati i dati protetti, non cosa proteggono.

La guida di strongSwan al NAT-traversal descrive questo comportamento, inclusa l'interazione con il port floating quando si usa MOBIKE.

Usate l'impostazione che appartiene al vostro backend

strongSwan ha due backend di configurazione, e la chiave differisce tra loro. Una swanctl.conf connessione accetta encap, mentre una ipsec.conf connessione legacy accetta forceencaps. Mettere la parola chiave di un backend nell'altro produce una configurazione che si carica senza lamentarsi e non cambia nulla, il che è peggio di un errore.

Controllate quale demone è realmente in esecuzione prima di modificare qualcosa. Su molte distribuzioni entrambi i file esistono perché uno è un residuo di una migrazione precedente, e quello attivo è quello che avvia l'unità di servizio. Leggete quell'unità invece di indovinare dai timestamp dei file. Un controllo di cinque secondi qui evita ore di test di un'impostazione che nulla ha caricato.

Applicate la modifica tramite il proprietario della connessione e ristabilite l'associazione durante una finestra controllata. Un child già installato mantiene l'incapsulamento attuale finché non viene sostituito, quindi la sola modifica del file non prova che la nuova disposizione sia in uso.

Verificate i dati incapsulati, non solo la porta

Catturate sul gateway mentre scorre traffico protetto, poi confrontate con la vista di strongSwan stesso:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

L'ESP nativo appare come protocollo IP 50 e non somiglia affatto a UDP. L'ESP incapsulato appare come datagrammi UDP su 4500 il cui payload non è IKE. Il traffico IKE sulla stessa porta non è prova di incapsulamento, perché MOBIKE può spostare IKE lì mentre il percorso dati resta nativo, quindi leggete il payload, non il numero di porta.

Tenete presente anche l'MTU del percorso. L'involucro aggiunge overhead, e un percorso che trasportava ESP nativo può richiedere aggiustamenti quando i pacchetti crescono. La gestione ICMP necessaria dovrebbe già far parte del progetto; l'incapsulamento non elimina quella dipendenza.

Accettate la modifica quando il nuovo traffico applicativo dentro il tunnel è visibile nella cattura come ESP incapsulato a entrambe le estremità, e quando il servizio interno e la sua rotta di ritorno funzionano ancora. Qualsiasi cosa in meno è una configurazione che sembra corretta in un file.