Aller au contenu

AWS Mis à jour le 2026-07-04

Appairage VPC qui ne fonctionne pas : la liste de vérification routes, groupes de sécurité et DNS

Un appairage VPC actif qui ne passe aucun trafic a presque toujours des routes manquantes d'un côté, des groupes de sécurité qui bloquent le CIDR du pair, ou la résolution DNS restée désactivée. Suivez cette liste dans l'ordre.

Un appairage VPC affichant Active prouve seulement que deux VPC ont accepté de s’appairer — il ne déplace aucun paquet par lui-même. Quand des instances de part et d’autre n’arrivent pas à se parler, la cause est presque toujours l’une de ces quatre choses, dans cet ordre de probabilité : des routes vers le CIDR du pair manquent dans les tables de routage des sous-réseaux d’un côté ou des deux, les groupes de sécurité n’autorisent pas les adresses du pair, la résolution DNS sur l’appairage n’a jamais été activée et les clients se connectent à des IP publiques, ou le trafic n’allait jamais fonctionner parce que l’appairage n’est pas transitif. Suivez la liste dans cet ordre et vous trouverez.

Ce qui se passe

L’appairage est un arrangement de routage, pas un tunnel qui capture le trafic automatiquement. Pour qu’un paquet traverse, la table de routage du sous-réseau source doit avoir une route pour le CIDR du VPC pair ciblant la connexion d’appairage (pcx-...), et la table du sous-réseau de destination doit avoir la route miroir — les réponses sont routées indépendamment, donc un montage unilatéral produit des délais silencieux, pas des erreurs. Ensuite, le groupe de sécurité de la destination doit autoriser la source. Sur un appairage intra-région, vous pouvez référencer directement l’identifiant du groupe de sécurité du pair; entre régions, vous devez autoriser le CIDR du pair, et cette asymétrie piège les équipes qui ont modelé leurs règles sur des références de SG.

Le DNS est la troisième couche, la plus sournoise. Par défaut, si une instance du VPC A résout le nom DNS public d’une instance du VPC B, elle obtient l’IP publique — et la connexion sort par le chemin Internet ou meurt sur un groupe de sécurité qui n’autorise que le CIDR du pair. Chaque côté de l’appairage a une option de résolution DNS qui fait résoudre les noms publics vers les IP privées pour le pair; elle est livrée désactivée et doit être activée des deux côtés pour que les deux directions se comportent. Notez que cela vise les noms DNS publics EC2; les zones hébergées privées sont un sujet distinct — elles exigent une association explicite au VPC, appairage ou pas.

Enfin, les limites structurelles : l’appairage ne transporte pas de trafic transitif (A-B et B-C ne donnent pas A-C), ne fonctionne pas du tout avec des CIDR qui se chevauchent, et n’offre aucun moyen de référencer les routes d’un troisième VPC. Si votre problème est l’un de ceux-là, aucune liste de vérification ne le règle — la conception, oui; voyez appairage VPC vs PrivateLink pour savoir quand chacun convient.

Quoi vérifier en premier

  • L’état de l’appairage est active — pas pending-acceptance (l’accepteur n’a jamais cliqué) ni failed (habituellement des CIDR qui se chevauchent).
  • Les routes des deux côtés, dans les tables des sous-réseaux précis impliqués, pas juste quelque part dans le VPC.
  • Le groupe de sécurité de la destination autorise la source — par CIDR entre régions, la référence de SG n’étant permise qu’intra-région.
  • Les NACL si les sous-réseaux en utilisent des non par défaut — les deux directions, y compris les ports éphémères de retour.
  • À quelle IP le client se connecte réellement — l’IP privée du pair ou une publique venue du DNS.

Comment vérifier

# État de l'appairage et les deux CIDR
aws ec2 describe-vpc-peering-connections \
  --query 'VpcPeeringConnections[].{Id:VpcPeeringConnectionId,Status:Status.Code,ReqCidr:RequesterVpcInfo.CidrBlock,AccCidr:AccepterVpcInfo.CidrBlock}'

# Routes vers l'appairage dans la table du sous-réseau source
aws ec2 describe-route-tables \
  --filters "Name=association.subnet-id,Values=subnet-0abc123" \
  --query 'RouteTables[].Routes[?VpcPeeringConnectionId!=`null`]'

# Options de résolution DNS de l'appairage
aws ec2 describe-vpc-peering-connections \
  --vpc-peering-connection-ids pcx-0abc123 \
  --query 'VpcPeeringConnections[].{Req:RequesterVpcInfo.PeeringOptions,Acc:AccepterVpcInfo.PeeringOptions}'

