Jeux de règles pour les équilibreurs de charge

Utilisez des jeux de règles composés d'actions appliquées au trafic du module d'écoute d'un équilibreur de charge.

Un jeu de règles est un jeu de règles nommé associé à un équilibreur de charge et appliqué à un ou plusieurs modules d'écoute sur ce dernier. Pour appliquer un jeu de règles à un module d'écoute, vous devez d'abord créer le jeu de règles qui contient les règles. Les règles sont des objets représentant des actions appliquées au trafic dans un module d'écoute d'équilibreur de charge. Le jeu de règles devient une partie de la configuration de l'équilibreur de charge. Vous pouvez indiquer le jeu de règles à utiliser lors de la création ou de la mise à jour d'un module d'écoute pour l'équilibreur de charge.

Vous pouvez inclure les types de règle suivants dans un jeu de règles :

Règles de contrôle d'accès, qui limitent l'accès aux ressources d'application en fonction de la source de la demande.

Règles de méthode d'accès, qui indiquent les méthodes HTTP autorisées.

Règles de redirection d'URL, qui acheminent les demandes HTTP entrantes vers une autre URL de destination.

Règles d'en-tête de demande et de réponse, qui ajoutent, modifient ou suppriment des en-têtes de demande ou de réponse HTTP.

R règles d'en-tête HTTP, qui précisent la taille de l'en-tête HTTP et les caractères qui sont autorisés dans les en-têtes.

Règles relatives au nombre maximal de connexions au module d'écoute, qui indiquent le nombre maximal de connexions IP pour un module d'écoute.

Note

Les jeux de règles s'appliquent uniquement aux modules d'écoute HTTP.

Appliquez un jeu de règles existant lorsque vous modifiez un module d'écoute. Vous pouvez appliquer le même jeu de règles à plusieurs modules d'écoute sur le même équilibreur de charge.

Les jeux de règles ne sont pas partagés entre les équilibreurs de charge. Pour utiliser le même jeu de règles sur un autre équilibreur de charge, vous devez créer un nouveau jeu de règles identique sous celui-ci.

Un jeu de règles peut contenir jusqu'à 20 règles. Vous pouvez associer un maximum de 50 règles à un équilibreur de charge.

Vous pouvez effectuer les tâches suivantes de gestion des jeux d'itinéraires de chemin d'accès :

Listez les jeux de règles d'un équilibreur de charge.

Créez un jeu de règles pour un équilibreur de charge.

Obtenir les détails d'un jeu de règles.

Modifiez les paramètres d'un jeu de règles.

Supprimer un jeu de règles d'un équilibreur de charge.

Pour plus d'informations sur la gestion des modules d'écoute d'équilibreur de charge, voir Modules d'écoute.

Règles de contrôle d'accès

Les règles de contrôle d'accès permettent l'accès aux ressources d'application en fonction des conditions de correspondance d'adresse IP ou d'intervalle d'adresses spécifiées par l'utilisateur. Si vous n'indiquez aucune règle de contrôle d'accès, la règle par défaut autorise tout le trafic. Si vous ajoutez des règles de contrôle d'accès, l'équilibreur de charge refuse tout trafic qui ne correspond pas aux règles.

Le service accepte uniquement les chaînes d'acheminement interdomaine (CIDR) (x.x.x.x/y ou x:x::x/y) sans classe pour la condition de correspondance.

Spécifiez 0.0.0.0/0 ou ::/0 pour une correspondance à tout le trafic entrant.

Note

Seules les régions du nuage gouvernemental des États-Unis autorisent les valeurs IPv6.

Règles de méthode d'accès

Les règles de méthode d'accès indiquent les méthodes HTTP autorisées pour le module d'écoute associé. L'équilibreur de charge ne transmet pas une demande non autorisée aux serveurs dorsaux et retourne une réponse 405 Method Not Allowed avec une liste des méthodes autorisées. Vous ne pouvez associer qu'une liste de méthodes autorisées à un module d'écoute particulier.

Par défaut, vous ne pouvez spécifier que les méthodes HTTP standard définies dans le registre des méthodes HTTP. La liste des méthodes HTTP est extensible. Si vous avez besoin de configurer des méthodes HTTP personnalisées, communiquez avec My Oracle Support pour demander que la restriction soit retirée de votre location. Votre application dorsale doit pouvoir traiter les méthodes indiquées.

La liste suivante présente les méthodes HTTP par défaut :

