Ich habe versucht zu verstehen, wie das Routing in einem AWS VPC mit öffentlichen/privaten Subnetzen funktioniert.
Ich habe ein Setup wie von Amazon empfohlen mit einem ELB und NAT im öffentlichen Subnetz und dem Webserver im privaten Subnetz. Ich habe Sicherheitsgruppen (SG) konfiguriert wiehttp://blogs.aws.amazon.com/security/blog/tag/NATund alles funktioniert wie erwartet. Großartig!
Was ich noch nicht verstehe, ist, wie in der obigen Architektur HTTP-Antworten von der Webserverinstanz zurückgegeben werden.
Eine Web-Anfrage kommt also aus dem öffentlichen Internet über HTTP, 80 trifft auf ELB und ELB leitet sie an die private IP des Webservers weiter, cool. Jetzt muss der Webserver antworten. So wie ich das verstehe, erfolgt die Antwort über einen anderen, höheren TCP-Port (1024-65535). Das NAT SG erlaubt nur ausgehenden Datenverkehr über die Ports 80 und 443. Wie gelangt diese Antwort also zurück ins öffentliche Internet? Sie kann nicht durch das NAT gehen. Bedeutet das, dass die Antwort zurück durch das ELB geht? Das Amazon-Diagramm zeigt den ELB-Verkehrsrichtungspfeil nicht als bidirektional an, und auch die ELB-Dokumentation besagt nicht, dass sich das ELB wie ein Stateful NAT verhält. Tut es das?
Antwort1
Die Pfeile im Diagramm zeigen lediglich die Richtung des Verbindungsaufbaus an, nicht den Verkehrsfluss.
Ja, der Rückverkehr erfolgt über die ELB.
Es handelt sich jedoch nicht um ein Stateful NAT, sondern um einen TCP-Verbindungsproxy. Die ELB-Maschinen akzeptieren TCP-Verbindungen auf den konfigurierten Abhörports, beenden die SSL-Sitzung (sofern konfiguriert) und stellen eine neue TCP-Verbindung zum Back-End-Server her. Wenn der Listener für HTTP konfiguriert ist, arbeitet der ELB in einem Payload-Aware-Modus, der HTTP-Anfragen analysiert, protokolliert und an das Back-End weiterleitet. Andernfalls ist er Payload-agnostisch, stellt für jede eingehende Verbindung eine neue 1:1-TCP-Verbindung zum Back-End her und „bindet die Pipes zusammen“ (ohne HTTP-Level-Awareness oder -Änderung).
In jedem Fall ist die Quelladresse der eingehenden Verbindung zu Ihrer Anwendung die des ELB-Knotens und nicht die des ursprünglichen Clients. Auf diese Weise wird der Antwortverkehr zum ELB zurückgeleitet, um an den Client zurückgegeben zu werden.
Im http-Modus fügt der ELB hinzu(oder wird an den X-Forwarded-ForHeader angehängt), damit Ihre Anwendung die ursprüngliche Client-IP identifizieren kann, und X-Forwarded-Proto: [ http | https ]um anzuzeigen, ob die Client-Verbindung SSL verwendet und X-Forwarded-Portum den Front-End-Port anzugeben.
Aktualisieren:Das Obige bezieht sich auf einen Lastenausgleichstyp, der jetzt als „ELB Classic“ oder ELB/1.0 bekannt ist (zu finden in der Benutzeragentzeichenfolge, die er mit HTTP-Integritätsprüfungen sendet).
Der neuere Layer-7-Balancer, Application Load Balancer oder ELB/2.0, funktioniert hinsichtlich des Verkehrsflusses ähnlich. Die Layer-4-Funktion („transparentes“ TCP) wurde aus ALB entfernt und die Layer-7-Funktionen wurden erheblich verbessert.
Der neueste Typ von Load Balancer, der Network Load Balancer, ist ein Layer-3-Balancer. Anders als die anderen beiden verhält er sich sehr ähnlich wie dynamisches NAT, verarbeitet nur eingehende (von außen kommende) Verbindungen und ordnet Quelladresse+Port über EIP-Adresse+Port der privaten IP-Adresse der Instanz:Adresse+Port zu – wobei die EIP an den „Balancer“ gebunden ist – und anders als bei den anderen beiden Balancertypen müssen sich die Instanzen in öffentlichen Subnetzen befinden und hierfür ihre eigenen öffentlichen IPs verwenden.
Konzeptionell gesehen scheint der Network Load Balancer tatsächlich das Verhalten des Internet-Gateways zu ändern – das selbst ein logisches Objekt ist, das nicht deaktiviert oder ersetzt werden kann oder bei dem in irgendeiner sinnvollen Weise ein Fehler auftritt. Dies steht im Gegensatz zu ELB und ALB, die tatsächlich auf „versteckten“ EC2-Instanzen arbeiten. NLB arbeitet allem Anschein nach auf der Netzwerkinfrastruktur selbst.
Antwort2
Laut AWS-Dokumentation für NLB handelt es sich um Schicht 4 und nicht um Schicht 3. Auch die Backend- oder Zielserver müssen sich nicht in einem öffentlichen Subnetz befinden. Tatsächlich müssen die IP-Adressbereiche der Zielgruppen einer der folgenden sein: Die folgenden Zieltypen sind möglich:
Instanz. Die Ziele werden durch die Instanz-ID angegeben.
ip Die Ziele werden durch die IP-Adresse angegeben.
Wenn der Zieltyp „IP“ ist, können Sie IP-Adressen aus einem der folgenden CIDR-Blöcke angeben:
Die Subnetze der VPC für die Zielgruppe
10.0.0.0/8 (RFC 1918)
100.64.0.0/10 (RFC 6598)
172.16.0.0/12 (RFC 1918)
192.168.0.0/16 (RFC 1918)
Wichtig
Sie können keine öffentlich routbaren IP-Adressen angeben.
Ich hoffe das hilft.