AWS VPC: Comportement étrange lors de l'utilisation NAT et la passerelle Internet avec Load Balancer et Subnets privées

Question

Envisagez la configuration suivante basée sur this document:

• Un AWS VPC avec quatre sous-réseaux. Un public et trois privés (un pour chaque zone de disponibilité)
• Le VPC a une passerelle Internet qui lui est attachée.
• Le sous-réseau public (10.0.1.0/24) dispose d'un Elastic Load Balancer (V2), d'une passerelle NAT et d'un serveur bastion pour SSH dans l'environnement. La table de routage pour ce sous-réseau est défini comme: 10.0.0.0/16 -> local 0.0.0.0/0 -> igw-67e14203 (Internet Gateway)
• Les trois sous-réseaux privés (dans chaque zone de disponibilité) ont la table de routage suivant joint: 10.0.0.0/16 -> local 0.0.0.0/0 -> igw-67e14203

Avec la configuration ci-dessus, les travaux d'équilibrage de charge parfaitement et je peux atteindre les URL du serveur web et les applications de l'internet public. Cependant, avec cette configuration, les serveurs du sous-réseau privé (10.0.2.0/24,10.0.3.0/24,10.0.4.0/24) ne peuvent pas accéder à quoi que ce soit à l'extérieur du réseau local - pas même les dépôts AWS yum. Quand je change la table de routage pour les sous-réseaux privés: 10.0.0.0/16 -> local 0.0.0.0/0 -> nat-0a71345c417d7758a

• Si je regarde les contrôles de santé sous les groupes cibles, il montre tous les cas dans les trois sous-réseaux privés en bonne santé.
• À moins qu'il me manque quelque chose, comme dans le document referenced above, l'équilibreur de charge peut, en fait, être connecté au (x) sous-réseau (s) privé (s).

La configuration ELB est la suivante:

"AppServerLoadBalancer": { 
     "Type": "AWS::ElasticLoadBalancingV2::LoadBalancer", 
     "Properties": { 
     "Scheme": "internet-facing", 
     "Tags": [ 
      { 
      "Key": "environment", 
      "Value": { 
       "Ref": "Environment" 
      } 
      } 
     ], 
     "SecurityGroups": [ 
      { 
      "Ref": "LoadBalancerSecurityGroup" 
      } 
     ], 
     "Subnets": [ 
      { 
      "Ref": "AppServerSubnetAZ0" 
      }, 
      { 
      "Ref": "AppServerSubnetAZ1" 
      }, 
      { 
      "Ref": "AppServerSubnetAZ2" 
      } 
     ] 
     } 
    } 

Les sous-réseaux AppServerSubnetAZ0, AppServerSubnetAZ1 et AppServerSubnetAZ2 sont des sous-réseaux privés avec une route qui pointe vers la passerelle NAT comme décrit précédemment.

Les instances du sous-réseau privé peuvent accéder à Internet, mais le LoadBalancer cesse de fonctionner. Je commence à obtenir des délais d'attente sur l'équilibreur de charge.

Les ACL réseau sont définies correctement et la modification uniquement dans les deux scénarios ci-dessus est le changement dans la table de routage.

Vous n'arrivez pas à comprendre ce qui ne va pas? J'aurais supposé que la passerelle NAT aurait pris soin de routage du trafic de l'équilibreur de charge ainsi que dans l'article/lien ci-dessus?

Nous vous remercions de votre aide!

Answer 1

Je ne sais pas comment il est possible de faire à la fois une passerelle NAT et ELB à travailler pour les instances EC2 dans le sous-réseau privé.

Un travail autour Je vous suggère de garder est votre table de routage

10.0.0.0/16 -> local 
0.0.0.0/0 -> igw-67e14203 (Internet Gateway) 

Et atteindre le NAT en utilisant une instance EC2 au lieu de NAT Gateway.

Answer 2

Vous interprétez incorrectement le document référencé.

L'équilibreur de charge doit être sur un sous-réseau public et les instances sur un sous-réseau privé.

Pourquoi cela fonctionne-t-il lorsque la route sur le sous-réseau privé pointe vers la passerelle Internet? C'est une question piège. Si la route defaut pointe vers la passerelle Internet, ce n'est plus un sous-réseau privé. C'est un sous-réseau public.

Ne pensez pas en termes de réseaux conventionnels, où il est logique que l'équilibreur et les instances qui se trouvent derrière se trouvent souvent sur un sous-réseau commun. VPC ne fonctionne pas de cette façon. Il n'y a aucune pénalité de performance pour le trafic à travers les limites de sous-réseau dans une zone de disponibilité, ni un avantage de performance pour le trafic au sein d'un seul sous-réseau.