IKEv2 usa UDP 500 e 4500: quale trasporta i dati?

Aprire UDP 500 nel firewall permette al tunnel di negoziare, poi la connessione smette di far passare traffico. L’elenco delle porte era incompleto, non sbagliato. IKEv2 parte su un socket e in molte implementazioni reali continua su un altro, mentre il payload può non essere affatto una porta. Leggere le fasi in ordine spiega quale regola manca.

Due porte, due compiti

IKEv2 inizia con uno scambio di chiavi su UDP 500, dove i peer si autenticano e stabiliscono un’associazione di sicurezza per il tunnel. Il percorso dati che segue è un’altra questione: può essere ESP nativo, cioè un numero di protocollo IP e non una porta, oppure traffico incapsulato in UDP sulla 4500. Tenere separati questi due aspetti in una verifica del firewall è la differenza tra un tunnel che negozia e un tunnel che funziona. Un socket porta il controllo e l’altro il payload.

Per questo una regola che consente solo la 500 produce il sintomo più confuso dell’intera famiglia di protocolli: la negoziazione riesce e non segue nulla di utile. Lo stato mostra un peer, il registro mostra una IKE SA stabilita, e l’applicazione va comunque in timeout. Il permesso mancante appartiene a un flusso diverso da quello appena riuscito.

Perché la 4500 esiste

Molti dispositivi NAT non possono inoltrare protocolli diversi da TCP o UDP, e alcuni riscrivono gli indirizzi in modi che rompono il controllo di integrità di ESP. Incapsulare ESP dentro UDP risolve entrambi i problemi, al costo di un’intestazione in più e di una seconda porta da consentire. È proprio questo incapsulamento la ragione per cui la seconda porta esiste.

Una volta rilevato NAT, anche IKE passa alla 4500 così tutto il traffico condivide un solo percorso attraverso il traduttore. Un marcatore di quattro byte che non è ESP distingue i messaggi di controllo dai dati su quel socket. Il passaggio è una decisione del protocollo, non una preferenza dell’amministratore.

Dove cambia la porta di origine

Un traduttore può riscrivere la porta di origine del client, quindi la tupla vista dal server non corrisponde a quella sul client. Guarda entrambi i lati di ogni salto NAT prima di concludere che una regola venga ignorata. La diagnosi solo sul client può produrre una regola che sembra corretta e fallisce comunque.

Le implementazioni compatibili con MOBIKE possono passare alla 4500 anche senza NAT rilevato, e alcune installazioni impongono deliberatamente quel percorso. Vedere 4500 è quindi prova di una decisione, non prova di un router domestico.

Controlla entrambi i flussi a ogni confine

Percorri i tre confini: la rete del client, qualsiasi firewall intermedio e il server. Ognuno richiede i flussi documentati dall’installazione, non quelli di un articolo su un altro caso.

sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or udp port 4500'
sudo iptables -S | grep -E '500|4500|esp'
ip xfrm state

La riga ESP in un elenco del firewall è una corrispondenza di protocollo, quindi una regola di porta non la copre mai. Se l’operatore usa una porta personalizzata, segui la configurazione documentata su entrambe le estremità, perché un client non può creare un listener sul server scegliendo un numero familiare.

Annota dove la negoziazione si è fermata e se è stata installata un’associazione di sicurezza figlia, perché quella coppia separa un percorso bloccato da un errore di autenticazione o di criterio. Poi ripeti il test con la verifica del server attiva, perché la raggiungibilità non è autenticazione. Quest’ultimo passo separa una porta consentita da un peer fidato.