Depuis l’instance source, séparez le routage du filtrage :

# Le nom résout-il vers l'IP privée du pair?
dig ec2-3-98-x-x.ca-central-1.compute.amazonaws.com +short
# Le port répond-il sur l'IP privée?
nc -vz -w 5 10.1.20.15 5432

Si nc expire malgré des routes correctes, soupçonnez les groupes de sécurité; s’il est refusé, le chemin réseau fonctionne et c’est le service qui cloche. Reachability Analyzer (VPC > Reachability Analyzer) nommera le composant bloquant à travers un appairage en une seule analyse. La référence du comportement d’appairage est dans la documentation Amazon VPC.

Le correctif

  1. Ajoutez les routes, des deux côtés, dans les bonnes tables. Dans les tables des sous-réseaux du VPC A : CIDR du pair -> pcx-.... Miroir dans le VPC B. Si les tables privées sont par AZ, mettez à jour chacune qui héberge un sous-réseau impliqué.
  2. Ouvrez le groupe de sécurité pour le pair. Entre régions : ajoutez le CIDR du pair (ou des sous-réseaux précis) sur le port du service. Intra-région : une référence de SG est plus propre et survit aux changements d’adresses. Gardez la règle serrée — le sous-réseau du pair, pas 10.0.0.0/8.
  3. Activez la résolution DNS sur l’appairage, des deux côtés. aws ec2 modify-vpc-peering-connection-options --vpc-peering-connection-id pcx-0abc123 --requester-peering-connection-options AllowDnsResolutionFromRemoteVpc=true et le --accepter-peering-connection-options correspondant depuis le compte accepteur. Les deux VPC doivent aussi avoir enableDnsSupport et enableDnsHostnames activés.
  4. Associez les zones hébergées privées au VPC pair si des noms internes doivent résoudre à travers — l’appairage seul ne partage jamais les zones privées.
  5. Corrigez les NACL en dernier. Si des NACL personnalisées existent, autorisez le CIDR du pair en entrée sur le port du service et en sortie sur les ports éphémères (1024-65535) — sans état veut dire les deux directions, des deux côtés.
  6. Si le besoin est transitif ou en chevauchement, cessez de rapiécer : des CIDR qui se chevauchent exigent un réadressage ou des acrobaties NAT qui vieillissent mal, et les topologies en étoile appartiennent à un Transit Gateway.

Quand c’est la mauvaise approche

Si vous n’avez besoin d’exposer qu’un seul service — une base de données, une API interne — à un autre VPC ou à une autre organisation, une joignabilité réseau complète dépasse le besoin, et PrivateLink est la forme la plus sûre : unidirectionnel, service seulement, aucun couplage de tables de routage. Et une fois que vous approchez la dizaine d’appairages avec des routes miroirs entretenues à la main, le risque opérationnel est le maillage lui-même, pas une connexion en particulier.

Erreurs fréquentes

  • Crier victoire quand l’appairage affiche active sans jamais avoir ajouté de routes.
  • Ajouter les routes à la table principale du VPC pendant que les sous-réseaux de la charge utilisent leurs propres tables.
  • Utiliser une référence de groupe de sécurité entre régions, où elle n’est pas prise en charge, et interpréter le silence comme un bogue de routage.
  • Tester en interrogeant un nom DNS public qui résout encore vers l’IP publique parce que la résolution DNS de l’appairage est restée désactivée.

Prévention

  • Créez les appairages via des modules IaC qui émettent ensemble les routes des deux côtés, les règles de SG et les options DNS — jamais un appairage fait à la console avec des routes ajoutées à la main.
  • Standardisez l’allocation de CIDR sans chevauchement entre les comptes avant le premier appairage, pas après le troisième.
  • Lancez Reachability Analyzer comme test d’acceptation à chaque création ou modification d’appairage.
  • Documentez le but et l’équipe responsable de chaque appairage; les appairages orphelins sont ceux que personne n’ose supprimer.
  • Alertez sur les routes en trou noir — un appairage supprimé laisse ses routes derrière, avalant le trafic en silence.

Un appairage active sans routes est une poignée de main, pas un réseau. Routes dans les deux sens, groupes de sécurité pour le pair, résolution DNS activée — dans cet ordre, et la plupart des billets « l’appairage est cassé » se ferment à l’étape un. 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.