Ensembles de règles pour les équilibreurs de charge
Utilisez des ensembles de règles composés d'actions appliquées au trafic du processus d'écoute d'un équilibreur de charge.
Un ensemble de règles est un ensemble de règles nommé associé à un équilibreur de charge et appliqué à des processus d'écoute de cet équilibreur. Pour appliquer un ensemble de règles à un processus d'écoute, créez tout d'abord l'ensemble contenant les règles. Les règles sont des objets représentant des actions appliquées au trafic au niveau d'un processus d'écoute d'équilibreur de charge. L'ensemble de règles est une partie de la configuration de l'équilibreur de charge. Vous pouvez indiquer l'ensemble de règles à utiliser lorsque vous créez ou mettez à jour un processus d'écoute pour l'équilibreur de charge.
Vous pouvez inclure les types de règle suivants dans un ensemble de règles :
Règles de contrôle d'accès, qui restreignent l'accès aux ressources d'application en fonction de la source de la demande.
Règles de méthode d'accès, qui spécifient les méthodes HTTP autorisées.
Règles de réacheminement 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 enlèvent des en-têtes de demande ou de réponse HTTP.
Règles d'en-tête HTTP, qui indiquent la taille de l'en-tête HTTP et les caractères autorisés dans ces derniers.
Nombre maximal de règles de connexion au processus d'écoute, qui indiquent le nombre maximal de connexions IP pour un processus d'écoute.
Les ensembles de règles s'appliquent uniquement aux processus d'audit HTTP.
Appliquez un ensemble de règles existant lorsque vous modifiez un processus d'écoute. Vous pouvez appliquer le même ensemble de règles à différents processus d'écoute sur le même équilibreur de charges.
Les ensembles de règles ne sont pas partagés entre les équilibreurs de charge. Pour utiliser le même ensemble de règles sur un autre équilibreur de charge, vous devez créer un ensemble de règles identique dans cet équilibreur de charge.
Un ensemble de règles peut contenir jusqu'à 20 règles. Vous pouvez associer jusqu'à 50 règles à un équilibreur de charge.
Vous pouvez effectuer les tâches de gestion d'ensemble de routages par chemin suivantes :
Répertoriez les ensembles de règles d'un équilibreur de charges.
Créez un ensemble de règles pour un équilibreur de charge.
Obtenir les détails d'un ensemble de règles.
Modifier les paramètres d'un ensemble de règles.
Supprimez un ensemble de règles d'un équilibreur de charge.
Pour plus d'informations sur la gestion des processus d'oreille d'équilibreur de charge, reportez-vous à Processus d'écoute.
Règles de contrôle d'accès
Les règles de contrôle d'accès permettent d'accéder aux ressources d'application en fonction des conditions de mise en correspondance de l'adresse IP ou de la plage d'adresses IP définies par l'utilisateur. Si vous ne spécifiez aucune règle de contrôle d'accès, la règle par défaut consiste à autoriser tout le trafic. Si vous ajoutez des règles de contrôle d'accès, l'équilibreur de charge refuse tout trafic ne correspondant pas aux règles.
Le service accepte uniquement les chaînes au format CIDR (x.x.x.x/y ou x:x::x/y
) pour la condition de mise en correspondance.
Indiquez 0.0.0.0/0
ou ::/0
pour correspondre à tout le trafic entrant.
Seuls les régions US Government Cloud autorisent les valeurs IPv6.
Règles de méthode d'accès
Les règles de méthode d'accès spécifient les méthodes HTTP autorisées au niveau du processus d'écoute associé. L'équilibreur de charge n'envoie pas de demande non autorisée aux serveurs back-end et renvoie une réponse 405 Method Not Allowed
avec la liste des méthodes autorisées. Vous pouvez associer qu'une seule liste de méthodes autorisées au processus d'écoute donné.
Par défaut, vous pouvez indiquer uniquement les méthodes HTTP standard définies dans le registre de méthodes HTTP. La liste des méthodes HTTP est extensible. Si vous devez configurer des méthodes HTTP personnalisées, contactez My Oracle Support afin d'enlever la restriction de votre location. L'application back-end doit pouvoir gérer les méthodes indiquées.
La liste suivante présente les méthodes HTTP par défaut :
ACL | BASELINE-CONTROL | BIND |
CHECKIN | CHECKOUT | CONNECT |
COPY | DELETE | GET |
HEAD | LABEL | LINK |
LOCK | MERGE | MKACTIVITY |
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 réacheminement d'URL
Les règles de réacheminement d'URL indiquent comment acheminer des demandes HTTP entrantes vers une autre URL de destination. Les règles de réacheminement d'URL s'appliquent uniquement aux processus d'écoute HTTP. Vous devez configurer chaque règle de réacheminement pour un processus d'écoute donné et un chemin spécifié. Un listener ne peut avoir qu'une seule règle de réacheminement pour un chemin d'URL entrant particulier.
Lorsque vous créez une règle de réacheminement d'URL, vous indiquez la chaîne de chemin et la condition de mise en correspondance utilisées par le service pour évaluer une URL entrante en vue d'un réacheminement. Vous pouvez également définir l'URL de réacheminement et le code de réponse.
Evaluation de la chaîne de chemin entrante
Indiquez la chaîne de chemin ou le modèle à évaluer dans l'URL entrante. Par exemple :
/video
Vous devez également indiquer la condition de mise en correspondance à appliquer lors de l'évaluation de l'URL entrante pour le réacheminement. Les types de correspondance disponibles sont les suivants :
- FORCE_LONGEST_PREFIX_MATCH
Le système recherche la chaîne contenant la correspondance la plus longue sur la première partie du chemin d'URL entrant.
- EXACT_MATCH
Le chemin d'URL entrant doit correspondre exactement à la chaîne de chemin indiquée.
- PREFIX_MATCH
La première partie du chemin d'URL entrant doit correspondre exactement à la chaîne de chemin spécifiée.
- SUFFIX_MATCH
La dernière partie du chemin d'URL entrant doit correspondre exactement à la chaîne de chemin indiquée.
La chaîne de chemin d'URL entrante ne peut pas inclure de requête.
Construction de l'URL de réacheminement
Vous devez définir l'URL de réacheminement à appliquer à la demande d'origine. Les règles de réacheminement 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 n'importe quel composant. Les jetons extraient des valeurs à partir de l'URL de la demande HTTP entrante. Les jetons distinguent les majuscules des minuscules. Par exemple, {host}
est un jeton valide, mais pas {HOST}
.
- Protocole
Protocole HTTP à utiliser dans l'URL de réacheminement. Les valeurs valides sont HTTP et HTTPS.
Le jeton
{protocol}
extrait le protocole à partir de l'URL de la demande HTTP entrante. Il s'agit du seul jeton valide pour cette propriété. - Hôte
Nom de domaine ou adresse IP valide à utiliser dans l'URL de réacheminement.
Le jeton
{host}
extrait l'hôte à partir de l'URL de la demande HTTP entrante. Tous les jetons de réacheminement URL sont valides pour cette propriété. Vous pouvez utiliser un jeton plusieurs fois.Les accolades {} ne sont valides dans cette propriété qu'autour des jetons.
- Port
Port de communication à utiliser dans l'URL de réacheminement. Les valeurs valides incluent les entiers compris entre 1 et 65535.
Le jeton
{port}
extrait le port à partir de l'URL de la demande HTTP entrante. Il s'agit du seul jeton valide pour cette propriété. - Chemin
Chemin d'URL HTTP à utiliser dans l'URL de réacheminement. Pour omettre le chemin de l'URL de réacheminement, définissez cette valeur sur 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 réacheminement URL sont valides pour cette propriété. Vous pouvez utiliser un jeton plusieurs fois.Si la chaîne de chemin ne commence pas par le jeton
{path}
, elle doit commencer par une virgule /. - Requête
Chaîne de requête à utiliser dans l'URL de réacheminement. Pour omettre tous les paramètres de requête entrants de l'URL de réacheminement, définissez cette valeur sur une chaîne vide.
Le jeton
{query}
extrait la chaîne de requête à partir de l'URL de la demande HTTP entrante. Tous les jetons de réacheminement URL sont valides pour cette propriété. Vous pouvez utiliser un jeton plusieurs fois.Si la chaîne de requête ne commence pas par le jeton
{query}
, elle doit commencer par un point d'interrogation ? .Vous pouvez indiquer différents paramètres de requête sous forme de chaîne unique. Séparez les paramètres de requête par une esperluette &.
Si la chaîne de requête indiquée génère une URL de réacheminement se terminant par ? ou par &, le dernier caractère est tronqué. Par exemple, si l'URL entrante est
http://host.com:8080/documents
et que la valeur de la propriété de requête est?lang=en&{query}
, l'URL de réacheminement esthttp://host.com:8080/documents?lang=en
. Le système tronque l'esperluette finale & car l'URL entrante ne comporte aucune valeur destinée à remplacer le jeton{query}
.
Si vous ne spécifiez pas de valeur dans au moins un champ d'élément de l'URL, cela peut entraîner une boucle de réacheminement.
Construction manuelle de l'URL de réacheminement
La console fournit des champs de saisie de texte pour chaque composant d'URL. Vous pouvez également indiquer manuellement l'URL de réacheminement complète.
Vous pouvez conserver les caractères littéraux d'un jeton lorsque vous indiquez des valeurs pour les propriétés de chemin et de requête de l'URL de réacheminement. 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é de chemin /example{path}123\{path\}
apparaît dans l'URL de réacheminement construite sous la forme /example/video123{path}
.
Voici quelques exemples de chaînes de chemin et de requête :
- /example/video/123 apparaît sous la forme
/example/video/123
dans l'URL de réacheminement. - /example{path} apparaît sous la forme
/example/video/123
dans l'URL de réacheminement lorsque/video/123
est le chemin dans l'URL de la demande HTTP entrante. - {path}/123 apparaît sous la forme
/example/video/123
dans l'URL de réacheminement lorsque/example/video
est le chemin dans l'URL de la demande HTTP entrante. - {path}123 apparaît sous la forme
/example/video123
dans l'URL de réacheminement lorsque/example/video
est le chemin dans l'URL de la demande HTTP entrante. - /{host}/123 apparaît sous la forme
/example.com/123
dans l'URL de réacheminement lorsqueexample.com
est le nom d'hôte dans l'URL de la demande HTTP entrante. - /{host}/{port} apparaît sous la forme
/example.com/123
dans l'URL de réacheminement lorsqueexample.com
est le nom d'hôte et que123
est le port dans l'URL de la demande HTTP entrante. - /{query} apparaît sous la forme
/lang=en
dans l'URL de réacheminement lorsque la requête estlang=en
dans l'URL de la demande HTTP entrante. - lang=en&time_zone=PST apparaît sous la forme
lang=en&time_zone=PST
dans l'URL de réacheminement. - {query} apparaît sous la forme
lang=en&time_zone=PST
dans l'URL de réacheminement lorsquelang=en&time_zone=PST
est la chaîne de requête de la demande HTTP entrante. Si la demande HTTP entrante ne possède aucun paramètre de requête, le jeton{query}
apparaît sous la forme d'une chaîne vide. - lang=en&{query}&time_zone=PST apparaît sous la forme
lang=en&country=us&time_zone=PST
dans l'URL de réacheminement lorsquecountry=us
est la chaîne de requête de la demande HTTP entrante. Si la demande HTTP entrante ne possède aucun paramètre de requête, cette valeur est affichée sous la formelang=en&time_zone=PST
. - protocol={protocol}&hostname={host} apparaît sous la forme
protocol=http&hostname=example.com
dans l'URL de réacheminement lorsque le protocole esthttp
et que le nom d'hôte estexample.com
dans la demande HTTP entrante. - port={port}&hostname={host} apparaît sous la forme
port=8080&hostname=example.com
dans l'URL de réacheminement lorsque le port est8080
et que le nom d'hôte estexample.com
dans l'URL de la demande HTTP entrante.
Code de réponse
Vous pouvez indiquer le code de statut HTTP à renvoyer lors du réacheminement de la requête. Les codes de réponse valides pour le réacheminement à partir de la spécification HTTP standard sont les suivants :
301 Déplacé définitivement
302 Trouvé
303 Voir autre
307 Réacheminement temporaire
308 Réacheminement permanent
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 enlèvent des en-têtes de demande ou de réponse HTTP. Ces règles peuvent vous aider à transmettre des métadonnées vers vos serveurs back-end pour effectuer les opérations suivantes :
- Identifier le processus d'écoute ayant envoyé une demande.
- Avertir un serveur back-end de la terminaison SSL.
Voici quelques exemples montrant comment les ensembles de règles peuvent vous aider à améliorer la sécurité de votre site :
- Ajout d'en-têtes afin d'éviter que des domaines externes n'utilisent la fonctionnalité iFrame sur votre site.
- Suppression des en-têtes de débogage, tels que "Server," envoyés par les serveurs back-end. Cette opération permet de masquer les détails d'implémentation du back-end.
- Ajout de l'en-tête "strict-transport-security", avec une valeur appropriée, aux réponses. Cet en-tête permet de garantir un accès au site via le protocole HTTPS uniquement.
- Ajout de l'en-tête "x-xss-protection", avec une valeur appropriée. Cet en-tête vous aide à mettre en oeuvre la protection XSS intégrée aux navigateurs modernes.
- Ajout de l'en-tête "x-content-type", avec une valeur appropriée. Cet en-tête vous aide à prévenir les attaques basées sur le changement du type de contenu.
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 dans En-têtes "X-" HTTP n'entraîne pas la suppression ou le remplacement de la valeur d'en-tête. En effet, ces actions peuvent entraîner l'ajout d'autres valeurs à la fin de l'en-tête ou sa duplication.
Exemple : envoi d'une notification à WebLogic indiquant que l'équilibreur de charge a mis fin à SSL
Vous pouvez configurer votre équilibreur de charge pour qu'il mette fin à SSL. Souvent, vos applications back-end doivent être averties 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 vérifier si la demande provient du protocole SSL. Vous pouvez utiliser des ensembles de règles pour ajouter cet en-tête au processus d'écoute de l'équilibreur de charge.
Pour des raisons de sécurité, WebLogic ne prend pas en considération cet En-tête, sauf si vous cochez la case Module d'extension WebLogic activé dans la console d'administration WebLogic.
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'un tampon utilisé pour lire l'en-tête de demande client HTTP et la réponse du serveur back-end de 8 ko à 64 ko par défaut. Le tampon est utilisé pour le contrôle de débordement. Chaque ligne d'en-tête de demande ou de réponse doit tenir dans ce tampon. Par conséquent, les applications utilisant des lignes d'en-tête HTTP volumineuses doivent régler ce paramètre.
- 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 traits d'union et des traits de soulignement dans les en-têtes HTTP.
Pour plus d'informations sur l'implémentation des règles d'en-tête HTTP, reportez-vous à Création d'un ensemble de règles.
Nombre maximal de règles de connexion au processus d'écoute
La règle de connexion maximale du processus d'écoute vous permet d'appliquer à la fois un nombre maximal uniforme de connexions de processus d'écoute pour toutes les adresses IP et d'indiquer 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, le nombre de connexions qu'une adresse IP peut établir à un processus d'écoute n'est pas limité.
- Vous pouvez également définir des valeurs maximales pour une ou plusieurs adresses IP qui remplacent la valeur de connexions maximales par défaut.
Pour plus d'informations sur l'implémentation du nombre maximal de règles de connexion de processus d'écoute, reportez-vous à Création d'un ensemble de règles.