Dépanner la connectivité VPC

Un serveur applicatif en subnet privé n'arrive pas à ouvrir une connexion vers une instance RDS du même VPC. La base tourne, les identifiants n'ont pas changé, et la connexion tombe simplement en timeout. Vous avez quatre suspects et aucune preuve : un security group, une network ACL, une route table, et la possibilité que la base n'écoute pas du tout.

La plupart des ingénieurs commencent à cliquer dans la console dans l'ordre où les onglets se présentent. Ça finit par marcher. Ça brûle aussi les vingt premières minutes de la panne sur des composants qui n'ont jamais été en cause. La compétence enseignée ici n'est pas de mémoriser plus de services. C'est de parcourir le chemin dans l'ordre où un paquet le parcourt, pour que la première anomalie trouvée soit vraiment celle qui a cassé.

Le chemin a un ordre, vous aussi

Un paquet qui quitte une instance EC2 traverse une séquence fixe de portes. Chacune peut le refuser, et chaque refus est identique vu de l'application : un timeout. Suivez donc la séquence, pas votre intuition.

1. Security group source, sortant. Une règle egress autorise-t-elle l'adresse et le port de destination ? Les groupes par défaut autorisent tout le sortant, donc ce n'est un suspect que dans un environnement verrouillé. Quand c'est la cause, c'est parce que quelqu'un a remplacé la règle egress par défaut en oubliant un port.
2. Network ACL du subnet source, sortant. Une règle sortante autorise-t-elle la requête, et une règle entrante autorise-t-elle la réponse sur les ports éphémères ? Les network ACL sont stateless, donc les deux directions sont deux questions distinctes.
3. Route table source. Existe-t-il une route dont le CIDR de destination contient l'adresse visée, et sa cible existe-t-elle et fonctionne-t-elle ? Sans route, le paquet est jeté avant que le moindre filtre soit consulté.
4. L'intermédiaire. NAT gateway, internet gateway, VPC endpoint, connexion de peering ou transit gateway. Chacun a ses modes de panne propres, tous couverts dans les sujets précédents de ce domaine.
5. Network ACL du subnet destination, entrant. La même paire de questions stateless, vue de l'autre côté.
6. Security group destination, entrant. Une règle ingress autorise-t-elle la source, par CIDR ou en référençant le security group de la source ?
7. La politique de ressource. Une endpoint policy, une bucket policy S3 ou une politique côté service peut refuser une requête dont les paquets sont arrivés parfaitement. Celle-ci produit une erreur plutôt qu'un timeout, ce qui est déjà un signal utile.

Parcourez ensuite le chemin de retour. Cela ressemble à une formalité jusqu'à la panne qu'elle attrape : la requête est acceptée, la destination répond, et la réponse est refusée par une règle sortante de network ACL à laquelle personne n'a pensé, parce que l'application n'initie jamais que dans un sens.

Cet ordre paye parce que chaque porte cache celles qui la suivent. Si la route table n'a aucune correspondance, le security group du fond peut être grand ouvert ou fermé, vous n'en saurez rien. Vérifier dans l'ordre du chemin garantit que le premier refus trouvé est celui qui compte, et que tout ce qui vient après n'est que du bruit.

Lisez le symptôme avant la configuration

Trois des pannes ci-dessus produisent des symptômes distinguables, à condition de regarder au bon endroit.

La deuxième ligne mérite sa propre phrase, parce qu'elle épargne des investigations entières. Une erreur connection refused signifie que le réseau a fonctionné. Le SYN a atteint l'hôte, l'hôte n'avait rien qui écoutait sur ce port, et il a répondu honnêtement. Aucun security group ne produit cette erreur, parce qu'un refus de security group produit du silence. Quand une application journalise connection refused, arrêtez de regarder le VPC et allez voir si le processus tourne et écoute sur l'adresse que vous croyez.

Reachability Analyzer lit tout le chemin pour vous

Parcourir sept portes à la main sur deux comptes prend un temps réel. Reachability Analyzer le fait en un appel.

