Global Accelerator:Ajouter et gérer des règles de transfert

Types de règles

Chaque listener comporte deux types de règles de transfert :

• Règle de transfert par défaut : créée automatiquement lors de la création d'un listener et associée au groupe d'endpoints par défaut. Chaque listener possède exactement une règle par défaut. Sa priorité est fixe ; elle ne peut être ni modifiée ni supprimée.

• Règles de transfert personnalisées : créées après la configuration du listener. Un listener peut comporter plusieurs règles personnalisées dont vous pouvez ajuster la priorité.

Composants d'une règle

Chaque règle de transfert se compose de forwarding conditions et de forwarding actions. Les actions s'appliquent uniquement si la requête satisfait toutes les conditions de la règle.

Les types de conditions et d'actions disponibles dépendent du protocole du listener :

Logique des conditions

Comprendre la combinaison des conditions est essentiel pour concevoir des règles efficaces.

Au sein d'une même règle, toutes les conditions doivent correspondre (logique ET). Une requête n'est transférée que si elle satisfait à chaque condition de la règle.

Au sein d'une même condition, plusieurs valeurs utilisent la logique OU. Par exemple, une condition Host contenant deux noms de domaine correspond si le nom d'hôte de la requête est égal à l'un ou l'autre.

Le tableau suivant résume le comportement de chaque type de condition lorsqu'il est utilisé plusieurs fois dans la même règle :

Correspondance des requêtes

1. L'évaluation des requêtes suit les règles de transfert personnalisées par ordre de priorité décroissante. Un numéro de règle inférieur indique une priorité plus élevée.

   • Si la requête correspond à une règle personnalisée (c'est-à-dire qu'elle satisfait à toutes les conditions), les actions associées s'appliquent immédiatement.

   • En cas de non-correspondance, la requête est comparée à la règle suivante dans l'ordre de priorité.

2. Si aucune règle personnalisée ne correspond, la règle de transfert par défaut s'applique. La requête est alors transférée vers le groupe d'endpoints par défaut.

Si le listener possède plusieurs groupes d'endpoints par défaut, la règle par défaut répartit le trafic selon les paramètres de distribution définis. Pour plus de détails, consultez Répartir le trafic entre les groupes d'endpoints dans différents scénarios.

Host

Correspond au nom d'hôte dans la requête. Prend en charge les noms de domaine exacts, les noms de domaine génériques et les expressions régulières. Consultez Configurer les noms de domaine dans les conditions de transfert pour les règles de format.

• Une seule condition Host est autorisée par règle.

• Plusieurs noms de domaine au sein de la condition utilisent la logique OU.

Exemple : *.example.com

Path

Correspond au chemin URL dans la requête. Prend en charge les chemins exacts, les chemins génériques et les expressions régulières. Consultez Configurer les chemins dans les conditions de transfert pour les règles de format.

• Plusieurs conditions Path dans une même règle utilisent la logique OU.

• Plusieurs chemins au sein d'une même condition utilisent la logique OU.

Exemple : Si l'URL est www.example.com/test/test1?x=1&y=2, définissez le chemin sur /test/*.

HTTP Header

Correspond à une paire clé-valeur d'en-tête HTTP spécifique. Saisissez le nom de l'en-tête dans Key is et la valeur dans Value is.

• Plusieurs conditions HTTP Header dans une même règle utilisent la logique ET. Les clés doivent être uniques parmi les conditions.

• Plusieurs valeurs au sein d'une même condition utilisent la logique OU. Les valeurs d'en-tête HTTP au sein d'une même condition doivent être uniques.

Exemple : Clé user-agent, valeur *Mozilla/4.0*

HTTP Request Method

Correspond à la méthode de requête HTTP. Valeurs valides : HEAD, GET, POST, OPTIONS, PUT, PATCH, DELETE.

• Une seule condition HTTP Request Method est autorisée par règle.

• Plusieurs méthodes au sein de la condition utilisent la logique OU.

Cookie

Correspond aux paires clé-valeur des cookies.

• Plusieurs conditions Cookie dans une même règle utilisent la logique ET.

• Plusieurs paires clé-valeur au sein d'une même condition utilisent la logique OU.

Exemple : key:value

Source IP

Correspond aux adresses IP client ou aux blocs CIDR.

• Une seule condition Source IP est autorisée par règle.

• Plusieurs entrées au sein de la condition utilisent la logique OU.

Exemple d'adresse IP : 1.1.XX.XX/32. Exemple de bloc CIDR : 2.2.XX.XX/24

Query String

Correspond aux paires clé-valeur de la chaîne de requête URL.

• Plusieurs conditions Query String dans une même règle utilisent la logique ET.

• Plusieurs paires clé-valeur au sein d'une même condition utilisent la logique OU.

Exemple : Si l'URL est www.example.com/test/test1?x=1&y=2, définissez les paramètres sur x:1 ou y:2.

