Ich habe eine einzelne VPC in Amazon Web Services mit dem Subnetz 172.31.0.0/16. Ich habe in diesem Subnetz eine EC2-Instanz erstellt und ihr eine öffentliche Elastic IP zugewiesen. Auf dieser VPC befindet sich ein Internet-Gateway. Meine Routentabelle sieht also folgendermaßen aus:
172.31.0.0/16 local
0.0.0.0/0 igw-b4ac67d0
Um einige IP-Zugriffsprobleme bei einem externen Dienst zu umgehen, den ich nicht kontrolliere, habe ich diesem VPC ein NAT-Gateway hinzugefügt, sodass der gesamte Datenverkehr zur einzelnen externen Adresse ABCD über das NAT-Gateway geleitet wird. Das heißt, ich möchte, dass die Routentabelle folgendermaßen aussieht:
# GOAL
172.31.0.0/16 local
A.B.C.D/32 nat-451b3be9
0.0.0.0/0 igw-b4ac67d0
Aber so sehr ich es auch versuche, die AWS-Schnittstelle ändert die Reihenfolge, wenn ich auf "SPEICHERN" klicke, so dass ich immer mit
# What AWS gives me
172.31.0.0/16 local
0.0.0.0/0 igw-b4ac67d0
A.B.C.D/32 nat-451b3be9
Diese Routentabelle scheint albern: Das NAT-Gateway würde nie verwendet werden und mein Datenverkehr A.B.C.Dscheint immer noch von der Elastic IP der EC2-Instanz zu kommen.
Wie erhalte ich das Ziel der Routentabelle?
Hinweis: Der externe Dienst ermöglicht mir das Hinzufügen eineseinzelIP-Adresse, auf die der Zugriff möglich ist. Wenn ich nur eine einzige EC2-Instanz hätte, könnte ich ihnen einfach die Elastic IP-Adresse der EC2-Instanz geben. Aber ich möchte mehrere weitere EC2-Instanzen hinzufügen, die auf die gleiche Weise eingerichtet sind. Daher das NAT-Gateway. Außerdem kann ich nicht einfach auf das Internet-Gateway verzichten und nur das NAT-Gateway verwenden, da ich Dienste auf der EC2-Instanz benötige, die für die Außenwelt zugänglich sind.
Antwort1
Diese Routentabelle scheint albern
Ja, in Ihrer Interpretation ... aber Ihre Interpretation ist nicht korrekt. Die Routentabelleneinträge in VPC haben eigentlich keine Reihenfolge.
Es wird immer die spezifischste Route ausgewählt.
Jede Route in einer Tabelle gibt einen Ziel-CIDR und ein Ziel an (beispielsweise ist der für das externe Unternehmensnetzwerk 172.16.0.0/12 bestimmte Datenverkehr für das virtuelle private Gateway bestimmt). Wir verwenden die spezifischste Route, die dem Datenverkehr entspricht, um zu bestimmen, wie der Datenverkehr geroutet werden soll.
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Route_Tables.html
Ihre Konfiguration funktioniert jedoch immer noch nicht, wenn sich das NAT-Gateway tatsächlich in einem Subnetz befindet, das diese Routentabelle verwendet. Das NAT-Gateway muss sich in einem Subnetz befinden, dessen Routentabelle nichtbeliebigRouten, die zurück zum NAT-Gateway zeigen – andernfalls handelt es sich um eine Routing-Schleife. In Richtung Internet verwendet das NAT-Gateway die VPC-Routentabelle des Subnetzes, an das es tatsächlich angeschlossen ist, um auf das Internet-Gateway zuzugreifen. Es muss sich also in einem anderen Subnetz befinden als das mit den Instanzen, die es verwenden werden, da diese /32Route nicht dort platziert werden kann, wo sie den ausgehenden Datenverkehr vom NAT-Gateway beeinflusst.
Dies ist für Leute, die nicht wissen, dass das VPC-Netzwerk kein herkömmliches Ethernet-Netzwerk mit Routern ist, nicht intuitiv. Das gesamte Netzwerk ist softwaredefiniert und nicht physisch, sodass es keine Leistungseinbußen gibt, wenn der Datenverkehr Subnetzgrenzen innerhalb einer Verfügbarkeitszone überschreitet, wie dies beispielsweise bei einer EC2-Instanz in einem Subnetz der Fall ist, die ein NAT-Gateway (oder eine NAT-Instanz) in einem anderen Subnetz verwendet, oder bei einem Elastic Load Balancer in einem Subnetz, der eine Verbindung zu einer EC2-Instanz in einem anderen Subnetz herstellt. Tatsächlich ist der Datenverkehr, der in diesen Fällen von einem Subnetz in ein anderes übergeht, die Standardkonfiguration, bei der NAT-Gateways und ELBs in öffentlichen Subnetzen (Standardroute ist IGW) und EC2-Instanzen in privaten Subnetzen (Standardroute ist NAT-Gerät) platziert werden.
Beachten Sie außerdem, dass die von Ihnen versuchte Konfiguration ausgehende Verbindungen zulässt, jedoch niemals eingehende Verbindungen (von außen initiiert) von der A.B.C.DAdresse zu irgendetwas in diesem Subnetz, da die Rückroute durch das NAT-Gateway asymmetrisch ist.