Pourquoi avons-nous besoin de sous-réseau privé dans VPC?

mise à Jour: à la fin de décembre, 2015, AWS , a annoncé une nouvelle fonctionnalité, un Géré Passerelle NAT pour VPC . Ce service optionnel fournit un mécanisme alternatif pour les instances VPC dans un sous-réseau privé pour accéder à Internet, où auparavant, la solution commune était une instance EC2 sur un sous-réseau public au sein du VPC, fonctionnant comme une "instance NAT", fournissant la traduction d'adresse réseau (techniquement, port traduction d'adresse) pour les instances dans d'autres sous-réseaux privés, permettant à ces machines d'utiliser l'adresse IP publique de L'instance NAT pour leur accès Internet sortant.

le nouveau service de NAT géré ne change pas fondamentalement l'applicabilité des informations suivantes, mais cette option n'est pas abordée dans le contenu qui suit. Une instance NAT peut encore être utilisée comme décrit, ou le service de passerelle NAT gérée peut être fourni, à la place. Un une version élargie de cette réponse intégrant plus d'information sur NAT Gateway et comment elle se compare à une instance NAT sera disponible prochainement, car ces deux documents sont pertinents pour le paradigme du sous-réseau privé/public dans VPC.

notez que la passerelle Internet et passerelle NAT sont deux caractéristiques différentes. Toutes les configurations VPC avec accès Internet auront un objet virtuel de passerelle Internet.

---

pour comprendre la distinction entre les sous-réseaux "privés" et "publics" dans Amazon VPC nécessite une compréhension de la façon dont le routage IP et la traduction d'adresses réseau (NAT) fonctionnent en général, et comment il ils sont spécifiquement mis en œuvre dans VPC.

la différenciation de base entre un sous-réseau public et privé dans VPC est définie par la route par défaut de ce sous-réseau, dans les tables de routage VPC.

This la configuration, à son tour, dicte la validité d'utiliser ou de ne pas utiliser les adresses IP publiques sur les instances de ce sous-réseau particulier.

chaque sous-réseau a exactement une route par défaut, qui ne peut être que l'une des deux choses:

• l'objet "passerelle Internet" de VPC, dans le cas d'un sous-réseau" public", ou
• un périphérique NAT -- c'est-à-dire une passerelle NAT ou une instance EC2, jouant le rôle "d'instance NAT", dans le cas d'un "privé" sous-réseau.

la passerelle Internet ne fait pas de traduction d'adresse réseau pour les instances sans adresse IP publique de sorte qu'une instance sans adresse IP publique ne peut pas se connecter outward à Internet -- pour faire des choses comme télécharger des mises à jour logicielles, ou accéder à d'autres ressources AWS comme S3 ¹ et SQS -- si la route par défaut sur son sous-réseau VPC est l'objet passerelle Internet. Donc, si vous êtes une instance sur un sous-réseau "public", puis vous besoin une adresse IP publique afin de faire un nombre important de choses que les serveurs ont généralement besoin de faire.

pour les cas avec seulement une adresse IP privée, il y a une autre façon d'accéder à Internet. C'est là que la translation D'adresse réseau2 et une instance NAT sont entrées.

les machines sur un sous-réseau privé peuvent accéder à Internet parce que la route par défaut sur un le sous-réseau privé est et non l'objet VPC" passerelle Internet " -- il s'agit d'une instance EC2 configurée comme une instance NAT.

une instance NAT est une instance sur un sous-réseau public avec une IP publique, et une configuration spécifique. Il ya des AMIs qui sont pré-construit pour le faire, ou vous pouvez construire votre propre.

lorsque les machines privées envoient du trafic vers l'extérieur, le trafic est envoyé, par VPC, à L'instance NAT, qui remplace la source L'adresse IP sur le paquet (l'adresse IP privée de la machine privée) avec sa propre adresse IP publique, envoie le trafic à L'Internet, Accepte les paquets de réponse, et les renvoie à l'adresse privée de la machine d'origine. (Il peut aussi réécrire le port source, et dans tous les cas, il se souvient des mappages pour savoir quelle machine interne devrait recevoir les paquets de réponse). Une instance NAT ne permet pas à un trafic entrant "inattendu" d'atteindre les instances privées, sauf s'il a été configuré pour le faire.

ainsi, lors de l'accès à une ressource Internet externe à partir d'un sous-réseau privé, le trafic traverse L'instance NAT, et semble à la destination avoir provenu de l'adresse IP publique de l'instance NAT... donc le trafic de réponse revient à L'instance NAT. Ni le groupe de sécurité assigné à L'instance NAT ni le groupe de sécurité assigné à l'instance privée n'ont besoin d'être configurés pour "permettre" ceci trafic de réponse, parce que les groupes de sécurité sont dynamique. Ils réalisent que le trafic de réponse est corrélé à des sessions internes, donc il est automatiquement autorisé. Le trafic inattendu est, bien sûr, refusé à moins que le groupe de sécurité ne soit configuré pour le permettre.

