VPC Reachability Analyzer : prouver exactement où meurt une connexion

Quand une connexion entre deux choses dans AWS échoue et que vous avez déjà fixé trois groupes de sécurité et quatre tables de routage, VPC Reachability Analyzer est l’outil qui clôt le débat : vous lui donnez une source, une destination et un port, et il retourne soit « reachable » avec le chemin complet saut par saut, soit « not reachable » avec le composant exact — ce groupe de sécurité, cette table de routage, cette règle NACL — qui tue le trafic. Il analyse la configuration, pas les paquets en direct, donc il fonctionne même quand vous ne pouvez pas générer de trafic de test.

Ce qui se passe

Reachability Analyzer construit un modèle de votre configuration réseau — ENI, groupes de sécurité, NACL, tables de routage, passerelles Internet et NAT, appairages, Transit Gateways, points de terminaison VPC — et calcule si un paquet avec votre quintuple pourrait traverser de la source à la destination. Deux objets sont en jeu : un chemin (source, destination, protocole, port optionnel — une définition réutilisable) et une analyse (une évaluation de ce chemin contre la configuration courante). Vous êtes facturé par analyse exécutée, donc le chemin ne coûte rien à conserver et à relancer après chaque changement.

Parce que c’est de l’analyse de configuration, le verdict vient avec une explication. Un chemin bloqué nomme le composant et la raison avec un code précis — la famille d’explications *_MISMATCH, comme un groupe de sécurité sans règle entrante correspondante, une table de routage sans route vers la destination, ou une NACL qui refuse le port. Un chemin joignable liste chaque saut dans l’ordre, ce qui est utile en soi pour confirmer que le trafic prend le chemin conçu (à travers l’appliance d’inspection, pas à côté).

La moitié tout aussi importante est ce qu’il ne voit pas : tout ce qui vit dans le système d’exploitation. Pare-feu de l’hôte (iptables, nftables, pare-feu Windows), le fait que le processus écoute ou non, l’authentification applicative — tout cela est invisible. « Reachable » signifie que la couche réseau du VPC permet le flux; le service peut quand même être à terre. Il analyse aussi à l’intérieur d’une région (les chemins peuvent traverser des comptes de la même organisation AWS, des Transit Gateways et des appairages), et il couvre les chemins IPv4 — planifiez en conséquence pour le débogage en double pile.

Quoi vérifier en premier

Avant de lancer une analyse, assurez-vous que la question est bien posée :

Choisissez les bons types de source et de destination — identifiants d’instance, ENI ou passerelles. Pour une instance à plusieurs ENI, analysez l’ENI précise qui porte le trafic.
Connaissez le port et le protocole — une analyse pour TCP 443 ne dit rien de TCP 5432.
Même région? Les chemins inter-régions demandent une autre approche (analyser chaque côté vers le milieu).
Entre comptes? Les deux comptes doivent appartenir à la même organisation avec l’accès inter-comptes de l’analyseur activé.
Permissions IAM — l’appelant a besoin de ec2:CreateNetworkInsightsPath, ec2:StartNetworkInsightsAnalysis et des permissions tiros:* (le service sous-jacent) que l’assistant console configure.

Comment vérifier

Console : VPC > Reachability Analyzer > Create and analyze path, choisir la source, la destination, le protocole, le port de destination, puis lancer. Les constats s’affichent en liste ordonnée de sauts avec le composant bloquant en évidence. CLI :

# Définir le chemin une seule fois
aws ec2 create-network-insights-path \
  --source i-0source123 \
  --destination i-0dest456 \
  --protocol tcp \
  --filter-at-source '{"DestinationPortRange":{"FromPort":5432,"ToPort":5432}}'

# Lancer une analyse contre la configuration courante
aws ec2 start-network-insights-analysis \
  --network-insights-path-id nip-0abc123