Forward to

Transfère les requêtes correspondantes vers le groupe d'endpoints spécifié.

La sélection du groupe d'endpoints dépend de votre mode de facturation :

Redirect to

Redirige les requêtes correspondantes vers une URL différente. Spécifiez le Protocol, le Status Code, le Host, le Port, le Path et la chaîne de Query. Les paramètres Protocol, Host, Port, Path et Query ne peuvent pas être tous vides ou utiliser leurs valeurs par défaut simultanément.

Pour les règles de configuration avancée du Path, consultez Configurations de chemin avancées pour les réécritures et les redirections.

Mirror traffic to

Envoie une copie du trafic des requêtes correspondantes vers le groupe d'endpoints spécifié, tandis que la requête originale continue vers la destination Forward to.

Contraintes :

• La duplication du trafic est déployée par phases. Contactez votre responsable de compte pour l'activer.

• Seules les instances GA en paiement à l'utilisation prennent en charge cette action.

• Doit être combinée avec une action Forward to. Placez Mirror traffic to avant Forward to.

• Les groupes d'endpoints pour Mirror traffic to et Forward to ne peuvent pas être identiques.

• Un seul groupe d'endpoints (par défaut ou virtuel) peut être sélectionné pour la duplication du trafic.

Return fixed response

Retourne une réponse HTTP statique au client. Spécifiez le Response Status Code, le Response Body Type et le Response Body.

Rewrite

Réécrit l'URL de la requête avant le transfert. Spécifiez le Host, le Path et la Query String pour l'URL réécrite. Cette action doit être combinée avec une action Forward to et placée avant celle-ci.

Pour les règles de configuration avancée du Path, consultez Configurations de chemin avancées pour les réécritures et les redirections.

Insert header

Insère ou écrase un en-tête HTTP dans la requête avant le transfert. Saisissez le nom de l'en-tête dans Key is et la valeur dans Value is.

Contraintes :

• Les clés doivent être uniques parmi les actions Insert header d'une même règle.

• Les clés de Insert header ne peuvent pas dupliquer les clés de Remove header dans la même règle.

• Seules les instances en paiement à l'utilisation prennent en charge l'insertion d'System-defined Request IDs dans les en-têtes.

Cette action doit être placée avant l'action Forward to.

Remove header

Supprime un en-tête HTTP de la requête avant le transfert. Saisissez le nom de l'en-tête à supprimer.

Contraintes :

• Les clés doivent être uniques parmi les actions Remove header d'une même règle.

• Les clés de Remove header ne peuvent pas dupliquer les clés de Insert header dans la même règle.

Cette action doit être placée avant l'action Forward to.

Drop (Block Traffic)

Abandonne la requête immédiatement sans la transférer vers un groupe d'endpoints.

Transférer des requêtes vers un groupe d'endpoints virtuel spécifique

Une application web dessert deux domaines — example.com et example.net — à partir de deux serveurs distincts. Les deux domaines sont accélérés via GA.

Configurez un listener HTTPS avec un groupe d'endpoints par défaut et liez-y un certificat par défaut. Les requêtes pour example.com sont transférées vers le groupe d'endpoints par défaut. Ajoutez ensuite un groupe d'endpoints virtuel, liez un certificat supplémentaire et créez une règle de transfert Host pour envoyer le trafic de example.net vers ce groupe d'endpoints virtuel.

La figure suivante illustre la configuration de la règle de transfert Host pour cet exemple.

Rediriger les requêtes HTTP vers HTTPS

Lorsqu'un site web migre de HTTP vers HTTPS, les favoris et liens existants utilisant HTTP cessent de fonctionner. Configurez une règle de transfert Redirect pour envoyer automatiquement les requêtes HTTP vers l'URL HTTPS équivalente. Par défaut, cette règle retourne un code d'état HTTP 301.

Dans cet exemple, les requêtes HTTP sur le port 80 sont redirigées vers HTTPS sur le port 443. La figure suivante montre la configuration de la règle de transfert Redirect.

Configurer le blocage du trafic basé sur le domaine

Un site web dessert du trafic via example.com et utilise un Content Delivery Network (CDN) comme service backend dans GA. Étant donné que les services CDN sont mutualisés et partagent des adresses IP, d'autres locataires du CDN pourraient résoudre différents domaines vers la même adresse IP accélérée et acheminer le trafic via votre instance GA, ce qui engendrerait des coûts inattendus et des risques potentiels de sécurité.

Pour éviter cela, configurez des règles de transfert qui autorisent uniquement les requêtes pour example.com et abandonnent toutes les autres. Dans cet exemple, les requêtes pour example.com sont transférées vers le groupe d'endpoints backend. Les requêtes pour tout autre domaine sont abandonnées via l'action Drop (Block Traffic).