Perché L2TP/IPsec ha bisogno di UDP 1701 oltre a IPsec

I firewall che consentono IKE ed ESP ma non UDP 1701 spezzano le connessioni L2TP in un modo che sembra un problema di credenziali. Il motivo è che L2TP è un secondo protocollo che viaggia dentro il primo. IPsec trasporta e autentica lo scambio, e L2TP gestisce il proprio tunnel su UDP 1701, che lo stack locale deve comunque consegnare. Sapere dove compare ogni intestazione spiega quale dispositivo ha bisogno di quale regola.

Due protocolli, due insiemi di porte

Una connessione L2TP/IPsec usa IKE su UDP 500, l'attraversamento NAT su UDP 4500 dove è presente la traduzione, ed ESP come protocollo IP 50 dove non lo è. L2TP stesso è un protocollo di tunnel su UDP 1701, e funziona dopo che IPsec ha autenticato il peer. Le due metà falliscono in modo diverso, e le righe di registro che ne danno conto provengono da componenti diversi. Un insieme di regole che copre solo la prima metà produce una connessione che negozia e poi muore nella fase del tunnel.

I numeri di porta descrivono estremi di trasporto, ed ESP non è affatto una porta. Per questo un'interfaccia firewall che offre solo regole TCP e UDP non può esprimere una politica IPsec completa. Il protocollo 50 deve essere consentito come protocollo, e una regola che menziona solo UDP non lo incontrerà mai.

L'involucro spiega la porta

Sul filo, una connessione L2TP/IPsec mostra normalmente IKE su 500 ed ESP incapsulato su 4500. L'intestazione UDP 1701 si trova dentro il carico protetto, per questo una cattura sull'interfaccia esterna non la mostra. L'host locale deve comunque consegnare quel datagramma al demone L2TP, e la consegna avviene dopo la decapsulazione. La regola 1701 appartiene quindi al firewall dell'estremità stessa, anche quando nessun dispositivo intermedio vede mai la porta.

L'ordine di elaborazione spiega la maggior parte della confusione. Se lo stack applica la politica IPsec prima del filtro dell'host, il pacchetto L2TP decapsulato viene confrontato come UDP 1701; se l'ordine è invertito, sono le porte esterne quelle che vede l'insieme di regole. Entrambi i comportamenti esistono in pratica, per questo lo stesso insieme di regole sembra funzionare su una piattaforma e fallire su un'altra.

Controlla il percorso in ordine

Cattura prima l'interfaccia esterna e conferma che IKE ed ESP incapsulato si muovano in entrambe le direzioni. Poi controlla i contatori del firewall locale per il traffico decapsulato. L'ordine conta, perché una cattura che non mostra assolutamente nulla significa che il problema è a monte dell'host.

sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701

La cattura conferma la prima metà dello scambio e mostra se il peer risponde. L'elenco delle regole mostra se esiste una regola 1701 e dove si colloca rispetto a qualsiasi politica di scarto. L'elenco dei socket conferma che il demone L2TP è collegato e in ascolto, il che esclude un servizio mai avviato. Leggi tutti e tre prima di cambiare una regola, perché un ascoltatore assente e una porta filtrata producono identiche lamentele da parte dell'utente.

Cosa non può mostrare una scansione delle porte

Una scansione esterna di UDP 1701 contro un server configurato correttamente di solito non segnala nulla, e questo è il risultato atteso. La porta non è esposta a internet; la si raggiunge solo dopo che IPsec ha autenticato il peer. Trattare il risultato chiuso come un guasto porta ad aprire una porta che dovrebbe restare chiusa. La scansione non può vedere dentro il tunnel più di quanto possa vedere il traffico dell'applicazione.

Prova invece con un client reale, e leggi la fase che raggiunge. Se la connessione negozia e poi si blocca, il sospetto è il demone L2TP o il filtro locale; se non negozia mai, sono le porte esterne. Quella singola divisione elimina la maggior parte delle congetture su quale regola aggiungere, e l'impilamento dei protocolli lo rende prevedibile anziché misterioso.