Méthodes HTTP par défaut
ACL BASELINE-CONTROL BIND
CHECKIN CHECKOUT CONNECT
COPY DELETE GET
HEAD LABEL LINK
LOCK MERGE MKACTIVITÉ
MKCALENDAR MKCOL MKREDIRECTREF
MKWORKSPACE MOVE OPTIONS
ORDERPATCH PATCH POST
PRI PROPFIND PROPPATCH
PUT REBIND REPORT
SEARCH TRACE UNBIND
UNCHECKOUT UNLINK UNLOCK
UPDATE UPDATEREDIRECTREF VERSION-CONTROL

Règles de redirection d'URL

Les règles de redirection d'URL indiquent comment acheminer des demandes HTTP entrantes vers une autre URL de destination. Les règles de redirection d'URL s'appliquent uniquement aux modules d'écoute HTTP. Vous configurez chaque règle de routage pour un module d'écoute particulier et un chemin spécifié. Un module d'écoute ne peut avoir qu'une seule règle de redirection pour un chemin d'URL entrant particulier.

Lorsque vous créez une règle de redirection d'URL, vous spécifiez la chaîne de chemin et la condition de correspondance que le service utilise pour évaluer une URL entrante pour la redirection. Vous définissez également l'URL de redirection et le code de réponse.

Évaluation de chaîne de chemin entrant

Vous spécifiez la chaîne de chemin ou le modèle à évaluer dans l'URL entrante. Par exemple :

/video

Vous pouvez également spécifier la condition de correspondance à appliquer lors de l'évaluation de l'URL entrante pour la redirection. Les types de correspondance disponibles sont les suivants :

  • FORCE_LONGEST_PREFIX_MATCH

    Le système recherche une chaîne de chemin de règle de redirection offrant la correspondance la plus longue et la meilleure avec le début du chemin de l'URL entrante.

  • EXACT_MATCH

    Le chemin de l'URL entrante doit correspondre exactement à la chaîne de chemin indiquée.

  • PREFIX_MATCH

    La partie de début du chemin de l'URL entrante doit correspondre exactement à la chaîne de chemin indiquée.

  • SUFFIX_MATCH

    La partie de fin du chemin de l'URL entrante doit correspondre exactement à la chaîne de chemin indiquée.

Note

La chaîne du chemin de l'URL entrante ne peut pas inclure d'interrogation.

Construction de l'URL de redirection

Vous définissez l'URL de redirection appliquée à la demande initiale. Les règles de redirection d'URL reconnaissent les composants d'URL suivants :


                        <protocol>://<host>:<port>/<path>?<query>
                    

Vous pouvez spécifier une chaîne littérale ou fournir un jeton pour tous les composants. Les jetons extraient les valeurs à partir de l'URL de la demande HTTP entrante. Les jetons sont sensibles à la casse. Par exemple, {host} est un jeton valide, mais {HOST} n'en est pas un.

  • Protocole

    Protocole HTTP à utiliser dans l'URL de redirection. Les valeurs valides sont HTTP et HTTPS.

    Le jeton {protocol} extrait le protocole à partir de l'URL de la demande HTTP entrante. C'est le seul jeton valide pour cette propriété.

  • Hôte

    Nom de domaine ou adresse IP valide à utiliser dans l'URL de redirection.

    Le jeton {host} extrait l'hôte à partir de l'URL de la demande HTTP entrante. Tous les jetons de redirection d'URL sont valides pour cette propriété. Vous pouvez utiliser un jeton plus d'une fois.

    Les accolades {} sont valides dans cette propriété uniquement pour encadrer les jetons.

  • Port

    Port de communication à utiliser dans l'URL de redirection. Les valeurs valides incluent des entiers de 1 à 65535.

    Le jeton {port} extrait le port à partir de l'URL de la demande HTTP entrante. C'est le seul jeton valide pour cette propriété.

  • Chemin

    Chemin de l'URL HTTP à utiliser dans l'URL de redirection. Pour ignorer le chemin de l'URL de redirection, réglez cette valeur à une chaîne vide.

    Le jeton {path} extrait la chaîne de chemin à partir de l'URL de la demande HTTP entrante. Tous les jetons de redirection d'URL sont valides pour cette propriété. Vous pouvez utiliser un jeton plus d'une fois.

    Si la chaîne de chemin ne commence pas par le jeton {path}, elle doit commencer par une barre oblique /.

  • Interrogation

    Chaîne d'interrogation à utiliser dans l'URL de redirection. Pour ignorer tous les paramètres d'interrogation entrants de l'URL de redirection, réglez cette valeur à une chaîne vide.

    Le jeton {query} extrait la chaîne d'interrogation à partir de l'URL de la demande HTTP entrante. Tous les jetons de redirection d'URL sont valides pour cette propriété. Vous pouvez utiliser un jeton plus d'une fois.

    Si la chaîne d'interrogation ne commence pas par le jeton {query}, elle doit commencer par un point d'interrogation?

    Vous pouvez spécifier plusieurs paramètres d'interrogation sous la forme d'une seule chaîne. Séparez chaque paramètre d'interrogation par une perluète &.

    Si la chaîne d'interrogation indiquée retourne une URL de redirection se terminant par ? ou &, le dernier caractère est tronqué. Par exemple, si l'URL entrante est http://host.com:8080/documents et que la valeur de propriété de l'interrogation est ?lang=en&{query}, l'URL de redirection est http://host.com:8080/documents?lang=en. Le système tronque la perluète finale & parce que l'URL entrante ne contient aucune valeur pour remplacer le jeton {query}.