L'essentiel à comprendre est ce qu'il regarde vraiment. Il construit un modèle de votre configuration réseau et raisonne sur ce modèle. Il n'envoie pas de paquets et ne touche pas au data plane. Il peut donc vous dire qu'un security group rejetterait ce trafic, et vous donner le chemin saut par saut qu'emprunterait un paquet autorisé, sans qu'aucun trafic n'existe. C'est pour cela qu'il fonctionne sur une ressource complètement cassée, et avant même que vous déployiez quoi que ce soit de réel.

Vous définissez un path : une source, une destination, et éventuellement un protocole, un port de destination et des composants intermédiaires à inclure ou exclure. Vous lancez ensuite une analysis sur ce path. Les sources et destinations prises en charge sont les instances EC2, les internet gateways, les network interfaces, les transit gateways, les transit gateway attachments, les virtual private gateways, les VPC endpoint services, les VPC endpoints et les connexions de peering, plus une simple adresse IP en destination.

# 1. Définir le path une seule fois
aws ec2 create-network-insights-path \
  --source i-0a1b2c3d4e5f67890 \
  --destination i-09876fedcba543210 \
  --destination-port 3306 \
  --protocol tcp

# 2. Lancer une analyse dessus, aussi souvent que voulu
aws ec2 start-network-insights-analysis \
  --network-insights-path-id nip-0abc123def456789a

# 3. Lire le verdict et les explications
aws ec2 describe-network-insights-analyses \
  --network-insights-analysis-ids nia-0abc123def456789a \
  --query 'NetworkInsightsAnalyses[0].[NetworkPathFound,Explanations]'

Trois faits opérationnels méritent d'être retenus :

• La facturation porte sur chaque analyse lancée, pas sur le path, donc l'objet path est gratuit à conserver et à relancer après chaque changement. C'est ce qui en fait un contrôle de non-régression et pas seulement un outil d'incident.
• Source et destination doivent être dans la même Région, et dans le même VPC ou dans des VPCs reliés par peering ou par un transit gateway. Elles peuvent appartenir à des comptes différents de la même organisation AWS Organizations si vous activez le trusted access.
• Les analyses sont supprimées automatiquement 120 jours après leur création. Si un résultat sert de preuve pour un audit, exportez-le.

Les explanation codes nomment le coupable

Quand un chemin n'est pas joignable, l'analyse renvoie un ou plusieurs explanation codes. Inutile d'apprendre la liste complète, mais reconnaître les familles transforme un mur de résultats en diagnostic d'une ligne.

Deux de ces codes enseignent plus que leur message. MORE_SPECIFIC_ROUTE est la leçon de routage reformulée en diagnostic : votre route est présente, correcte et pourtant inutilisée, parce que quelque chose de plus long a correspondu avant. Et TGW_ATTACH_MISSING_TGW_RTB_ASSOCIATION est la distinction association contre propagation, vue dans la leçon Transit Gateway, qui se manifeste en panne concrète, puisqu'un attachment qui propage ses routes sans être associé n'a aucune route table à consulter.

Là où le modèle s'arrête et où les paquets commencent

Reachability Analyzer vérifie de la configuration, donc il est aveugle à tout ce qui n'en est pas. Connaître ses angles morts est ce qui empêche un résultat vert de vous égarer.

• Il ne tient pas compte de la santé des targets enregistrées. Un load balancer dont toutes les targets échouent aux health checks s'analysera quand même comme joignable.
• Il ne prend en charge que l'IPv4. Si une ressource porte les 2 familles d'adresses, seul le côté IPv4 est analysé. Une panne purement IPv6 apparaît en NO_PATH.
• Il n'a aucune vue sur le DNS. Si votre application résout un nom vers la mauvaise adresse, le chemin vers la bonne adresse reste parfaitement joignable.
• Il s'arrête aux transit gateway Connect attachments, et les chemins passant par un endpoint Gateway Load Balancer excluent le Gateway Load Balancer et ses targets, qui réclament leur propre analyse.
• La prise en charge de Network Firewall est partielle. Il traite les règles stateful et stateless de type 5-tuple, mais pas les listes de domaines, les règles Suricata, les rule options ni les groupes de ressources par tag, et il le signale dans les détails du chemin quand il en rencontre.
• Il ne dit rien de l'application. Un processus qui écoute, un handshake TLS, une base qui refuse les identifiants : tout cela est hors du modèle.

