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

il y a 4 scénarios dans AWS VPC configure. Mais regardons ces deux-là:

  • scénario 1: 1 sous-réseau public.
  • scénario 2: 1 sous-réseau public et 1 sous-réseau privé.

étant donné que toute instance lancée dans un sous-réseau public ne dispose pas d'EIP (sauf si elle est assignée), elle n'est déjà pas adressable à partir d'Internet. Puis:

  • Pourquoi y a-t-il une besoin de sous-réseau privé?
  • quelles sont exactement les différences entre les sous-réseaux privés et publics?
104
demandé sur J P 2014-03-05 08:20:04
la source

4 ответов

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 1 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 1 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.)"

206
répondu Michael - sqlbot 2016-10-13 13:25:22
la source

je n'ai pas la réputation d'ajouter un commentaire à Michael réponse ci-dessus, d'où l'ajout de mon commentaire comme une réponse.

il est intéressant de noter que la passerelle gérée par AWS est ~3 fois plus chère que la date lorsque comparée à l'exécution de votre propre instance. Ceci suppose bien sûr que vous n'avez besoin que d'une seule instance NAT (I. e vous n'avez pas plusieurs instances NAT configurées pour le basculement, etc.), ce qui est généralement le cas pour la plupart des scénarios d'utilisation petite à moyenne. Supposer un transfert de données mensuel de 100 Go via la passerelle NAT,

instance NAT gérée coût mensuel = 33,48 $ / mois (0,045 $ / heure * 744 heures dans un mois) + 4,50 $(0,045 $par Go de données traitées * 100 Go) + 10 $( $ .10 / GB frais standard de transfert de données AWS pour toutes les données transférées via la passerelle NAT) = 47,98 $151910920"