Important

Si vous ne parvenez pas à spécifier une valeur pour au moins un champ de composant d'URL, cela peut entraîner une boucle de redirection.

Construction manuelle de l'URL de redirection

La console fournit des champs d'entrée de texte pour chaque composant de l'URL. Vous pouvez également spécifier manuellement l'URL de redirection complète.

Vous pouvez conserver les caractères littéraux d'un jeton lorsque vous spécifiez des valeurs pour le chemin et les propriétés d'interrogation de l'URL de redirection. Utilisez une barre oblique inverse \ comme caractère d'échappement pour les caractères \, { et }. Par exemple, si l'URL de la demande HTTP entrante est /video, la valeur de propriété du chemin /example{path}123\{path\} s'affiche dans l'URL de redirection construite en tant que /example/video123{path}.

Exemples de chemin et de chaîne d'interrogation :

  • /example/video/123 s'affiche comme /example/video/123 dans l'URL de redirection.
  • /example{path} s'affiche comme /example/video/123 dans l'URL de redirection lorsque /video/123 correspond au chemin dans l'URL de la demande HTTP entrante.
  • {path}/123 s'affiche comme /example/video/123 dans l'URL de redirection lorsque /example/video correspond au chemin dans l'URL de la demande HTTP entrante.
  • {path}123 s'affiche comme /example/video123 dans l'URL de redirection lorsque /example/video correspond au chemin dans l'URL de la demande HTTP entrante.
  • /{host}/123 s'affiche comme /example.com/123 dans l'URL de redirection lorsque example.com est le nom d'hôte dans l'URL de la demande HTTP entrante.
  • /{host}/{port} s'affiche comme /example.com/123 dans l'URL de redirection lorsque example.com est le nom d'hôte et 123, le port dans l'URL de la demande HTTP entrante.
  • /{query} s'affiche comme /lang=en dans l'URL de redirection lorsque l'interrogation est lang=en dans l'URL de la demande HTTP entrante.
  • lang=en&time_zone=PST s'affiche comme lang=en&time_zone=PST dans l'URL de redirection.
  • {query} s'affiche comme lang=en&time_zone=PST dans l'URL de redirection lorsque lang=en&time_zone=PST est la chaîne d'interrogation dans la demande HTTP entrante. Si la demande HTTP entrante ne comporte aucun paramètre d'interrogation, le jeton {query} s'affiche en tant que chaîne vide.
  • lang=en&{query}&time_zone=PST s'affiche comme lang=en&country=us&time_zone=PST dans l'URL de redirection lorsque country=us est la chaîne d'interrogation de la demande HTTP entrante. Si la demande HTTP entrante n'a aucun paramètre d'interrogation, cette valeur est rendue en tant que lang=en&time_zone=PST.
  • protocol={protocol}&hostname={host} s'affiche comme protocol=http&hostname=example.com dans l'URL de redirection lorsque le protocole est http et le nom d'hôte est example.com dans la demande HTTP entrante.
  • port={port}&hostname={host} s'affiche comme port=8080&hostname=example.com dans l'URL de redirection lorsque le port est 8080 et que le nom d'hôte est example.com dans l'URL de la demande HTTP entrante.

Code de réponse

Vous pouvez spécifier le code de statut HTTP à retourner lorsque la demande entrante est redirigée. Les codes de réponse valides pour la redirection à partir de la spécification HTTP standard sont :

  • 301 Moved Permanently
  • 302 Found
  • 303 See Other
  • 307 Temporary Redirect
  • 308 Permanent Redirect

La valeur par défaut est 302 Found.

Règles d'en-tête de demande et de réponse

Les règles d'en-tête de demande et de réponse ajoutent, modifient ou suppriment des en-têtes de demande ou de réponse HTTP. Ces règles peuvent vous aider à transmettre des métadonnées à vos serveurs dorsaux pour :

  • Identifier le module d'écoute qui a envoyé une demande.
  • Aviser un serveur dorsal de la terminaison SSL.

