Pourquoi GRE et ESP échouent à travers une passerelle NAT AWS

Le tunnel échoue, le groupe de sécurité autorise déjà tout le trafic, et la conclusion est qu’AWS bloque le VPN. Il ne bloque rien. Une passerelle NAT gérée relaie un ensemble documenté de protocoles externes, et GRE natif ou ESP natif n’en font pas partie, donc aucune règle que vous ajoutez ne fera transporter ces protocoles par la passerelle. La règle d’autorisation et la capacité de transport sont deux choses différentes, et une seule des deux est à votre portée.

L’ensemble des règles n’est pas l’ensemble des protocoles

Un groupe de sécurité décide quel trafic est autorisé à quitter l’instance. La passerelle NAT décide ce qu’elle est capable de traduire et de relayer. Quand la seconde limite s’applique, une règle permissive produit exactement le symptôme que les gens interprètent à tort comme un problème de pare-feu : les paquets quittent l’instance, l’échange de contrôle peut même se terminer, et rien n’arrive au pair.

La spécification des protocoles de la passerelle NAT d’AWS énumère TCP, UDP et ICMP pour le service géré. C’est l’ensemble complet pris en charge. Une règle d’autorisation pour un autre protocole IP ne peut pas l’étendre, car la règle est évaluée bien avant que le chemin de relais de la passerelle ne soit atteint.

La distinction compte parce que les deux échecs semblent identiques côté client et ont des correctifs complètement différents.

PPTP montre pourquoi un test de port ment

PPTP est l’exemple ancien le plus clair d’une vérification de port qui ne prouve rien. Il ouvre une connexion de contrôle TCP sur le port 1723 puis transporte les données du tunnel sur GRE, qui est le protocole IP 47. Le protocole 47 n’est pas le port TCP 47, et les deux nombres n’ont rien à voir entre eux au-delà du partage de chiffres.

Un opérateur qui teste la connectivité vers 1723 et voit une poignée de main terminée conclut que le chemin fonctionne. Le canal de données ne passe ensuite jamais un seul paquet, car la passerelle n’a aucun support GRE à offrir. C’est une interprétation des exigences d’un ancien protocole, pas un conseil de déployer PPTP, qui est obsolète depuis des années.

Le même raisonnement s’applique à tout protocole dont le canal de contrôle est TCP ou UDP alors que son chemin de données ne l’est pas.

IPsec ne survit qu’en UDP

IPsec est le cas où la réponse est conditionnelle plutôt qu’un non catégorique. AWS documente le NAT traversal comme l’arrangement pris en charge pour IPsec à travers une passerelle NAT. Avec NAT-T négocié, ESP est encapsulé dans UDP et la passerelle voit de l’UDP ordinaire plutôt que le protocole 50.

Autoriser UDP 4500 ne fait pas utiliser le NAT traversal aux extrémités. Cela autorise seulement les paquets s’ils ont déjà cette forme. Confirmez à partir de la sortie de négociation du client lui-même quelle encapsulation a été choisie, et confirmez côté réception que le pair l’a acceptée. Deux extrémités configurées pour ESP natif continueront d’envoyer de l’ESP natif, quoi que dise l’ensemble de règles.

Un VPN basé sur TCP ou UDP correspond à l’ensemble de transports documenté et peut malgré tout échouer pour des raisons de routage, de filtrage ou d’authentification. Correspondre à l’ensemble est nécessaire, pas suffisant.

Vérifiez le chemin avant d’élargir la politique

Vérifiez la route réelle du sous-réseau de charge de travail et l’identité de son prochain saut d’abord. Un chemin public direct, une instance NAT, une passerelle NAT gérée et un chemin privé via une passerelle de transit sont quatre conceptions différentes, et une seule d’entre elles est le service géré décrit ici.

Enregistrez ensuite l’extrémité tentée, la famille d’adresses, le protocole externe et le port lorsque le protocole en possède un. Utilisez les diagnostics du client et les observations de flux du propriétaire du réseau plutôt qu’une requête de navigateur réussie, qui ne prouve que le fonctionnement de TCP et d’UDP. Après cela, examinez le groupe de sécurité, l’ACL du sous-réseau, le pare-feu de l’invité et la politique du service pour les deux directions du flux.

N’ouvrez pas tout le trafic pour compenser un transport que le service ne peut pas transporter. Le changement de règle n’y remédiera pas et il survivra à l’incident.

Quand le transport ne convient pas

Si le protocole externe est hors de l’ensemble pris en charge, le correctif est architectural : choisissez un transport que le chemin peut transporter, ou déplacez la sortie vers quelque chose qui transporte celui dont vous avez besoin. OpenVPN sur UDP, WireGuard sur UDP et les tunnels basés sur TLS correspondent tous à l’ensemble documenté. Une instance NAT gérée par le client est l’option lorsqu’un protocole précis doit passer et que le coût opérationnel de son exécution est acceptable.

Héberger un serveur VPN entrant est un problème distinct avec une réponse distincte. Une passerelle NAT fournit une traduction sortante et aucun transfert de ports entrants général, donc un serveur derrière elle a besoin de son entrée publique approuvée conçue selon ses propres termes.

Ordre du travail : nommez le protocole externe, confirmez le prochain saut, comparez-le à l’ensemble documenté, puis changez l’architecture ou le transport. Un autre numéro de port ne peut pas transformer GRE en TCP, et une règle plus permissive ne peut pas transformer un échange de contrôle terminé en canal de données fonctionnel.