LabEx
Rejoindre

Diagnostiquer le chemin retour d’une ACL réseau

AWSBeginner
Pratiquer maintenant

Introduction

Une application publique de livraison dispose d’une route Internet, d’une adresse publique et d’une autorisation HTTP dans son groupe de sécurité, mais le client A ne peut pas la lire. L’ACL de son sous-réseau autorise le port de destination de la requête et bloque le port retour du client. Vous diagnostiquerez et réparerez ce chemin, observerez la priorité des règles, puis restaurerez la configuration initiale fournie.

Terminez d’abord Connect Privately to S3 with a VPC Endpoint. Cet environnement neuf fournit sa propre application, ses sous-réseaux public et privé, route publique, adresse, groupe et ACL personnalisée. La CLI est configurée. Préservez ces ressources et le réseau de référence. Ne modifiez que la règle étudiée et supprimez votre refus temporaire pendant le nettoyage. L’état final reproduit volontairement la panne initiale ; il ne supprime pas l’application fournie.

Liens avec les certifications

Cette pratique élémentaire concerne les sujets d’examen suivants.

Examiner la frontière du sous-réseau de l’application

Localisez l’application et comparez route, groupe de sécurité et ACL avant toute modification.

Utilisez Terminal et ouvrez AWS View à côté. L’adresse privée de l’application publique est 10.20.1.10. Le client A est 198.51.100.10 ; B est 198.51.100.20. Le groupe fourni n’autorise que A sur TCP 80. Le port 8081 n’est pas autorisé.

cd /home/labex/project

Sélectionnez le VPC par son étiquette Name. Les filtres sélectionnent les ressources, la requête extrait l’ID et $(...) le conserve :

VPC_ID=$(aws ec2 describe-vpcs \
  --filters Name=tag:Name,Values=application-network \
  --query 'Vpcs[0].VpcId' \
  --output text)

Enregistrez le sous-réseau public et son interface fournie :

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)

Lisez l’adresse privée, l’association publique et le groupe attaché :

aws ec2 describe-network-interfaces \
  --network-interface-ids "$ENI_ID" \
  --query 'NetworkInterfaces[].{Private:PrivateIpAddress,Public:Association.PublicIp,Groups:Groups}' \
  --output json

Lisez la table associée à ce sous-réseau :

aws ec2 describe-route-tables \
  --filters "Name=association.subnet-id,Values=$SUBNET_ID" \
  --query 'RouteTables[].{Routes:Routes,Associations:Associations}' \
  --output json

L’adresse publique est associée et une route active 0.0.0.0/0 cible une passerelle Internet. Enregistrez et consultez le groupe :

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

L’entrée autorise TCP 80 depuis 198.51.100.10/32, avec l’autorisation de sortie par défaut fournie. Préservez ces règles.

Une ACL réseau contrôle le trafic traversant la frontière d’un sous-réseau. Chaque sous-réseau possède une ACL ; une ACL peut en servir plusieurs. Contrairement au groupe avec état, l’ACL est sans état : autoriser une requête n’autorise pas automatiquement sa réponse. Sélectionnez l’ACL associée :

ACL_ID=$(aws ec2 describe-network-acls \
  --filters "Name=association.subnet-id,Values=$SUBNET_ID" \
  --query 'NetworkAcls[0].NetworkAclId' \
  --output text)

Lisez son identité, ses associations et ses entrées distinctes d’entrée et sortie :

aws ec2 describe-network-acls \
  --network-acl-ids "$ACL_ID" \
  --query 'NetworkAcls[].{ID:NetworkAclId,Default:IsDefault,Associations:Associations,Entries:Entries}' \
  --output json

Il s’agit de l’ACL personnalisée application-acl, pas de celle par défaut. Sa règle 100 autorise A sur TCP destination 80 dans les deux sens. Egress: false indique l’entrée, true la sortie. Le protocole 6 est TCP. Le trafic sans correspondance atteint le refus final, * dans AWS View et 32767 dans CLI.

Dans AWS View, cliquez sur Request application · client A : Connection failed malgré la route et l’autorisation du groupe. Request application · client B et Request port 8081 échouent aussi. Gardez ce Terminal ouvert pour conserver les ID.

Réparer la règle du port retour du client

Remplacez le port de sortie incorrect en conservant l’adresse restreinte du client.

La requête HTTP va du port éphémère choisi par le client au port serveur 80. La réponse va du 80 au port client. Dans chaque sens, l’ACL compare le port de destination du paquet. Une sortie destination 80 n’autorise pas cette réponse.

La plage éphémère dépend du client initiateur. Pour cet exercice, autorisez la plage courante 1024–65535 uniquement vers A, 198.51.100.10/32. Ce n’est pas une valeur universelle par défaut des systèmes. Remplacez la sortie 100 ; --egress choisit la sortie et --port-range sa plage de destination :

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

Un remplacement réussi ne produit aucune sortie. Lisez les entrées :

aws ec2 describe-network-acls \
  --network-acl-ids "$ACL_ID" \
  --query 'NetworkAcls[].Entries' \
  --output json

L’entrée 100 autorise toujours TCP 80 depuis A. La sortie 100 autorise désormais les destinations 1024–65535 vers ce même client. Les refus par défaut et l’association restent inchangés.