# Lire le verdict et le composant bloquant
aws ec2 describe-network-insights-analyses \
  --network-insights-path-ids nip-0abc123 \
  --query 'NetworkInsightsAnalyses[0].{Reachable:NetworkPathFound,Explanations:Explanations[].{Code:ExplanationCode,Component:Component.Id}}'

Les codes d’explication et les combinaisons source/destination prises en charge sont catalogués dans la documentation Amazon VPC.

Le runbook

Reproduisez l’échec sous forme de chemin. Source = l’ENI ou l’instance cliente, destination = le serveur, protocole et port exactement comme l’application les utilise. Résistez à l’envie de tester « ping » quand l’application parle TCP 5432 — les résultats ICMP ne se transfèrent pas.
Lancez l’analyse et lisez la première explication. Le constat nomme le composant et la direction. Un écart de groupe de sécurité sur l’ENI de destination signifie que la règle entrante manque; un constat de table de routage signifie que le paquet ne s’est jamais rendu jusque-là.
Corrigez seulement le composant nommé. La précision est justement l’intérêt — n’allez pas « faire le ménage » de trois autres groupes en plein incident. Si le constat vise une NACL, pensez à la direction de retour; les règles sans état sont couvertes dans groupes de sécurité vs NACL.
Relancez la même analyse. Même objet chemin, un clic ou un start-network-insights-analysis. Itérez jusqu’à ce que NetworkPathFound soit vrai — les blocages multiples se révèlent un à la fois.
Confirmez à la couche OS. Joignable dans l’analyseur plus nc -vz host 5432 depuis la source ferme la boucle; si l’analyseur dit joignable et que nc échoue encore, le problème est le pare-feu de l’hôte ou le service lui-même, et vous venez d’économiser des heures d’archéologie VPC.
Conservez le chemin pour la régression. Relancez-le après les refontes de groupes de sécurité ou les changements de routes, comme test de fumée du plan de configuration.

Quand c’est la mauvaise approche

Reachability Analyzer répond à « ce flux pourrait-il fonctionner selon la configuration » — pas à « que se passe-t-il en ce moment ». Pour des coupures intermittentes, des réinitialisations de connexion sous charge ou un « ça marchait hier », il vous faut des preuves de paquets réels : l’analyse des VPC Flow Logs montre les acceptations et les rejets au fil de l’eau. C’est aussi le mauvais outil pour les problèmes DNS (il teste des chemins IP, pas la résolution de noms) et pour tout ce qui vit dans l’instance. Et si vous lancez des analyses en boucle serrée depuis de l’automatisation, rappelez-vous que chaque exécution est facturée — la tarification par analyse convient au débogage, pas à la surveillance.

Erreurs fréquentes

Tester le mauvais quintuple — analyser le port 443 pendant que l’application échoue sur le 8443, puis se fier au résultat vert.
Confondre « joignable » et « fonctionnel » et fermer le billet pendant que le service est à terre au niveau de l’OS.
Analyser instance-à-instance quand le vrai chemin passe par un répartiteur de charge — analysez client-vers-ALB et ALB-vers-cible séparément.
Oublier que l’analyse est un instantané : une configuration changée après l’exécution rend le verdict périmé.

Prévention

Créez des chemins permanents pour vos flux critiques (application vers base de données, ALB vers cibles, VPC vers site via TGW) et relancez-les après chaque changement réseau.
Branchez une analyse dans les pipelines de changement qui touchent groupes de sécurité ou tables de routage — un échec de joignabilité bloque l’application du changement.
Étiquetez les chemins avec le flux qu’ils représentent pour que le prochain ingénieur sache ce que nip-0abc123 prouve.
Jumelez l’analyseur aux flow logs : l’analyseur pour « est-ce que ça devrait marcher », les flow logs pour « est-ce que ça a marché ».

L’habitude payante, c’est de lancer l’analyseur avant la séance de thérapie de groupe où chacun relit les groupes de sécurité à voix haute — deux minutes, un blocage nommé. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.