t2.Nano instance configurée comme une instance NAT = $ 4.84 / mois ($0.0065 * 744 heures dans un mois) + $10 ($.10 / GB standards AWS data transfer charges for all données transférées via L'instance NAT) = 14,84 $151910920"

cela change bien sûr quand vous allez pour les instances redondantes NAT puisque la passerelle NAT gérée par AWS a une redondance intégrée pour une haute disponibilité. Si vous ne vous souciez pas des 33 $supplémentaires / mois, alors L'instance NAT gérée vaut certainement le casse-tête réduit de ne pas avoir à maintenir une autre instance. Si vous utilisez une instance VPN (par exemple OpenVPN) pour accéder à vos instances dans le VPC, vous pouvez simplement configurer cette instance pour agir aussi comme votre passerelle NAT, et ensuite vous n'avez pas à maintenir une instance supplémentaire juste pour le NAT (bien que certaines personnes puissent désapprouver l'idée de combiner le VPN et le NAT).

18
répondu Jim Walker 2015-12-19 12:45:44
la source

je suggérerais un autre sous - réseau" privé " tack-ditch et des instances / passerelles NAT. Elles ne sont pas nécessaires. Si vous ne voulez pas que la machine soit accessible à partir d'internet, ne la mettez pas dans un groupe de sécurité qui permet un tel accès.

en abandonnant L'instance / passerelle NAT, vous éliminez le coût de fonctionnement de l'instance / passerelle, et vous éliminez la limite de vitesse (que ce soit 250mbit ou 10gbit).

Si vous avez une machine qui de plus, il n'est pas nécessaire d'accéder directement à internet (et je vous demanderais comment vous le corrigez*), alors par tous les moyens, ne pas attribuer d'adresse IP publique.

* si la réponse ici est une sorte de procuration, Eh bien, vous êtes en face d'un plafond, mais chacun à sa propre.

16
répondu Phil 2016-10-24 23:32:06
la source

La réponse par Michael - sqlbot fait l'hypothèse implicite que les adresses IP privées sont nécessaires. Je pense qu'il vaut la peine de remettre en question cette hypothèse -- avons-nous même besoin d'utiliser des adresses IP privées en premier lieu? Au moins un commentateur a posé la même question.

Quel est l'avantage d'un serveur sur un sous-réseau privé avec une instance NAT [vs] un serveur [dans un] sous-réseau public avec une politique de sécurité stricte? – abhillman le 24 Juin '14 à 23:45

Imaginez un scénario où vous utilisez un VPC et que vous assignez des adresses IP publiques à toutes vos instances EC2. Ne vous inquiétez pas, cela ne veut pas dire qu'ils sont nécessairement accessibles sur internet, parce que vous utilisez des groupes de sécurité pour restreindre l'accès exactement de la même manière que les choses ont fonctionné avec EC2 classic. En utilisant des adresses IP publiques, vous avez l'avantage de pouvoir facilement exposer certains services pour un public limité sans avoir besoin d'utiliser quelque chose comme un Elbe. Cela vous libère de la nécessité de configurer une instance NAT ou une passerelle NAT. Et puisque vous avez besoin de la moitié du nombre de sous-réseaux, vous pouvez choisir d'utiliser une allocation plus petite du CIDR pour votre CPV ou vous pouvez faire des sous-réseaux plus grands avec la même taille de CPV. Et moins de sous-réseaux signifie que vous paierez moins pour le trafic inter-AZ aussi.

alors, pourquoi ne pas faire ça? Pourquoi AWS dit - il que la meilleure pratique est d'utiliser des IPs privés?

Amazon Web Services a une offre limitée d'adresses IPv4 publiques parce que l'internet dans son ensemble a une offre limitée D'adresses IPv4 publiques. Il est dans leur meilleur intérêt que vous utilisiez des adresses IP privées qui sont effectivement illimitées, plutôt que de consommer des adresses IPv4 publiques excessivement rares. Vous pouvez voir quelques preuves de cela dans la façon dont les prix AWS IP élastiques; un EIP attaché à une instance est libre, mais un EIP non utilisé coûte de l'argent.

mais pour le besoins de la discussion, supposons que nous ne nous soucions pas de la pénurie d'adresses IPv4 publiques sur internet. Après tout, mon application est spéciale. Ce qui se passe ensuite?

il n'y a que deux façons de joindre une adresse IP publique à une instance EC2 dans un VPC.

1. Adresse IP publique associée

vous pouvez demander une adresse IP publique lors du lancement d'une nouvelle instance EC2. Ce l'option apparaît comme une case à cocher dans la console, comme le drapeau --associate-public-ip-address lors de l'utilisation d'aws-cli, et comme le drapeau AssociatePublicIpAddress sur un objet d'interface réseau intégré lors de l'utilisation de CloudFormation. Dans tous les cas, L'adresse IP publique est attribuée à eth0 (DeviceIndex=0). Vous pouvez uniquement utiliser cette approche lors du lancement d'une nouvelle instance. Toutefois, cela vient avec des avantages et des inconvénients.

un inconvénient est que changer le groupe de sécurité d'une instance qui utilise un objet d'interface réseau intégré va forcer le remplacement immédiat de l'instance, au moins si vous utilisez CloudFormation.

un autre inconvénient est qu'une adresse IP publique assignée de cette façon sera perdue lorsque l'instance est arrêtée.

2. Elastic IP

en général, les IP élastiques sont l'approche préférée parce qu'elles sont plus sûr. Vous êtes assuré de continuer à utiliser la même adresse IP, vous ne risquez pas de supprimer accidentellement des instances EC2, vous pouvez librement fixer/détacher une IP élastique à tout moment, et vous avez la liberté de changer les groupes de sécurité appliqués à vos instances EC2.

... Mais AWS vous limite à 5 EIP par région. Vous pouvez demander plus, et votre demande pourrait être accordée. Mais AWS pourrait tout aussi bien rejeter cette demande sur la base du raisonnement que j'ai mentionné surtout. Donc, vous ne voulez probablement pas compter sur EIP's si vous prévoyez de mettre à l'échelle votre infrastructure au-delà de 5 EC2 instances par région.

en conclusion, l'utilisation d'adresses IP publiques présente de nombreux avantages, mais vous rencontrerez des problèmes administratifs ou de mise à l'échelle si vous essayez d'utiliser exclusivement les adresses IP publiques. Espérons que cela aidera à illustrer et à expliquer pourquoi les meilleures pratiques sont telles qu'elles sont.

9
répondu Nic 2017-10-20 15:18:46
la source

Autres questions sur