Exemples illustrant comment des jeux de règles peuvent vous aider à renforcer la sécurité d'un site :

  • Ajout d'en-têtes pour empêcher des domaines externes d'insérer des iframes dans votre site.
  • Suppression des en-têtes de débogage, tels que "Server", envoyés par les serveurs dorsaux. Cette action vous aide à masquer les détails de mise en oeuvre de votre serveur dorsal.
  • Ajout de l'en-tête "strict-transport-security" avec une valeur appropriée, aux réponses. Cet en-tête vous aide à garantir que l'accès à votre site se fait uniquement par HTTPS.
  • Ajout de l'en-tête "x-xss-protection" avec une valeur appropriée. Cet en-tête vous permet d'appliquer la protection contre les attaques par script intersites (XSS) intégrée dans les navigateurs modernes.
  • Ajout de l'en-tête "x-content-type" avec une valeur appropriée. Cet en-tête vous aide à empêcher les attaques basées sur le décalage du type de contenu.
Note

L'ajout ou la suppression de l'en-tête d'hôte intégré ou de l'un des en-têtes X-, tel que décrit sous En-têtes HTTP "X-" ne suppriment pas ou ne remplacent pas la valeur de l'en-tête. Ces actions peuvent plutôt ajouter des valeurs ou dupliquer l'en-tête.

Exemple : Aviser WebLogic que l'équilibreur de charge a mis fin à SSL

Vous pouvez configurer votre équilibreur de charge pour effectuer une terminaison SSL. Souvent, vos applications dorsales ont besoin d'être avisées de cette action. Par exemple, le traitement de transaction en ligne de commerce électronique WebLogic HTTPS recherche l'en-tête WL-Proxy-SSL pour confirmer qu'une demande a été transmise par SSL. Vous pouvez utiliser des jeux de règles pour ajouter cet en-tête dans le module d'écoute de l'équilibreur de charge.

Note

Pour des raisons de sécurité, WebLogic ignore cet en-tête sauf si vous cochez la case WebLogic Plugiciel activé dans la console d'administration de WebLogic.
  1. Créez un jeu de règles avec les paramètres suivants. Pour plus d'informations, voir Création d'un jeu de règles.
    • Sélectionnez l'option Ajouter un en-tête de demande dans la liste Action.
    • Entrez WL-Proxy-SSL comme nom d'en-tête.
    • Définissez la valeur de l'en-tête :
      • Si votre équilibreur de charge est configuré pour effectuer une terminaison SSL, réglez cette valeur à "Vrai".
      • Si le point de terminaison SSL se trouve sur le serveur Web où le plugiciel est exécuté, réglez cette valeur à "Faux".
  2. Créez un module d'écoute ou modifiez un module d'écoute existant, puis ajoutez le nouveau jeu de règles. Pour plus d'informations, voir Modules d'écoute.

Règles d'en-tête HTTP

Les règles d'en-tête HTTP indiquent la taille de l'en-tête HTTP et les caractères autorisés dans les en-têtes.

  • La règle d'en-tête HTTP Taille de tampon d'en-tête HTTP augmente la taille d'une mémoire tampon utilisée pour lire l'en-tête de la demande du client HTTP et la réponse du serveur dorsal, de 8 Ko par défaut à 64 Ko. Le tampon est utilisé pour le contrôle de dépassement de capacité. Chaque ligne d'en-tête de demande ou de réponse doit tenir dans cette mémoire tampon. Par conséquent, pour les applications qui utilisent de grandes lignes d'en-tête HTTP, ce paramètre doit être ajusté.
  • La règle d'en-tête HTTP Autoriser les caractères non valides dans l'en-tête HTTP permet d'inclure des chiffres, des tirets et des traits de soulignement dans les en-têtes HTTP.

Pour plus d'informations sur la mise en oeuvre des règles d'en-tête HTTP, voir Création d'un jeu de règles.

Règles concernant le nombre maximal de connexions au module d'écoute

La règle de connexion maximale du module d'écoute vous permet d'appliquer à la fois un nombre maximal uniforme de connexions du module d'écoute pour toutes les adresses IP et de spécifier des remplacements à cette valeur uniforme pour les adresses IP individuelles que vous identifiez.

  • Vous pouvez définir une valeur de nombre maximal de connexions par défaut qui s'applique à toutes les adresses IP pour lesquelles aucun nombre maximal spécifique n'est défini. Si vous ne définissez pas cette valeur maximale par défaut, il n'y a pas de limite au nombre de connexions qu'une adresse IP peut établir à un module d'écoute.
  • Vous pouvez également définir des valeurs maximales pour une ou plusieurs adresses IP qui remplacent la valeur de connexion maximale par défaut.

Pour plus d'informations sur la mise en oeuvre du nombre maximal de règles de connexion au module d'écoute, voir Création d'un jeu de règles.