La règle honnête tient donc en une phrase : Reachability Analyzer prouve que le chemin est autorisé, pas que l'appel réussira. Quand il répond non joignable, vous avez votre réponse et vous pouvez vous arrêter. Quand il répond joignable et que l'application échoue toujours, vous avez appris quelque chose d'utile aussi : le problème est au-dessus de la couche réseau, et les logs de la leçon suivante sont votre prochaine étape.

Les pannes qui ne sont pas vraiment des pannes réseau

Quatre causes expliquent une large part des tickets étiquetés "connectivité VPC" qui ne touchent jamais un security group.

Un DNS qui résout vers la mauvaise chose. Une private hosted zone exige enableDnsSupport et enableDnsHostnames sur le VPC pour être utilisable, et un interface endpoint dont le private DNS est désactivé laisse le nom public du service pointer vers une adresse publique qu'un subnet privé ne peut pas atteindre. La connexion échoue au niveau réseau, mais le correctif est un paramètre DNS.

Le path MTU. Une connexion qui s'ouvre proprement puis se fige dès qu'une grosse charge utile démarre n'est presque jamais un problème de permission. Les handshakes sont petits et passent partout. Les tunnels réduisent la taille de paquet utilisable, et si un firewall jette les messages ICMP fragmentation needed, le path MTU discovery ne peut pas dire à l'émetteur d'envoyer plus petit, donc le transfert reste suspendu. Vérifiez le MTU avant les règles chaque fois que le symptôme dépend de la taille.

Le source/destination check. Toute instance qui relaie du trafic pour autrui, une NAT instance ou une appliance, doit l'avoir désactivé. Laissé actif, l'interface jette les paquets relayés et tout le routage a l'air correct.

Les ports éphémères sur une network ACL stateless. Traité en détail dans la leçon sur les security groups, et il ressurgit ici parce que c'est la raison numéro un pour laquelle une network ACL autorise la requête et tue la réponse. Si le trafic est sortant et que les règles entrantes de la network ACL n'autorisent pas le retour sur 1024 à 65535, rien ne marche et chaque règle paraît raisonnable.

Conseils d'examen

• Le parcours ordonné, à chaque fois. Security group source, network ACL source, route table, intermédiaire, network ACL destination, security group destination, politique de ressource, puis le chemin de retour. Les questions de scénario sont construites en cassant exactement l'un de ces éléments.
• "Connection refused" n'est pas un problème réseau. Timeout veut dire jeté, refused veut dire délivré. Une question où le client reçoit un refus immédiat désigne le service, pas le VPC.
• Reachability Analyzer analyse la configuration, pas les paquets. Quand une question demande comment trouver le composant bloquant sans générer de trafic ni rien modifier, c'est la réponse. Quand elle demande ce qui est réellement arrivé au trafic, ce sont les flow logs.
• Reachability Analyzer est IPv4 seulement, même Région, et ignore la santé des targets. Ces 3 contraintes sont ce que l'examen teste le plus probablement à son sujet.
• MORE_SPECIFIC_ROUTE et NO_ROUTE_TO_DESTINATION sont du routage, SUBNET_ACL_RESTRICTION est la network ACL, ENI_SG_RULES_MISMATCH est le security group. Savoir relier un code à un composant suffit.
• Des CIDR qui se chevauchent ne peuvent pas être peerés, parce que la route locale gagne toujours à l'intérieur de votre propre CIDR et ne peut pas être surchargée.
• Appliance de relais plus pertes silencieuses égale source/destination check.
• Blocage uniquement sur les gros transferts égale MTU, pas filtrage.

L'habitude à emporter est plus petite que la liste d'outils : quand une connexion échoue, nommez la première porte du chemin que vous n'avez pas vérifiée, et vérifiez celle-là. Reachability Analyzer est la façon de faire ce parcours en un appel au lieu de sept. Ce qu'il ne peut pas vous dire, c'est ce qui est réellement arrivé au trafic mardi dernier à 03:00, et c'est précisément le rôle des logs de la leçon suivante.