Server Load Balancer:Access control

Pourquoi ma liste d'autorisation accepte-t-elle toutes les adresses IP ?

Cause : Le contrôle d'accès est désactivé sur l'écouteur, ou l'ACL associée est vide (une ACL vide autorise tout le trafic).

Solution : Accédez à l'onglet Listener de votre instance CLB. Vérifiez que la colonne ACL de l'écouteur cible affiche Enabled et confirmez que l'ACL associée contient des entrées IP.

Pourquoi ma liste de blocage ne bloque-t-elle pas les adresses IP ?

Cause : Lorsque les requêtes transitent par un proxy (CDN ou WAF), CLB voit l'adresse IP de retour du proxy plutôt que l'adresse IP réelle du client, ce qui empêche les règles de la liste de blocage de correspondre.

Solution : Configurez la liste de blocage au niveau du proxy (CDN ou WAF). Si les clients peuvent contourner le proxy, ajoutez une liste d'autorisation sur CLB qui n'autorise que les plages d'adresses IP de retour du proxy.

Pourquoi les règles allow/deny de Nginx sont-elles inefficaces avec un écouteur de couche 7 ?

Cause : Les écouteurs de couche 7 de CLB transfèrent le trafic depuis des adresses IP privées situées dans la plage 100.64.0.0/10. Les règles allow/deny de Nginx correspondent à l'adresse IP source, elles ne peuvent donc pas filtrer selon l'adresse IP réelle du client.

Solution :

• (Recommandé) Utilisez le contrôle d'accès de CLB pour configurer directement une liste d'autorisation ou de blocage sur l'instance.

• Dans Nginx, extrayez l'adresse IP réelle du client à partir de l'en-tête X-Forwarded-For et configurez les règles allow/deny en conséquence. Obtain the real client IP on a backend server through a CLB Layer 7 listener.

Pourquoi les groupes de sécurité ECS ne peuvent-ils pas bloquer le trafic CLB ?

Cause : CLB utilise la plage 100.64.0.0/10 pour communiquer avec les instances ECS backend. Par conception, les règles entrantes des groupes de sécurité ECS ne restreignent pas le trafic provenant de cette plage.

Solution : Configurez une ACL CLB pour bloquer les requêtes par adresse IP client avant qu'elles n'atteignent les serveurs backend.

Que se passe-t-il lorsqu'une requête est bloquée ?

Description : CLB supprime les requêtes bloquées sans renvoyer de réponse. Le client rencontre un délai d'expiration de connexion.

Les listes d'autorisation protègent-elles contre les attaques DDoS ?

Description : Non. Le trafic DDoS consomme la bande passante de l'instance avant d'atteindre la couche de contrôle d'accès. Une attaque sévère peut déclencher un blackholing.

Recommandation : Utilisez Anti-DDoS.

Pourquoi le contrôle d'accès CLB (liste de blocage/liste d'autorisation) ne prend-il pas effet ?

Description : Un groupe de politiques ACL peut être attaché à un écouteur alors que le commutateur de contrôle d'accès reste désactivé : la simple configuration du groupe de politiques n'active pas le contrôle d'accès. De plus, les règles de port Cloud Firewall, la protection Anti-DDoS Origin ou les proxies multicouches masquant l'adresse IP réelle du client peuvent chacun empêcher indépendamment le bon fonctionnement du contrôle d'accès. Suivez les étapes ci-dessous par ordre de priorité.

Étape 1 : Vérifiez que le contrôle d'accès est activé. Accédez à l'onglet Listener de votre instance CLB. Dans la colonne ACL, vérifiez que le statut de l'écouteur indique Enabled. Un groupe de politiques ACL peut exister sur l'écouteur alors que le commutateur de contrôle d'accès est toujours désactivé. Si le commutateur est désactivé, cliquez sur Enable, sélectionnez Whitelist: Allows Specified IP Addresses to Access the SLB Instance ou Blacklist: Forbids Specified IP Addresses to Access the SLB Instance comme type de contrôle d'accès, associez un groupe de politiques ACL, puis cliquez sur Save.

Étape 2 : Vérifiez les règles de port Cloud Firewall. Si Cloud Firewall est activé sur votre compte, connectez-vous à la console Cloud Firewall et confirmez que le port de l'écouteur CLB est autorisé dans la politique de contrôle d'accès réseau. Cloud Firewall peut bloquer indépendamment le trafic sur un port, même lorsque le contrôle d'accès CLB est correctement activé.

Étape 3 : Vérifiez les paramètres Anti-DDoS Origin. Si votre instance CLB est précédée par Anti-DDoS, les règles de protection au niveau d'Anti-DDoS peuvent remplacer les entrées de la liste de blocage côté CLB. Dans ce cas, configurez les règles de liste de blocage et d'autorisation sur l'instance Anti-DDoS plutôt que sur CLB.

Étape 4 : Identifiez l'adresse IP réelle du client. Lorsque les requêtes transitent par plusieurs couches de proxy, CLB ne voit que l'adresse IP du proxy amont, et non l'adresse IP réelle du client, ce qui peut empêcher les règles de contrôle d'accès de correspondre. Pour localiser l'adresse IP réelle du client : désactivez temporairement le contrôle d'accès CLB, consultez les journaux de votre serveur backend ou de votre application pour identifier l'adresse source réelle, ajoutez-la à l'ACL, puis réactivez le contrôle d'accès.