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.
Benutzerdefiniertes Netzwerk ACLs für Ihre VPC
Sie können eine benutzerdefinierte Netzwerk-ACL erstellen und einem Subnetz zuordnen. So können Sie bestimmten eingehenden oder ausgehenden Datenverkehr auf der Subnetzebene verweigern. Weitere Informationen finden Sie unter Erstellen einer Netzwerk-ACL für Ihre VPC.
Jede Netzwerk-ACL enthält eine Standardregel für eingehenden Datenverkehr und eine Standardregel für ausgehenden Datenverkehr, deren Regelnummer ein Sternchen (*) ist. Über diese Regel wird sichergestellt, dass Pakete, die mit keiner anderen Regel übereinstimmen, abgelehnt werden.
Sie können eine Netzwerk-ACL ändern, indem Sie Regeln ergänzen oder entfernen. Sie können keine Regeln löschen, deren Nummer ein Sternchen enthält.
Für jede hinzugefügte Regel muss eine entsprechende Regel für ausgehenden oder eingehenden Datenverkehr existieren, die Antworten ermöglicht. Weitere Informationen zur Auswahl des passenden Bereichs für flüchtige Ports finden Sie unter Flüchtige Ports.
Beispiel: Regeln für eingehenden Datenverkehr
Die folgende Tabelle zeigt die Beispielregeln für eingehenden Datenverkehr für eine Netzwerk-ACL. Die Regeln für IPv6 werden nur hinzugefügt, wenn der VPC ein IPv6 CIDR-Block zugeordnet ist. IPv4 und der IPv6 Verkehr werden separat bewertet. Daher gilt keine der IPv4 Verkehrsregeln für den IPv6 Verkehr. Sie können IPv6 Regeln neben den entsprechenden IPv4 Regeln oder die IPv6 Regeln nach der letzten IPv4 Regel hinzufügen.
Wenn ein Paket im Subnetz eingeht, werden die Regeln für eingehenden Datenverkehr der Netzwerk-ACL, die mit dem Subnetz verknüpft ist, nacheinander ausgewertet, beginnend mit der Regel mit der niedrigsten Nummer. Nehmen wir zum Beispiel an, es gibt IPv4 Datenverkehr, der für den HTTPS-Port (443) bestimmt ist. Das Paket stimmt nicht mit Regel 100 oder 105 überein. Es entspricht Regel 110, die den Datenverkehr in das Subnetz zulässt. Wenn das Paket für Port 139 (NetBIOS) bestimmt gewesen wäre, würde es keiner der nummerierten Regeln entsprechen, sodass die *-Regel für den IPv4 Verkehr das Paket letztendlich ablehnt.
| Regel Nr. | Typ | Protocol (Protokoll) | Port-Bereich | Source | Erlauben/Verweigern | Kommentare |
|---|---|---|---|---|---|---|
100 |
HTTP |
TCP |
80 |
0.0.0.0/0 |
ERLAUBEN |
Lässt eingehenden HTTP-Verkehr von einer beliebigen Adresse aus zu. IPv4 |
105 |
HTTP |
TCP |
80 |
::/0 |
ERLAUBEN |
Erlaubt eingehenden HTTP-Verkehr von einer beliebigen Adresse aus. IPv6 |
110 |
HTTPS |
TCP |
443 |
0.0.0.0/0 |
ERLAUBEN |
Erlaubt eingehenden HTTPS-Verkehr von einer beliebigen Adresse aus. IPv4 |
115 |
HTTPS |
TCP |
443 |
::/0 |
ERLAUBEN |
Erlaubt eingehenden HTTPS-Verkehr von einer beliebigen Adresse aus. IPv6 |
120 |
SSH |
TCP |
22 |
|
ERLAUBEN |
Ermöglicht eingehenden SSH-Verkehr aus dem öffentlichen IPv4 Adressbereich Ihres Heimnetzwerks (über das Internet-Gateway). |
140 |
Custom TCP |
TCP |
|
0.0.0.0/0 |
ERLAUBEN |
Ermöglicht eingehenden IPv4 Rückverkehr aus dem Internet (für Anfragen, die aus dem Subnetz stammen). |
145 |
Custom TCP |
TCP |
|
::/0 |
ERLAUBEN |
Erlaubt eingehenden IPv6 Rückverkehr aus dem Internet (für Anfragen, die ihren Ursprung im Subnetz haben). |
* |
Gesamter Datenverkehr |
Alle |
Alle |
0.0.0.0/0 |
DENY |
Verweigert den gesamten eingehenden IPv4 Datenverkehr, der noch nicht durch eine vorherige Regel behandelt wurde (nicht änderbar). |
* |
Gesamter Datenverkehr |
Alle |
Alle |
::/0 |
DENY |
Verweigert den gesamten eingehenden IPv6 Verkehr, der noch nicht durch eine vorherige Regel behandelt wurde (nicht änderbar). |
Regeln für ausgehenden Datenverkehr
Die folgende Tabelle zeigt die Beispielregeln für ausgehenden Datenverkehr für eine benutzerdefinierte Netzwerk-ACL. Die Regeln für IPv6 werden nur hinzugefügt, wenn der VPC ein IPv6 CIDR-Block zugeordnet ist. IPv4 und der IPv6 Verkehr werden separat bewertet. Daher gilt keine der IPv4 Verkehrsregeln für den IPv6 Verkehr. Sie können IPv6 Regeln neben den entsprechenden IPv4 Regeln oder die IPv6 Regeln nach der letzten IPv4 Regel hinzufügen.
| Regel Nr. | Typ | Protocol (Protokoll) | Port-Bereich | Zielbereich | Erlauben/Verweigern | Kommentare |
|---|---|---|---|---|---|---|
100 |
HTTP |
TCP |
80 |
0.0.0.0/0 |
ERLAUBEN |
Ermöglicht ausgehenden IPv4 HTTP-Verkehr vom Subnetz zum Internet. |
105 |
HTTP |
TCP |
80 |
::/0 |
ERLAUBEN |
Lässt ausgehenden IPv6 HTTP-Verkehr vom Subnetz zum Internet zu. |
110 |
HTTPS |
TCP |
443 |
0.0.0.0/0 |
ERLAUBEN |
Lässt ausgehenden IPv4 HTTPS-Verkehr vom Subnetz zum Internet zu. |
115 |
HTTPS |
TCP |
443 |
::/0 |
ERLAUBEN |
Ermöglicht ausgehenden IPv6 HTTPS-Verkehr vom Subnetz zum Internet. |
120 |
Custom TCP |
TCP |
|
|
ERLAUBEN |
Lässt ausgehende Antworten für den SSH-Datenverkehr von Ihrem Heimnetzwerk zu. |
140 |
Custom TCP |
TCP |
|
0.0.0.0/0 |
ERLAUBEN |
Ermöglicht ausgehende IPv4 Antworten an Clients im Internet (z. B. das Bereitstellen von Webseiten). |
145 |
Custom TCP |
TCP |
|
::/0 |
ERLAUBEN |
Ermöglicht ausgehende IPv6 Antworten an Clients im Internet (z. B. das Bereitstellen von Webseiten). |
* |
Gesamter Datenverkehr |
Alle |
Alle |
0.0.0.0/0 |
DENY |
Verweigert den gesamten ausgehenden IPv4 Datenverkehr, der noch nicht durch eine vorherige Regel behandelt wurde. |
* |
Gesamter Datenverkehr |
Alle |
Alle |
::/0 |
DENY |
Verweigert den gesamten ausgehenden IPv6 Datenverkehr, der noch nicht durch eine vorherige Regel behandelt wurde. |
Flüchtige Ports
Die Beispiel-Netzwerk-ACL im vorhergehenden Abschnitt verwendet den flüchtigen Portbereich 32768 bis 65535. Möglicherweise möchten Sie jedoch ACLs je nach Clienttyp, den Sie verwenden oder mit dem Sie kommunizieren, einen anderen Bereich für Ihr Netzwerk verwenden.
Der flüchtige Portbereich wird vom Client festgelegt, von dem die Anfrage ausgeht. Der Bereich ist abhängig vom Betriebssystem des Clients.
-
Viele Linux-Kernel (einschließlich des Amazon Linux-Kernels) verwenden Ports 32768-61000.
-
Anfragen, die von ELB ausgehen, verwenden die Ports 1024-65535.
-
Windows-Betriebssysteme bis Windows Server 2003 verwenden die Ports 1025 bis 5000.
-
Ab Windows Server 2008 werden die Ports 49152 bis 65535 verwendet.
-
NAT-Gateways verwenden die Ports 1024 bis 65535.
-
AWS Lambda Funktionen verwenden die Ports 1024-65535.
Wenn eine Anfrage beispielsweise von einem Windows 10-Client im Internet auf einem Webserver in Ihrer VPC eingeht, muss Ihre Netzwerk-ACL über eine Regel für ausgehenden Datenverkehr verfügen, die Datenverkehr für die Ports 49152-65535 erlaubt.
Wenn die Anfrage von einer Instance in Ihrer VPC ausgeht, muss Ihre Netzwerk-ACL über eine Regel für eingehenden Datenverkehr verfügen, um Datenverkehr zu den spezifischen Ports des Betriebssystems zuzulassen.
In der Praxis empfiehlt es sich, die flüchtigen Ports 1024 bis 65535 zu öffnen, um die unterschiedlichen Client-Typen abzudecken, von denen Datenverkehr an öffentliche Instances in Ihrer VPC gelangen kann. Sie können der ACL jedoch auch Regeln hinzufügen, um Datenverkehr für böswillige Ports innerhalb dieses Bereichs zu verweigern. Platzieren Sie die deny (verweigern)-Regeln in der Tabelle vor den allow (erlauben)-Regeln, die den gesamten flüchtigen Portbereich freigeben.
Benutzerdefiniertes Netzwerk und andere Dienste ACLs AWS
Wenn Sie eine benutzerdefinierte Netzwerk-ACL erstellen, sollten Sie sich darüber im Klaren sein, wie sich dies auf Ressourcen auswirken kann, die Sie mit anderen AWS Diensten erstellen.
Wenn das Subnetz für Ihre Back-End-Instances über eine Netzwerk-ACL verfügt, in der Sie eine Ablehnungsregel für den gesamten Datenverkehr mit einer CIDR-Quelle 0.0.0.0/0 oder der CIDR-Quelle des Subnetzes hinzugefügt haben, kann Ihr Load Balancer keine Integritätsprüfungen an den Instances durchführen. Weitere Informationen zu den empfohlenen Netzwerk-ACL-Regeln für Load Balancer und Backend-Instances finden Sie unter:
Beheben von Problemen mit der Erreichbarkeit
Reachability Analyzer ist ein Tool zur statischen Konfigurationsanalyse. Mit Reachability Analyzer können Sie die Netzwerkerreichbarkeit zwischen zwei Ressourcen in Ihrer VPC analysieren und debuggen. Reachability Analyzer erzeugt hop-by-hop Details zum virtuellen Pfad zwischen diesen Ressourcen, wenn sie erreichbar sind, und identifiziert andernfalls die blockierende Komponente. Zum Beispiel kann er fehlende oder falsch konfigurierte Netzwerk-ACL-Regeln identifizieren.
Weitere Informationen finden Sie im Leitfaden Reachability Analyzer.
