Perché GRE ed ESP falliscono attraverso un gateway NAT AWS

Il tunnel fallisce, il gruppo di sicurezza consente già tutto il traffico e la conclusione è che AWS blocca la VPN. Non blocca nulla. Un gateway NAT gestito inoltra un insieme documentato di protocolli esterni, e GRE nativo o ESP nativo non ne fanno parte, quindi nessuna regola aggiunta farà trasportare loro dal gateway. La regola di autorizzazione e la capacità di trasporto sono due cose diverse, e solo una delle due è a portata di modifica.

L’insieme delle regole non è l’insieme dei protocolli

Un gruppo di sicurezza decide quale traffico può lasciare l’istanza. Il gateway NAT decide cosa è in grado di tradurre e inoltrare. Quando si applica il secondo limite, una regola permissiva produce esattamente il sintomo che le persone interpretano male come problema del firewall: i pacchetti lasciano l’istanza, lo scambio di controllo può persino completarsi e nulla arriva al peer.

La specifica dei protocolli del gateway NAT di AWS elenca TCP, UDP e ICMP per il servizio gestito. È l’intero insieme supportato. Una regola di autorizzazione per un altro protocollo IP non può estenderlo, perché la regola viene valutata molto prima che si raggiunga il percorso di inoltro del gateway.

La distinzione conta perché i due guasti sembrano identici dal lato client e hanno correzioni completamente diverse.

PPTP mostra perché un test di porta mente

PPTP è l’esempio vecchio più chiaro di una verifica di porta che non dimostra nulla. Apre una connessione di controllo TCP sulla porta 1723 e poi trasporta i dati del tunnel su GRE, che è il protocollo IP 47. Il protocollo 47 non è la porta TCP 47, e i due numeri non hanno nulla a che fare l’uno con l’altro oltre a condividere cifre.

Un operatore che verifica la connettività alla 1723 e vede una stretta di mano completata conclude che il percorso funziona. Poi il canale dati non passa mai nemmeno un pacchetto, perché il gateway non ha alcun supporto GRE da offrire. Questa è un’interpretazione dei requisiti di un vecchio protocollo, non un consiglio di distribuire PPTP, obsoleto da anni.

Lo stesso ragionamento vale per qualsiasi protocollo il cui canale di controllo sia TCP o UDP mentre il suo percorso dati non lo è.

IPsec sopravvive solo come UDP

IPsec è il caso in cui la risposta è condizionale anziché un no netto. AWS documenta il NAT traversal come la disposizione supportata per IPsec attraverso un gateway NAT. Con NAT-T negoziato, ESP viene incapsulato in UDP e il gateway vede UDP ordinario invece del protocollo 50.

Consentire UDP 4500 non fa usare il NAT traversal agli endpoint. Consente i pacchetti solo se hanno già quella forma. Conferma dall’output di negoziazione del client stesso quale incapsulamento è stato scelto e conferma sul lato ricevente che il peer l’ha accettato. Due endpoint configurati per ESP nativo continueranno a inviare ESP nativo, qualunque cosa dica l’insieme delle regole.

Una VPN basata su TCP o UDP rientra nell’insieme di trasporti documentato e può comunque fallire per motivi di routing, filtraggio o autenticazione. Rientrare nell’insieme è necessario, non sufficiente.

Verifica il percorso prima di ampliare la politica

Verifica la rotta reale della sottorete di carico di lavoro e l’identità del suo salto successivo per primo. Un percorso pubblico diretto, un’istanza NAT, un gateway NAT gestito e un percorso privato attraverso un gateway di transito sono quattro progetti diversi, e solo uno di essi è il servizio gestito descritto qui.

Poi registra l’endpoint tentato, la famiglia di indirizzi, il protocollo esterno e la porta dove il protocollo ne ha una. Usa la diagnostica del client e le osservazioni di flusso del proprietario della rete invece di una richiesta del browser riuscita, che dimostra solo che TCP e UDP funzionano. Dopo di che, esamina il gruppo di sicurezza, l’ACL della sottorete, il firewall dell’ospite e la politica del servizio per entrambe le direzioni del flusso.

Non aprire tutto il traffico per compensare un trasporto che il servizio non può portare. La modifica della regola non lo risolverà e sopravvivrà all’incidente.

Quando il trasporto non si adatta

Se il protocollo esterno è fuori dall’insieme supportato, la correzione è architetturale: scegli un trasporto che il percorso può portare, oppure sposta l’uscita su qualcosa che porti quello che ti serve. OpenVPN su UDP, WireGuard su UDP e i tunnel basati su TLS rientrano tutti nell’insieme documentato. Un’istanza NAT gestita dal cliente è l’opzione quando un protocollo specifico deve passare e il costo operativo di gestirla è accettabile.

Ospitare un server VPN in ingresso è un problema separato con una risposta separata. Un gateway NAT fornisce traduzione in uscita e nessun inoltro di porte in ingresso generale, quindi un server dietro di esso necessita del suo ingresso pubblico approvato progettato secondo i propri termini.

Ordine di lavoro: nomina il protocollo esterno, conferma il salto successivo, confrontalo con l’insieme documentato, poi cambia architettura o trasporto. Un numero di porta diverso non può trasformare GRE in TCP, e una regola più permissiva non può trasformare uno scambio di controllo completato in un canale dati funzionante.