contrairement au routage IP classique, où votre passerelle par défaut est sur votre même sous-réseau, la façon dont il fonctionne dans VPC est différente: L'instance NAT pour un sous-réseau privé donné est toujours sur un sous-réseau différent, et que l'autre sous-réseau est toujours un sous-réseau public, parce que L'instance NAT doit avoir une IP externe publique, et sa passerelle par défaut doit être l'objet VPC "Internet Gateway".

de même... vous ne pouvez pas déployer une instance avec une IP publique sur un sous-réseau privé. Cela ne fonctionne pas, car la route par défaut sur un sous-réseau privé est (par définition) une instance NAT (qui exécute NAT sur le trafic), et non l'objet passerelle Internet (qui ne le fait pas). Le trafic entrant de L'Internet frapperait L'IP publique de l'instance, mais les réponses essayeraient d'acheminer vers l'extérieur par L'intermédiaire de L'instance NAT, qui serait soit laisser tomber le trafic (car il serait composé de réponses à des connexions dont elle n'est pas au courant, de sorte qu'ils seraient considérés comme invalides) ou réécrire le trafic de réponse à utiliser sa propre adresse IP publique, ce qui ne fonctionnerait pas puisque l'origine externe n'accepterait pas les réponses qui viennent d'une adresse IP autre que celle qu'ils essayaient d'initier les communications avec.

en substance, les désignations" privé "et" public " ne concernent pas vraiment l'accessibilité ou l'inaccessibilité à partir de l'Internet. Elles concernent les types d'adresses qui seront attribuées aux instances sur ce sous-réseau, ce qui est pertinent en raison de la nécessité de traduire-ou d'éviter de traduire-ces adresses IP pour les interactions Internet.

puisque VPC a des routes implicites de tous les sous-réseaux VPC vers tous les autres sous-réseaux VPC, le la route par défaut ne joue aucun rôle dans le trafic VPC interne. Les Instances avec des adresses IP privées se connecteront à d'autres adresses IP privées dans le VPC "à partir" de leur adresse IP privée, et non "à partir" de leur adresse IP publique (si elles en ont une)... aussi longtemps que l'adresse de destination est une autre adresse privée dans le VPC.

si vos instances avec des adresses IP privées n'ont jamais, en aucun cas, besoin de générer du trafic Internet sortant, alors ils techniquement pourrait être déployé sur un sous-réseau "public" et serait encore inaccessible à partir de l'Internet... mais dans une telle configuration, il leur est impossible de générer du trafic sortant vers Internet, ce qui inclut les connexions avec d'autres services D'infrastructure SSFE, encore une fois, comme S3 ¹ ou SQS.

---

^{1. En ce qui concerne S3, en particulier, de dire que l'accès à Internet est toujours il est nécessaire de simplifier à l'excès la portée de ces services au fil du temps et de les étendre à d'autres services de SSFE, au fur et à mesure que les capacités de la VPC continueront de croître et d'évoluer. Il existe un concept relativement nouveau appelé VPC Endpoint qui permet à vos instances, y compris celles qui n'ont que des adresses IP privées, d'accéder directement à S3 à partir de sous-réseaux sélectionnés dans le VPC, sans toucher à "L'Internet", et sans utiliser une instance NAT ou une passerelle NAT, mais cela nécessite configuration supplémentaire, et n'est utilisable que pour accéder aux seaux dans la même région AWS que votre VPC. Par défaut, S3 -- qui est, au moment de la rédaction du présent document, le seul service qui ait exposé la capacité de créer des paramètres VPC -- n'est accessible que de L'intérieur de VPC via Internet. Lorsque vous créez un endpoint VPC, cela crée une liste de préfixes ( pl-xxxxxxxx ) que vous pouvez utiliser dans vos tables de route VPC pour envoyer le trafic lié à ce service AWS particulier directement au service via le virtuel " VPC Endpoint" objet. Il résout également un problème de restriction de l'accès sortant à S3 par exemple, parce que la liste de préfixe peut être utilisée dans les groupes de sécurité sortant, à la place d'une adresse IP de destination ou d'un bloc -- et un terminal VPC S3 peut être soumis à des déclarations de politique supplémentaires, en limitant l'accès de seau de l'intérieur, comme désiré.}

^{2. Comme indiqué dans la documentation, Ce Qui est effectivement discuté ici est le port ainsi que le réseau la translation d'adresse. Il est courant, bien que techniquement un peu imprécis, de se référer à l'opération combinée comme "NAT."Cela ressemble un peu à la façon dont beaucoup d'entre nous ont tendance à dire "SSL" quand nous voulons réellement dire "TLS."Nous savons de quoi nous parlons, mais nous n'utilisons pas le mot le plus juste pour le décrire. "Remarque Nous utilisons le terme NAT dans cette documentation pour suivre la pratique informatique courante, bien que le rôle réel d'un périphérique NAT soit à la fois la traduction d'adresse et la traduction d'adresse de port. (PAT.)"}