Aller au contenu

AWS Mis à jour le 2026-07-04

Tables de routage VPC déboguées : pourquoi le trafic ne va pas où vous pensez

Quand le trafic VPC prend le mauvais chemin, la cause est presque toujours l'association de table, la correspondance au préfixe le plus long ou une route en trou noir. Voici comment déboguer les tables de routage AWS méthodiquement.

Quand le trafic d’un VPC aboutit à un endroit inattendu — ou nulle part —, l’explication est presque toujours l’une de ces trois choses : le sous-réseau n’est pas associé à la table de routage que vous êtes en train de fixer, une route plus spécifique gagne sur celle que vous avez ajoutée, ou une route est passée en trou noir parce que sa cible a été supprimée. Le routage AWS ne journalise pas ses décisions, alors on le débogue en reconstruisant la décision : trouver la table que le sous-réseau utilise réellement, puis parcourir ses routes selon la correspondance au préfixe le plus long.

Ce qui se passe

Chaque paquet qui quitte une ENI est routé par exactement une table : celle associée au sous-réseau de l’ENI, ou la table principale du VPC s’il n’y a pas d’association explicite. Dans cette table, AWS choisit la route correspondante la plus spécifique — le préfixe le plus long gagne, toujours. Un /32 bat un /24 qui bat 0.0.0.0/0, peu importe l’ordre de création des routes ou leur apparence dans la console. À préfixe égal, les routes statiques que vous avez saisies battent les routes propagées apprises d’une passerelle privée virtuelle.

Deux comportements propres à AWS piègent souvent. D’abord, la route locale du CIDR du VPC existe dans chaque table et garde le trafic intra-VPC à l’intérieur; on ne peut pas la supprimer (on peut seulement en surcharger des portions avec des routes plus spécifiques vers des appliances intermédiaires, un patron délibéré et rare). Ensuite, les routes ne disparaissent pas quand leur cible disparaît : supprimez une passerelle NAT, un appairage ou un attachement de Transit Gateway, et la route reste, marquée blackhole, laissant tomber silencieusement tout ce qu’elle attrape.

Le trafic de retour compte aussi. La table du sous-réseau de destination décide du chemin de la réponse — le routage asymétrique, où la réponse emprunte un autre chemin que la requête, est le résultat classique de tables mises à jour à moitié, et se manifeste par des connexions qui figent plutôt que d’échouer proprement.

Quoi vérifier en premier

  • Quelle table est réellement associée au sous-réseau source? Pas celle qui porte son nom — celle affichée dans l’onglet Route table du sous-réseau.
  • Des routes en trou noir? Elles sont marquées dans la console et dans la sortie CLI; chacune est une cible supprimée vers laquelle on route encore.
  • Une route plus spécifique détourne-t-elle le trafic? Cherchez tout préfixe qui contient votre destination et qui est plus long que la route censée s’appliquer.
  • Le chemin de retour existe-t-il? Vérifiez la table du sous-réseau de destination pour une route vers le CIDR source.
  • Regardez-vous la table de la bonne AZ? Les tables privées sont généralement par AZ (une passerelle NAT chacune); un correctif appliqué à une AZ ne fait rien pour les autres.

Comment vérifier

Console : VPC > Route tables, filtrer par VPC, puis lire côte à côte les onglets Routes et Subnet associations. CLI :

# La table qui sert réellement le sous-réseau
aws ec2 describe-route-tables \
  --filters "Name=association.subnet-id,Values=subnet-0abc123" \
  --query 'RouteTables[].{Id:RouteTableId,Routes:Routes}'

# Toutes les routes en trou noir du VPC
aws ec2 describe-route-tables \
  --filters "Name=vpc-id,Values=vpc-0abc123" \
  --query 'RouteTables[].Routes[?State==`blackhole`]'

# Sous-réseaux SANS association explicite (héritent de la principale)
aws ec2 describe-route-tables \
  --filters "Name=vpc-id,Values=vpc-0abc123" \
  --query 'RouteTables[].Associations[?Main==`true`]'

