Einführung
Eine öffentliche Lieferanwendung hat eine Internetroute, eine öffentliche Adresse und eine HTTP-Freigabe in der Sicherheitsgruppe. Trotzdem kann Client A sie nicht lesen. Die Subnetz-ACL erlaubt den Zielport der Anfrage, sperrt aber den Rückport des Clients. Sie diagnostizieren und reparieren diesen Weg, beobachten die Regelpriorität und stellen anschließend die bereitgestellte Anfangskonfiguration wieder her.
Schließen Sie zuerst Connect Privately to S3 with a VPC Endpoint ab. Diese frische Umgebung stellt eine eigene Anwendung, öffentliche und private Subnetze, öffentliche Route, Adresse, Gruppe und benutzerdefinierte ACL bereit. Die CLI ist konfiguriert. Bewahren Sie diese Ressourcen und das Referenznetz. Ändern Sie nur die behandelte ACL-Regel und entfernen Sie die temporäre Sperre beim Aufräumen. Der Endzustand stellt absichtlich den ursprünglichen Fehler wieder her; die Anwendung wird nicht gelöscht.
Bezug zu Zertifizierungen
Diese Grundlagenübung unterstützt folgende Prüfungsthemen.
- Cloud Practitioner (CLF-C02) · Aufgabe 3.5: Grundlegende Rollen von VPC-Sicherheitsgruppen und Netzwerk-ACLs.
- Solutions Architect – Associate (SAA-C03) · Aufgabe 1.2: Subnetzschutz und Bedingungen für Anwendungszugriff.
- CloudOps Engineer – Associate (SOA-C03) · Aufgabe 5.3: Verbindungsdiagnose anhand von ACL-Regeln und Antwortports.
- Advanced Networking – Specialty (ANS-C01) · Aufgabe 3.1: Grundlagen geordneter Subnetzregeln und Prüfung des echten Rückwegs.
Die Subnetzgrenze der Anwendung untersuchen
Ermitteln Sie die Anwendung und vergleichen Sie Route, Sicherheitsgruppe und ACL vor Änderungen.
Nutzen Sie Terminal und öffnen Sie daneben AWS View. Die private Adresse der öffentlichen Anwendung ist 10.20.1.10. Client A ist 198.51.100.10, Client B 198.51.100.20. Die bereitgestellte Gruppe erlaubt nur A TCP 80. Port 8081 besitzt keine Dienstfreigabe.
cd /home/labex/project
Wählen Sie die VPC anhand des Tags Name. Filter wählen Ressourcen, die Abfrage extrahiert die ID und $(...) speichert sie:
VPC_ID=$(aws ec2 describe-vpcs \
--filters Name=tag:Name,Values=application-network \
--query 'Vpcs[0].VpcId' \
--output text)
Speichern Sie das öffentliche Subnetz und seine bereitgestellte Schnittstelle:
SUBNET_ID=$(aws ec2 describe-subnets \
--filters "Name=vpc-id,Values=$VPC_ID" Name=tag:Name,Values=public-subnet \
--query 'Subnets[0].SubnetId' \
--output text)
ENI_ID=$(aws ec2 describe-network-interfaces \
--filters "Name=subnet-id,Values=$SUBNET_ID" \
--query 'NetworkInterfaces[0].NetworkInterfaceId' \
--output text)
Lesen Sie private Adresse, öffentliche Zuordnung und angehängte Gruppe:
aws ec2 describe-network-interfaces \
--network-interface-ids "$ENI_ID" \
--query 'NetworkInterfaces[].{Private:PrivateIpAddress,Public:Association.PublicIp,Groups:Groups}' \
--output json
Lesen Sie die dem Subnetz zugeordnete Tabelle:
aws ec2 describe-route-tables \
--filters "Name=association.subnet-id,Values=$SUBNET_ID" \
--query 'RouteTables[].{Routes:Routes,Associations:Associations}' \
--output json
Die öffentliche Adresse ist zugeordnet; eine aktive Route 0.0.0.0/0 führt zum Internet-Gateway. Speichern und lesen Sie die Gruppe:
GROUP_ID=$(aws ec2 describe-security-groups \
--filters "Name=vpc-id,Values=$VPC_ID" Name=group-name,Values=supplied-application \
--query 'SecurityGroups[0].GroupId' \
--output text)
aws ec2 describe-security-groups \
--group-ids "$GROUP_ID" \
--query 'SecurityGroups[].{Inbound:IpPermissions,Outbound:IpPermissionsEgress}' \
--output json
Eingehend ist TCP 80 von 198.51.100.10/32 erlaubt, ausgehend besteht die bereitgestellte Standardfreigabe. Bewahren Sie diese Regeln.
Eine Netzwerk-ACL kontrolliert Verkehr über eine Subnetzgrenze. Jedes Subnetz hat eine ACL; eine ACL kann mehrere Subnetze bedienen. Anders als die zustandsbehaftete Sicherheitsgruppe ist eine ACL zustandslos: Eine erlaubte Anfrage erlaubt nicht automatisch ihre Antwort. Wählen Sie die zugeordnete ACL:
ACL_ID=$(aws ec2 describe-network-acls \
--filters "Name=association.subnet-id,Values=$SUBNET_ID" \
--query 'NetworkAcls[0].NetworkAclId' \
--output text)
Lesen Sie Identität, Zuordnungen und getrennte eingehende/ausgehende Einträge:
aws ec2 describe-network-acls \
--network-acl-ids "$ACL_ID" \
--query 'NetworkAcls[].{ID:NetworkAclId,Default:IsDefault,Associations:Associations,Entries:Entries}' \
--output json
Dies ist die benutzerdefinierte application-acl, nicht die Standard-ACL. Regel 100 erlaubt in beiden Richtungen A TCP-Zielport 80. Egress: false bedeutet eingehend, true ausgehend; Protokoll 6 ist TCP. Nicht passender Verkehr erreicht die abschließende Sperre: * in AWS View, 32767 in der CLI.
Klicken Sie in AWS View auf Request application · client A: Trotz Route und Gruppenfreigabe erscheint Connection failed. Request application · client B und Request port 8081 schlagen ebenfalls fehl. Lassen Sie dieses Terminal offen, damit die IDs erhalten bleiben.
Die Regel für den Client-Rückport reparieren
Ersetzen Sie den falschen ausgehenden Port und behalten Sie die enge Clientadresse bei.
Die HTTP-Anfrage läuft vom gewählten temporären Clientport zum Serverport 80. Die Antwort läuft von 80 zum Clientport. ACL-Portbereiche vergleichen in jeder Richtung den Zielport des Pakets. Ausgehend Zielport 80 erlaubt diese Antwort nicht.
Temporäre Bereiche hängen vom initiierenden Client ab. Erlauben Sie hier den verbreiteten Bereich 1024–65535 nur zu A, 198.51.100.10/32. Das ist kein universeller Betriebssystemstandard. Ersetzen Sie die ausgehende Regel 100; --egress wählt ausgehend, --port-range den Zielbereich:
aws ec2 replace-network-acl-entry \
--network-acl-id "$ACL_ID" \
--rule-number 100 \
--protocol 6 \
--rule-action allow \
--egress \
--cidr-block 198.51.100.10/32 \
--port-range From=1024,To=65535
Ein erfolgreiches Ersetzen erzeugt keine Ausgabe. Lesen Sie die Einträge:
aws ec2 describe-network-acls \
--network-acl-ids "$ACL_ID" \
--query 'NetworkAcls[].Entries' \
--output json
Eingehend erlaubt 100 weiterhin A TCP 80. Ausgehend erlaubt 100 jetzt Zielports 1024–65535 zum selben Client. Standardsperren und Subnetzzuordnung bleiben unverändert.
Klicken Sie in AWS View erneut auf Request application · client A. Die neue Anfrage liefert Application online, Quelle 198.51.100.10, Zielport 80. Request application · client B und Request port 8081 scheitern weiter. Anfrage und Antwort passieren nun die ACL, ohne eingehende Gruppen- oder ACL-Freigaben auf andere Clients auszuweiten.
Beispiel: Eingehend erlaubt 100 A TCP 80; ausgehend erlaubt 100 Antwortzielports 1024–65535 zu A. Beide Richtungen zeigen die abschließende Sperre; die echte Anfrage liefert Application online. Ressourcen-IDs können abweichen.
Eine Sperre mit kleinerer Regelnummer beobachten
Fügen Sie absichtlich eine passende Sperre vor der eingehenden Freigabe ein, um die Reihenfolge zu beobachten.
Die Regeln werden pro Richtung aufsteigend geprüft. Der erste Treffer entscheidet; spätere Regeln werden nicht betrachtet. Erstellen Sie die temporäre eingehende Regel 90, die A TCP 80 verweigert. --ingress wählt explizit eingehend; 90 überschreibt 100 nicht:
aws ec2 create-network-acl-entry \
--network-acl-id "$ACL_ID" \
--rule-number 90 \
--protocol 6 \
--rule-action deny \
--ingress \
--cidr-block 198.51.100.10/32 \
--port-range From=80,To=80
Lesen Sie die Einträge:
aws ec2 describe-network-acls \
--network-acl-ids "$ACL_ID" \
--query 'NetworkAcls[].Entries' \
--output json
Eingehende Sperre 90 trifft vor Freigabe 100. Ausgehend 100 erlaubt weiterhin Rückports und die Gruppe HTTP von A. Beides hebt die frühere ACL-Sperre nicht auf.
Sobald AWS View die eingehende 90 zeigt, klicken Sie auf Request application · client A. Die neue Anfrage scheitert; B und 8081 bleiben gesperrt. Eine frühere erfolgreiche Antwort ist historisch: Fordern Sie nach Regeländerungen erneut an. Behalten Sie 90 für diese Prüfung und entfernen Sie sie im nächsten Schritt.
Die temporäre Sperre entfernen und Zugriff erneut testen
Entfernen Sie nur die frühere Sperre und prüfen Sie den reparierten Rückweg.
Löschen Sie die eingehende 90. Die Richtung zählt, da eingehende und ausgehende Nummern getrennt sind:
aws ec2 delete-network-acl-entry --network-acl-id "$ACL_ID" --rule-number 90 --ingress
Lesen Sie die Einträge erneut:
aws ec2 describe-network-acls \
--network-acl-ids "$ACL_ID" \
--query 'NetworkAcls[].Entries' \
--output json
90 ist nicht mehr vorhanden. Eingehend 100 erlaubt A TCP 80, ausgehend 100 seine Rückports; anderer Verkehr bleibt gesperrt. Bewahren Sie ursprüngliche ACL-Zuordnung, Gruppe, öffentliche Route und Adresse.
In AWS View liefert eine neue Request application · client A Application online. Request application · client B und Request port 8081 scheitern weiter. Die zustandsbehaftete Gruppe erlaubt Antworten zugelassener Anfragen, aber die zustandslose ACL braucht beide Richtungen. Das Entfernen der früheren Sperre öffnet diese unabhängige Grenze wieder.
Die bereitgestellte ACL-Anfangskonfiguration wiederherstellen
Machen Sie Ihre Rückportänderung rückgängig, entfernen Sie alle temporären Sperren und bewahren Sie die bereitgestellten Ressourcen.
Stellen Sie ausgehend 100 auf den bereitgestellten Zielport 80 zurück. Dieses Aufräumen reproduziert absichtlich den Ausgangsfehler; die Regel ist nicht für einen funktionierenden HTTP-Antwortweg empfohlen:
aws ec2 replace-network-acl-entry \
--network-acl-id "$ACL_ID" \
--rule-number 100 \
--protocol 6 \
--rule-action allow \
--egress \
--cidr-block 198.51.100.10/32 \
--port-range From=80,To=80
Lesen Sie das vollständige ACL-Inventar der VPC samt Zuordnungen. Löschbare Tags allein beweisen kein Aufräumen:
aws ec2 describe-network-acls \
--filters "Name=vpc-id,Values=$VPC_ID" \
--query 'NetworkAcls[].{ID:NetworkAclId,Default:IsDefault,Associations:Associations,Entries:Entries}' \
--output json
Die temporäre 90 muss fehlen. Die benutzerdefinierte ACL bleibt dem öffentlichen Anwendungssubnetz zugeordnet. Beide 100-Einträge treffen A TCP-Zielport 80; abschließende Sperren bleiben erhalten. Das private Subnetz behält seine Standard-ACL. Löschen oder ersetzen Sie keine bereitgestellte ACL, Subnetze, Anwendung, Gruppe, Gateway oder öffentliche Adresse.
Lesen Sie die ursprüngliche Gruppe, um ihre Regeln zu bestätigen:
aws ec2 describe-security-groups \
--group-ids "$GROUP_ID" \
--query 'SecurityGroups[].{Inbound:IpPermissions,Outbound:IpPermissionsEgress}' \
--output json
In AWS View scheitert eine neue Request application · client A wieder, weil ihr Rückport nicht mehr erlaubt ist. B und 8081 bleiben gesperrt. Ein API-Fehler oder ein nicht verfügbares Anwendungsnetz beweist kein Aufräumen: Das authentifizierte Inventar muss erfolgreich sein und der echte konfigurierte Weg diese Ergebnisse liefern.
Führen Sie die Abschlussprüfung dieses Schritts aus.
Zusammenfassung
Sie haben die ACL lokalisiert und einen fehlenden Antwortportbereich diagnostiziert. Die ausgehende Änderung stellte echtes HTTP für A wieder her; andere Quellen und Ports blieben gesperrt. Eine eingehende Sperre mit kleinerer Nummer zeigte die erste passende Regel. Ihr Entfernen stellte Zugriff wieder her.
Sie bewahrten Gruppe, Routen, Adressen und Zuordnungen, entfernten die temporäre Sperre und stellten den Ausgangszustand wieder her.
