ESP è il protocollo IP 50, non la porta TCP 50: cosa consentire

I moduli dei firewall chiedono una porta TCP, e il valore ovvio è 50. Quel valore non consente nulla, perché ESP è il protocollo IP numero 50 e i numeri di protocollo non sono porte. I due spazi di nomi condividono piccoli interi e nient’altro, e l’errore resta invisibile finché IKE non termina e il traffico protetto non arriva mai.

Due spazi di nomi che condividono piccoli numeri

Un’intestazione IP porta un campo di protocollo che nomina ciò che segue: 6 per TCP, 17 per UDP, 1 per ICMP, 50 per ESP, 51 per AH. Un’intestazione TCP o UDP porta numeri di porta, che selezionano un processo sull’host di destinazione. Il protocollo 50 e la porta TCP 50 sono valori senza rapporto che una finestra di dialogo può far sembrare intercambiabili.

Per questo una regola di inoltro delle porte non può esprimere ESP nativo. Non esiste una porta di destinazione ESP da inoltrare, e un dispositivo che comprende solo regole di porta non ha alcun vocabolario per quel pacchetto. La regola corretta nomina invece il protocollo IP. Qualsiasi finestra di dialogo sulle porte è lo strumento sbagliato per quel pacchetto.

L’equivoco ha una seconda metà. Quando il pacchetto è cifrato, tutto ciò che contiene è opaco, compresa l’intestazione TCP della connessione originale. Un firewall che ispeziona le porte di quel pacchetto guarda l’intestazione esterna, che nel caso nativo non ha porte da ispezionare.

ESP nativo, poi l’alternativa incapsulata

L’ESP nativo viaggia direttamente come protocollo IP, il che è efficiente e scomodo in egual misura. È efficiente perché non c’è un’intestazione in più, ed è scomodo perché nessun dispositivo che traduce indirizzi e porte può seguirlo. Il NAT traversal esiste per risolverlo, avvolgendo il pacchetto ESP dentro UDP così che il traduttore abbia porte da riscrivere.

Le due forme sono distribuzioni alternative dello stesso canale dati, non livelli di uno solo. Consentire ESP nativo non consente la forma incapsulata, e consentire UDP 4500 non consente il traffico nativo, quindi un insieme di regole deve corrispondere alla distribuzione invece di coprire entrambe per caso.

Anche il rilevamento conta qui. Gli estremi scelgono tra le forme durante la negoziazione, e il passaggio avviene di solito quando viene rilevato un NAT tra loro. Un percorso che cambia dopo aver stabilito il tunnel può quindi spostare il traffico in uno spazio di nomi che le vostre regole non hanno mai coperto.

Leggete quale forma usa davvero la connessione

Chiedete all’estremo invece di indovinare dal firewall. Su Linux la voce di stato riporta se l’associazione usa l’incapsulamento UDP e quali porte sono coinvolte. Una cattura risponde alla stessa domanda dal cavo, ed entrambe sono più rapide che leggere un insieme di regole e sperare.

ip xfrm state | grep -A3 encap
tcpdump -ni any 'ip proto 50 or udp port 4500'

Il primo comando mostra un tipo di incapsulamento quando è in uso il NAT traversal e nulla quando non lo è. Il secondo mostra quale delle due forme attraversa davvero l’interfaccia, e questo chiude le discussioni su una configurazione che sulla carta sembra corretta.

La controprova appartiene allo stesso passaggio. Una regola che riporta zero corrispondenze vi dice che il pacchetto non l’ha mai raggiunta, e quella è una questione di instradamento o di selettore, non di firewall.

Poi confermate il canale di controllo separatamente. IKE ha le proprie porte e i propri registri, e una negoziazione completata senza dati è esattamente la separazione di cui parla questo articolo.

Scrivete la regola nello spazio di nomi giusto

Una regola di protocollo e una regola di porta sono istruzioni diverse, quindi lo strumento deve esprimere quella che intendete. In nftables la corrispondenza di protocollo è esplicita, e l’alternativa incapsulata riceve la propria regola UDP. Tenete le due regole vicine perché la coppia sia visibile in revisione.

nft add rule inet filter input ip protocol esp accept
nft add rule inet filter input udp dport { 500, 4500 } accept

Non allargate nessuna delle due regole per compensare una diagnosi sbagliata. Un consentire tutto per il protocollo ESP su ogni interfaccia, o un permesso UDP da qualsiasi a qualsiasi, corregge un sintomo e rimuove il controllo che stavate cercando di configurare. Il flusso stretto supportato è quasi sempre sufficiente una volta nota la forma.

Infine, tenete i livelli distinti quando il tunnel funziona e l’applicazione no. I pacchetti che arrivano al gateway hanno ancora bisogno di inoltro, di una rotta di ritorno e di una politica che li ammetta, e nulla di questo è espresso da una regola ESP. La porta mancante spiega un guasto specifico, non ogni guasto IPsec. Tenete la correzione della regola e il controllo dell’instradamento come due conclusioni separate.

Annotate la forma osservata, la regola di protocollo aggiunta e il contatore visto dopo. Tre righe, e la persona successiva distingue un errore di spazio di nomi da un errore di instradamento in un minuto invece che in un pomeriggio.