Pour voir si les paquets partent seulement, activez les VPC Flow Logs sur l’ENI source et cherchez des enregistrements ACCEPT sans trafic de réponse — les patrons de requêtes de l’analyse des VPC Flow Logs s’appliquent directement. Pour une réponse côté plan de configuration, lancez Reachability Analyzer entre la source et la destination (VPC > Reachability Analyzer); il nomme la table et la route exactes qui bloquent le chemin. Les règles d’évaluation des routes sont documentées dans la documentation Amazon VPC.

Le correctif

  1. Corrigez l’association, pas les routes. Si le sous-réseau hérite de la table principale ou pointe vers la table du mauvais palier, changez l’association (Route tables > Subnet associations > Edit). C’est la cause racine la plus fréquente et celle qu’on vérifie en dernier.
  2. Remplacez les routes en trou noir par des cibles vivantes. Recréez la route vers l’identifiant actuel de la passerelle NAT, de l’appairage ou de l’attachement TGW. L’ancien identifiant dans la route ne reviendra jamais à la vie.
  3. Traquez le préfixe plus long. Si un /24 vers un appairage contient l’hôte que vous essayez de joindre par VPN, la route d’appairage gagne. Rétrécissez-la, retirez-la, ou acceptez que la conception envoie ce trafic sur l’autre chemin.
  4. Réparez le chemin de retour. Ajoutez la route vers le CIDR source dans la table du sous-réseau de destination. Pour l’appairage et le TGW, les deux côtés doivent être mis à jour — des routes unilatérales produisent des délais d’attente, pas des erreurs.
  5. Appliquez le changement à la table de chaque AZ. Si vous avez une table privée par AZ, scriptez le changement sur toutes plutôt que de modifier celle que vous aviez ouverte.
  6. Retestez avec une vraie connexion, pas seulement la console : nc -vz -w 5 10.1.2.3 443 depuis l’instance source, en surveillant les flow logs pour la réponse.

Quand c’est la mauvaise approche

Si la table de routage est correcte et que le trafic meurt quand même, cessez de modifier des routes. Les groupes de sécurité et les NACL interviennent après la décision de routage — une route correcte avec un port bloqué ressemble exactement à une route manquante du point de vue de l’application; la distinction est expliquée dans groupes de sécurité vs NACL. Et si vous vous retrouvez à gérer des dizaines de tables pour coudre plusieurs VPC ensemble par appairage, le correctif n’est pas une meilleure hygiène de routage — c’est de migrer la topologie vers un Transit Gateway en étoile.

Erreurs fréquentes

  • Déboguer la table dont le sous-réseau porte le nom plutôt que celle à laquelle il est associé.
  • Oublier que les préfixes larges attrapent tout : 0.0.0.0/0 vers la NAT transportera volontiers le trafic destiné au VPN si la route VPN manque.
  • Modifier la table principale pour corriger un sous-réseau, changeant ainsi le comportement de tous les sous-réseaux non associés du VPC.
  • Croire que la propagation de routes depuis un VPN est active — elle est par table et désactivée par défaut.

Prévention

  • Associez explicitement chaque sous-réseau; gardez la table principale comme fil de détente, avec la seule route locale.
  • Alertez sur les routes en trou noir avec une règle AWS Config personnalisée ou un audit CLI planifié — elles n’apparaissent que lorsqu’on a supprimé quelque chose sous la production.
  • Gérez les tables via Terraform ou CloudFormation pour que la dérive apparaisse dans un diff de plan plutôt que dans une panne.
  • Nommez les tables par palier et AZ (prod-private-rtb-ca-central-1a) pour que la vérification d’association prenne quelques secondes.
  • Lancez Reachability Analyzer comme vérification post-changement après tout travail d’appairage, de TGW ou de VPN.

Les bogues de routage semblent mystérieux parce que le plan de données est silencieux, mais le processus de décision est déterministe : une table par sous-réseau, le préfixe le plus long gagne, les trous noirs avalent. Parcourez-le dans cet ordre et la réponse tombe d’elle-même. 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.