Dans AWS View, cliquez de nouveau sur Request application · client A. La nouvelle requête retourne Application online, source 198.51.100.10, destination 80. Request application · client B et Request port 8081 échouent toujours. Requête et réponse traversent l’ACL sans étendre les autorisations entrantes du groupe ou de l’ACL aux autres clients.

L’ACL réparée admet le client A et conserve les refus

Exemple : entrée 100 autorise TCP 80 depuis A ; sortie 100 autorise les destinations de réponse 1024–65535 vers A. Le refus final apparaît dans les deux sens et la requête réelle retourne Application online. Les ID peuvent différer.

Observer un refus de numéro inférieur

Insérez volontairement un refus correspondant avant l’autorisation entrante pour observer l’ordre.

Les règles s’évaluent du plus petit numéro au plus grand dans chaque sens. La première correspondance décide ; les suivantes sont ignorées. Ajoutez l’entrée temporaire 90 refusant A sur TCP 80. --ingress choisit explicitement l’entrée ; créer 90 n’écrase pas 100 :

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

Lisez les entrées :

aws ec2 describe-network-acls \
  --network-acl-ids "$ACL_ID" \
  --query 'NetworkAcls[].Entries' \
  --output json

Le refus entrant 90 correspond avant l’autorisation 100. La sortie 100 autorise encore les ports retour et le groupe autorise HTTP depuis A. Aucun ne neutralise le refus antérieur de l’ACL.

Lorsque AWS View affiche l’entrée 90, cliquez sur Request application · client A. La nouvelle requête échoue ; B et 8081 restent bloqués. Un ancien succès est historique : relancez après toute modification. Conservez 90 pour la vérification de cette étape, puis supprimez-la à la suivante.

Supprimer le refus temporaire et retester l’accès

Supprimez uniquement le refus antérieur et vérifiez que le retour réparé fonctionne encore.

Supprimez l’entrée 90. La direction compte : les numéros d’entrée et sortie sont indépendants :

aws ec2 delete-network-acl-entry --network-acl-id "$ACL_ID" --rule-number 90 --ingress

Relisez les entrées :

aws ec2 describe-network-acls \
  --network-acl-ids "$ACL_ID" \
  --query 'NetworkAcls[].Entries' \
  --output json

La règle 90 est absente. L’entrée 100 autorise A TCP 80, la sortie 100 ses ports retour et le reste reste refusé. Préservez l’association d’origine, le groupe, la route et l’adresse publique.

Dans AWS View, une nouvelle Request application · client A retourne Application online. Request application · client B et Request port 8081 échouent. Le groupe avec état autorise les réponses aux requêtes admises, mais l’ACL sans état exige les deux sens ; retirer son refus antérieur rétablit cette frontière indépendante.

Restaurer la configuration ACL initiale fournie

Annulez votre modification des ports retour et assurez-vous qu’aucun refus temporaire ne subsiste, sans supprimer les ressources.

Restaurez la sortie 100 au port de destination 80 fourni. Ce nettoyage reproduit volontairement la panne initiale ; cette règle n’est pas recommandée pour un retour HTTP fonctionnel :

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

Lisez l’inventaire complet des ACL du VPC et leurs associations. Les étiquettes supprimables ne suffisent pas comme preuve de nettoyage :

aws ec2 describe-network-acls \
  --filters "Name=vpc-id,Values=$VPC_ID" \
  --query 'NetworkAcls[].{ID:NetworkAclId,Default:IsDefault,Associations:Associations,Entries:Entries}' \
  --output json

La règle temporaire 90 doit être absente. L’ACL personnalisée reste associée au sous-réseau public. Les deux règles 100 correspondent à A TCP destination 80, avec les refus finaux intacts. Le sous-réseau privé conserve son ACL par défaut. Ne supprimez ni ne remplacez ACL, sous-réseaux, application, groupe, passerelle ou adresse fournis.

Consultez le groupe d’origine pour confirmer la conservation de ses règles :

aws ec2 describe-security-groups \
  --group-ids "$GROUP_ID" \
  --query 'SecurityGroups[].{Inbound:IpPermissions,Outbound:IpPermissionsEgress}' \
  --output json

Dans AWS View, une nouvelle Request application · client A échoue car son port retour n’est plus admis. B et 8081 restent bloqués. Un échec API ou un réseau indisponible ne prouve pas le nettoyage : l’inventaire authentifié doit réussir et le chemin réellement configuré doit produire ces résultats.

Exécutez la vérification de cette étape.

Résumé

Vous avez localisé l’ACL et diagnostiqué une plage de réponse manquante. Remplacer la sortie a restauré le véritable HTTP pour A tout en bloquant les autres sources et ports. Un refus entrant de numéro inférieur a démontré la première correspondance ; sa suppression a restauré l’accès.

Vous avez préservé groupe, routes, adresses et associations, supprimé le refus temporaire et restauré la configuration d’origine.

Connexe AWS Cours
Les bases d’AWS pour débutants

Les bases d’AWS pour débutants

aws
AWS S3 pour débutants

AWS S3 pour débutants

aws
AWS IAM pour débutants

AWS IAM pour débutants

aws