Quali porte VPN aprire su un firewall: protocollo per protocollo

Due regole separate decidono se un tunnel VPN sopravvive a un firewall: la porta che il client compone e il protocollo che trasporta il carico. Aprite solo la prima e il tunnel si autentica, poi non sposta più dati. Il minimo è una porta TCP più GRE per PPTP, due porte UDP più ESP per L2TP/IPsec e IKEv2, e una sola porta per SSTP, OpenVPN e WireGuard. Direzione, tracciamento dello stato e NAT decidono il resto.

Partite dalla porta che il client compone

Ogni famiglia ha un punto d'ingresso che il client contatta per primo, ed è quel punto d'ingresso che la vostra regola di autorizzazione deve nominare. I client PPTP si connettono a TCP 1723. L2TP/IPsec avvia IKE su UDP 500 e passa a UDP 4500 quando è in uso la traversata NAT, con la cornice L2TP stessa su UDP 1701 dentro il tunnel. SSTP incapsula la sessione in TLS su TCP 443, IKEv2 negozia su UDP 500 e 4500, OpenVPN usa UDP 1194 per impostazione predefinita ma spesso viene spostato su TCP 443, e WireGuard ascolta su UDP 51820.

Trattate quei numeri come valori predefiniti e non come proprietà fisse. Un'interfaccia WireGuard usa qualunque porta di ascolto dichiari la sua configurazione, e un server OpenVPN può stare su qualsiasi porta scelga l'amministratore. Leggete la configurazione del server prima di scrivere la regola, perché un firewall aperto per 1194 non fa nulla per un server spostato su 443.

La terza colonna è dove la maggior parte dei ticket di modifica va storta. La regola esiste, ma punta alla destinazione sbagliata, alla direzione sbagliata o al trasporto sbagliato.

GRE ed ESP sono numeri di protocollo, non porte

GRE ed ESP non hanno alcuna porta, quindi un modulo firewall che accetta solo numeri di porta non può esprimerli. GRE è il protocollo IP 47 ed ESP è il protocollo IP 50, entrambi confrontati tramite il campo protocollo dell'intestazione IP. Una regola scritta come porta TCP 47 non corrisponde a nulla, ed è così che una politica PPTP sembra corretta eppure scarta ogni pacchetto dopo la stretta di mano.

I router domestici nascondono questo dietro una casella di passaggio che installa la regola di protocollo e, per GRE, l'helper NAT necessario a mappare il flusso. Su un firewall vero aggiungete voi il protocollo: consentite il protocollo IP 47 verso il server PPTP, consentite il protocollo IP 50 verso il gateway IPsec. Dove la piattaforma non offre un campo protocollo, l'incapsulamento è la via d'uscita, per questo IKEv2 può ripiegare su UDP 4500 e per questo OpenVPN e WireGuard non incontrano mai il problema.

Controllate a cosa corrisponde davvero la regola prima di dare la colpa al client. Un contatore di pacchetti che resta a zero sul gateway dice che la regola non è mai scattata, e nessuna reinstallazione lato client lo cambia.

Direzione, stato e NAT cambiano la risposta

Un client che compone verso l'esterno e un gateway che ascolta verso l'interno sono requisiti diversi, e lo stesso elenco di porte può essere giusto in una direzione e sbagliato nell'altra. Un firewall con stato segue il flusso UDP su 500 e 4500 e lascia tornare le risposte senza una seconda regola. ESP e GRE non portano porte, quindi un dispositivo NAT non ha nulla su cui agganciarsi e ha bisogno di un helper o di un incapsulamento per seguire la sessione.

La traversata NAT è la parte che si dimentica. IKEv2 parte su UDP 500, rileva un dispositivo NAT e prosegue su UDP 4500, quindi una politica che consente solo 500 dà un tunnel che si stabilisce e poi tace. L2TP/IPsec fa la stessa mossa. Se la vostra cattura mostra il primo scambio ma non traffico continuo, cercate una regola che si ferma a 500.

Annotate la direzione con ogni regola. «Consenti UDP 4500» non significa nulla finché non dite da dove a dove, e una regola giusta per un client in roaming è di solito sbagliata per un peer sito a sito.

Verificate ogni percorso con una cattura

Eseguite la cattura sul gateway, non sul client: un client registra solo ciò che è arrivato. Questi filtri coprono le famiglie sopra e mostrano quale fase manca:

sudo tcpdump -ni any tcp port 1723
sudo tcpdump -ni any udp port 500 or udp port 4500
sudo tcpdump -ni any proto gre
sudo tcpdump -ni any proto 50

Leggete l'output come una sequenza. Quando la negoziazione compare ma il protocollo del carico no, lo scarto avviene da qualche parte tra client e gateway. Quando compaiono entrambi e la pagina fallisce ancora, il firewall non è più il sospetto; guardate routing, DNS o il pool di indirizzi assegnato al client.

Su una macchina senza tcpdump le stesse prove arrivano dai contatori di interfaccia e di regola. Byte che entrano ma non escono sull'interfaccia del tunnel indicano il percorso di ritorno e non la regola di autorizzazione iniziale.

Lasciate un insieme di regole che potete difendere

SSTP su TCP 443 è indistinguibile da un normale HTTPS per qualsiasi filtro basato sulle porte, ed è proprio il punto quando una rete consente solo traffico web. È anche il motivo per cui la regola sul 443 deve nominare il gateway come destinazione invece di tutto internet. Cancellate le regole temporanee da qualsiasi-a-qualsiasi non appena il tunnel funziona. Annotate quale regola ha corrisposto, il numero di protocollo dove c'è e la direzione, così la persona successiva parte dalle prove.

I gateway cloud da punto a sito rendono visibile la scelta: il profilo scaricato usa SSTP su 443 oppure IKEv2 su 500 e 4500, e dovreste aprire solo quello che il profilo sceglie davvero. PPTP non vale l'eccezione GRE su una rete moderna, dato che gli operatori mobili spesso scartano il protocollo 47 indipendentemente dal firewall. Prima di chiudere il ticket, confermate che la regola corrisponda alla porta nella configurazione del server, che il campo protocollo sia impostato dove la famiglia lo richiede e che la destinazione sia il gateway e non un indirizzo qualsiasi.