Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Verbindungsverfolgung von Sicherheitsgruppen
Ihre Sicherheitsgruppen verwenden die Verbindungsverfolgung zur Nachverfolgung des Datenverkehrs zu und von der Instance. Regeln werden auf der Grundlage des Verbindungszustands des Datenverkehrs angewendet, um zu ermitteln, ob der Datenverkehr zulässig ist oder nicht. Bei diesem Ansatz sind Sicherheitsgruppen zustandsbehaftet. Das bedeutet, dass Antworten auf eingehenden Verkehr unabhängig von den Regeln für ausgehende Sicherheitsgruppen aus der Instance fließen dürfen und umgekehrt.
Angenommen, Sie initiieren einen Befehl wie „netcat“ oder ähnliches für Ihre Instances von Ihrem Heimcomputer aus und Ihre eingehenden Sicherheitsgruppenregeln lassen ICMP-Datenverkehr zu. Informationen über die Verbindung (einschließlich der Port-Informationen) werden verfolgt. Antwort-Datenverkehr von der Instance für den -Befehl wird nicht als neue Anfrage verfolgt, sondern als eingerichtete Verbindung; dieser Datenverkehr kann die Instance verlassen, selbst wenn Ihre ausgehenden Sicherheitsgruppenregeln ausgehenden ICMP-Datenverkehr beschränken.
Für andere Protokolle als TCP, UDP oder ICMP werden nur die IP-Adresse und die Protokollnummer verfolgt. Wenn Ihre Instance Datenverkehr an einen anderen Host sendet und der Host innerhalb von 600 Sekunden dieselbe Art von Datenverkehr an Ihre Instance sendet, akzeptiert die Sicherheitsgruppe für Ihre Instance diesen unabhängig von den Sicherheitsgruppen-Regeln für eingehenden Datenverkehr. Die Sicherheitsgruppe akzeptiert ihn, da er als Antwort-Datenverkehr für den ursprünglichen Datenverkehr angesehen wird.
Wenn Sie eine Sicherheitsgruppenregel ändern, werden ihre nachverfolgten Verbindungen nicht sofort unterbrochen. Die Sicherheitsgruppe lässt Pakete weiterhin zu, bis bei bestehenden Verbindungen eine Zeitüberschreitung (Timeout) auftritt. Um sicherzustellen, dass Datenverkehr sofort unterbrochen wird oder der gesamte Datenverkehr unabhängig vom Nachverfolgungsstatus den Firewall-Regeln unterliegt, können Sie eine Netzwerk-ACL für Ihr Subnetz verwenden. Netzwerk-ACLs sind zustandslos und lassen daher nicht automatisch Antwortdatenverkehr zu. Das Hinzufügen einer Netzwerk-ACL, die Datenverkehr in beide Richtungen blockiert, trennt vorhandene Verbindungen. Weitere Informationen finden Sie unter Netzwerk-ACLs im Amazon VPC Benutzerhandbuch.
Anmerkung
Sicherheitsgruppen haben keine Auswirkung auf den DNS-Verkehr zum oder vom Route 53 Resolver, der manchmal auch als „VPC+2-IP-Adresse“ bezeichnet wird (siehe Was ist Amazon Route 53 Resolver? im Amazon Route 53 Developer Guide) oder im 'AmazonProvidedDNS' (siehe Arbeiten mit DHCP-Optionssätzen im Amazon Virtual Private Cloud Cloud-Benutzerhandbuch). Wenn Sie DNS-Anfragen über den Route 53 Resolver filtern möchten, können Sie die Route-53-Resolver-DNS-Firewall aktivieren (Informationen unter Route-53-Resolver-DNS-Firewall im Amazon-Route-53-Entwicklerhandbuch).
Unverfolgte Verbindungen
Nicht alle Datenverkehrsflüsse werden verfolgt. Wenn eine Sicherheitsgruppenregel TCP- oder UDP-Datenflüsse für den gesamten Datenverkehr (0.0.0.0/0 oder: :/0) zulässt und es eine entsprechende Regel in der anderen Richtung gibt, die den gesamten Antwortverkehr (0.0.0.0/0 oder: :/0) für jeden Port (0-65535) zulässt, dann wird dieser Verkehrsfluss nicht verfolgt, es sei denn, er ist Teil einer automatisch verfolgten Verbindung. Der Antwort-Datenverkehr für einen nicht nachverfolgten Fluss wird anhand der Regel für ein- oder ausgehenden Datenverkehr zugelassen, die den Antwort-Datenverkehr erlaubt, und nicht anhand von Nachverfolgungsinformationen.
Ein nicht verfolgter Datenverkehrsfluss wird sofort unterbrochen, wenn die Regel, die ihn ermöglicht, entfernt oder modifiziert wird. Wenn Sie z. B. eine offene (0.0.0.0/0) ausgehende Regel haben und eine Regel entfernen, die den gesamten (0.0.0.0/0) eingehenden SSH-Verkehr (TCP-Port 22) zur Instance zulässt (oder sie so ändern, dass die Verbindung nicht mehr zulässig wäre), werden Ihre bestehenden SSH-Verbindungen zur Instance sofort gelöscht. Die Verbindung wurde zuvor nicht nachverfolgt, sodass die Änderung die Verbindung unterbricht. Wenn Sie dagegen eine restriktivere Regel für eingehende Verbindungen verwenden, die zunächst eine SSH-Verbindung zulässt (was bedeutet, dass die Verbindung nachverfolgt wurde), diese Regel aber so ändern, dass keine neuen Verbindungen von der Adresse des aktuellen SSH-Clients mehr zugelassen werden, wird die bestehende SSH-Verbindung nicht unterbrochen, weil sie nachverfolgt wird.
Automatisch nachverfolgte Verbindungen
Verbindungen, die über Folgendes hergestellt werden, werden automatisch verfolgt, auch wenn die Sicherheitsgruppenkonfiguration ansonsten keine Nachverfolgung erfordert:
Internet-Gateways nur für ausgehenden Datenverkehr
Accelerators von Global Accelerator
NAT gateways (NAT-Gateways)
Firewall-Endpunkte von Network Firewall
Network Load Balancers
AWS PrivateLink (Schnittstelle VPC-Endpunkte)
AWS Lambda (Elastische Hyperplane-Netzwerkschnittstellen)
Zulagen für die Verbindungsverfolgung
Amazon EC2 definiert die maximale Anzahl von Verbindungen, die pro Instance verfolgt werden können. Nach Erreichen des Maximums werden alle gesendeten oder empfangenen Pakete verworfen, da keine neue Verbindung hergestellt werden kann. In diesem Fall können Anwendungen, die Pakete senden und empfangen, nicht ordnungsgemäß kommunizieren. Verwenden Sie die conntrack_allowance_available-Netzwerkleistungsmetrik, um die Anzahl der nachverfolgten Verbindungen zu bestimmen, die für diesen Instance-Typ noch verfügbar sind.
Um festzustellen, ob Pakete verworfen wurden, weil der Netzwerkverkehr für Ihre Instance die maximale Anzahl der nachverfolgbaren Verbindungen überschritten hat, verwenden Sie die conntrack_allowance_exceeded-Netzwerkleistungsmetrik. Weitere Informationen finden Sie unter Überwachen der Netzwerkleistung für Ihre EC2-Instance.
Wenn Sie mit Elastic Load Balancing die maximale Anzahl von Verbindungen überschreiten, die pro Instance nachverfolgt werden können, empfehlen wir, entweder die Anzahl der beim Load Balancer registrierten Instances oder die Größe der beim Load Balancer registrierten Instances zu skalieren.
Überlegungen zur Leistung der Verbindungsverfolgung
Asymmetrisches Routing, bei dem der Datenverkehr über eine Netzwerkschnittstelle in eine Instance eingeht und über eine andere Netzwerkschnittstelle wieder austritt, kann die Spitzenleistung verringern, die eine Instance erzielen kann, wenn Datenflüsse nachverfolgt werden.
Um die Spitzenleistung aufrechtzuerhalten, wenn die Verbindungsverfolgung für Ihre Sicherheitsgruppen aktiviert ist, empfehlen wir die folgende Konfiguration:
-
Vermeiden Sie nach Möglichkeit asymmetrische Routing-Topologien.
-
Verwenden Sie Netzwerk-ACLs, anstatt Sicherheitsgruppen zum Filtern zu verwenden.
-
Wenn Sie Sicherheitsgruppen mit Verbindungsverfolgung verwenden müssen, konfigurieren Sie das kürzest mögliche Verbindungstimeout.
Weitere Informationen zur Leistungsoptimierung auf dem Nitro-System finden Sie unter. Überlegungen zum Nitro-System zur Leistungsoptimierung
Timeout für die Nachverfolgung von Leerlaufverbindungen
Die Sicherheitsgruppe verfolgt jede bestehende Verbindung nach, um sicherzustellen, dass Rückpakete wie erwartet übertragen werden. Es gibt eine maximale Anzahl von Verbindungen, die pro Instance verfolgt werden können. Im Leerlauf befindliche Verbindungen können zur Erschöpfung der Kapazität der Verbindungsnachverfolgung führen und zur Folge haben, dass Verbindungen nicht nachverfolgt und Pakete verworfen werden. Sie können das Timeout für die Nachverfolgung von Leerlaufverbindungen für eine Elastic-Network-Schnittstelle festlegen.
Anmerkung
Diese Funktion ist nur für Instances verfügbar, die auf dem AWS Nitro-System basieren.
Es gibt drei konfigurierbare Timeouts:
Timeout für bestehende TCP-Verbindungen: Timeout (in Sekunden) für bestehende TCP-Verbindungen im Leerlauf. Min: 60 Sekunden. Max: 432 000 Sekunden (fünf Tage). Standard: 432 000 Sekunden. Empfohlen: Weniger als 432 000 Sekunden.
UDP-Timeout: Timeout (in Sekunden) für UDP-Datenflüsse im Leerlauf, bei denen Datenverkehr nur in eine Richtung oder nur in einer einzelnen Anforderung-Antwort-Transaktion übermittelt wurde. Min: 30 Sekunden. Max: 60 Sekunden. Standard: 30 Sekunden.
UDP-Stream-Timeout: Timeout (in Sekunden) für UDP-Datenflüsse im Leerlauf, die als Streams klassifiziert sind, bei denen mehr als eine Anforderung-Antwort-Transaktion stattgefunden hat. Min: 60 Sekunden. Max: 180 Sekunden (3 Minuten) Standard: 180 Sekunden.
In folgenden Fällen empfiehlt es sich möglicherweise, die Standard-Timeouts anzupassen:
-
Wenn Sie nachverfolgte Verbindungen mithilfe von Amazon-EC2-Netzwerkleistungsmetriken überwachen, ermöglichen Ihnen die Metriken conntrack_allowance_exceeded und conntrack_allowance_available die Überwachung verworfener Pakete und der nachverfolgten Verbindungsauslastung, um die EC2-Instance-Kapazität proaktiv per Hochskalierung oder horizontaler Skalierung zu verwalten und so den Bedarf an Netzwerkverbindungen zu decken, bevor Pakete verworfen werden. Wenn Sie conntrack_allowance_exceeded-Ausfälle auf Ihren EC2-Instances beobachten, können Sie davon profitieren, ein niedrigeres TCP-Timeout festzulegen, um veraltete TCP/UDP-Sitzungen zu berücksichtigen, die von falschen Clients oder Netzwerk-Middle-Boxen verursacht werden.
In der Regel haben Load Balancer oder Firewalls ein TCP-Etabliertes Leerlauf-Timeout im Bereich von 60 bis 90 Minuten. Wenn Sie Workloads ausführen, die voraussichtlich eine sehr hohe Anzahl von Verbindungen (mehr als 100 000) von Appliances wie Netzwerk-Firewalls verarbeiten, empfiehlt es sich, ein ähnliches Timeout für eine EC2-Netzwerkschnittstelle zu konfigurieren.
Wenn Sie einen Workload ausführen, der eine asymmetrische Routing-Topologie verwendet, empfehlen wir Ihnen, ein TCP-Idle-Timeout von 60 Sekunden zu konfigurieren.
Wenn Sie Workloads mit einer hohen Anzahl von Verbindungen wie DNS, SIP, SNMP, Syslog, Radius oder andere Dienste ausführen, die hauptsächlich UDP zur Verarbeitung von Anforderungen verwenden, können Sie das UDP-Stream-Timeout auf 60 Sekunden festlegen, um eine höhere Skalierung/Leistung für die vorhandene Kapazität zu erhalten und unklare Fehler zu vermeiden.
Bei TCP/UDP-Verbindungen über Network Load Balancer (NLBs) und Elastic Load Balancer (ELB) werden alle Verbindungen nachverfolgt. Der Wert des Leerlauf-Timeouts für TCP-Datenflüsse beträgt 350 Sekunden. Für UDP-Datenflüsse beträgt er 120 Sekunden. Er unterscheidet sich somit von den Timeout-Werten auf Schnittstellenebene. Es empfiehlt sich gegebenenfalls, Timeouts auf Netzwerkschnittstellen-Ebene zu konfigurieren, um beim Timeout mehr Flexibilität zu haben als mit den Standardwerten für ELB/NLB.
Die Timeouts für die Verbindungsnachverfolgung können bei folgenden Tätigkeiten konfiguriert werden:
Beispiel
Im folgenden Beispiel hat die Sicherheitsgruppe Regeln für eingehenden Verkehr, die TCP- und ICMP-Datenverkehr zulassen, und Regeln für ausgehenden Verkehr, die allen ausgehenden Datenverkehr zulassen.
Eingehend | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Protokolltyp | Port-Nummer | Quelle | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| TCP | 22 (SSH) | 203.0.113.1/32 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| TCP | 80 (HTTP) | 0.0.0.0/0 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| TCP | 80 (HTTP) | ::/0 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ICMP | Alle | 0.0.0.0/0 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ausgehend | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Protokolltyp | Port-Nummer | Bestimmungsort | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alle | Alle | 0.0.0.0/0 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alle | Alle | ::/0 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Bei einer direkten Netzwerkverbindung zur Instance oder Netzwerkschnittstelle sieht das Nachverfolgungsverhalten wie folgt aus:
-
Ein- und ausgehender TCP-Datenverkehr auf Port 22 (SSH) wird nachverfolgt, da die Regel für eingehenden Verkehr nur Datenverkehr von 203.0.113.1/32 und nicht von allen IP-Adressen (0.0.0.0/0) zulässt.
-
Ein- und ausgehender TCP-Datenverkehr auf Port 80 (HTTP) wird nicht nachverfolgt, da die Regeln für ein- und ausgehenden Verkehr Datenverkehr von allen IP-Adressen zulassen.
-
ICMP-Datenverkehr wird immer nachverfolgt.
Wenn Sie die Regel für ausgehenden Verkehr für IPv4-Datenverkehr entfernen, wird der gesamte ein- und ausgehende IPv4-Datenverkehr nachverfolgt, einschließlich Datenverkehr auf Port 80 (HTTP). Gleiches gilt für IPv6-Datenverkehr, wenn Sie die Regel für ausgehenden Verkehr für IPv6-Datenverkehr entfernen.
