Paramètres globaux pour le profil de batterie HTTP #

Le profil HTTP gère la commutation de contenu au niveau de la couche application du modèle OSI pour les protocoles HTTP et HTTPS. Nous avons conçu le profil pour répartir intelligemment le trafic Web entrant sur plusieurs ressources principales en analysant le contenu des demandes entrantes et en prenant des décisions de routage en fonction de paramètres spécifiques tels que l'URL, les cookies, les en-têtes et les informations de session. Avec ces informations, nous pouvons diriger le trafic vers les pools de serveurs (de services) appropriés.

Dans la partie supérieure droite, nous avons 2 indicateurs. Action boutons et Statut.
Boîte carrée : Lorsque vous cliquez dessus, la ferme LSLB s'arrête.
Bouton Actualiser: Lorsque vous cliquez dessus, la ferme redémarre.
Bouton Play: Si la ferme est éteinte ou inactive, elle démarrera lorsque vous cliquerez dessus.

Chacune des couleurs décrites ci-dessous représente le Statut d'un donné Ferme:
Vert: Signifie que la ferme est UP et tous les backends fonctionnent. Cela peut également signifier qu'une redirection est configurée.
Rouge: Signifie que la ferme est BAS ou il n'est pas fonctionnel.
Noir: Indique une CRITIQUE dommage. Se produit généralement lorsqu'une batterie de serveurs est UP mais qu'il n'y a pas de backend disponible, ou qu'elle peut être en mode maintenance.
Bleu: S'affiche lorsqu'il y a un PROBLÈME. La batterie de serveurs peut être en cours d'exécution, mais lorsqu'au moins un backend est en panne.
Orange: Représente Entretien. S'affiche lorsque la batterie de serveurs est en cours d'exécution mais qu'au moins un backend est en mode maintenance.

Ces codes de couleur sont les mêmes dans toute l'interface utilisateur graphique. Trouvez une explication concise à leur sujet dans le Section Ferme LSLB.

Dans le profil des batteries HTTP (S), l'en-tête HTTP X-Forwarded-For est renseigné par défaut avec l'adresse IP du client.

Comme un proxy inverse, chaque ferme HTTP(S) (ou service virtuel) gère plusieurs services. Par conséquent, une paire IP virtuelle HTTP et port peut gérer plusieurs services Web à charge équilibrée. Par conséquent, il y a une section appelée service au sein de la ferme HTTP qui offre la flexibilité de l'hôte virtuel et permet la création de listes de backends pour chaque service.

Chaque service HTTP(S) utilise expressions régulières (pour l'hôte virtuel et le modèle d'URL) dans PCRE pour rechercher des modèles spécifiques dans les en-têtes HTTP des connexions entrantes. Si le modèle correspond dans les deux hôte virtuel et Modèle d'URL , les backends de ce service particulier traiteront ces connexions entrantes.

Configuration de base #

Voici les paramètres de base du profil de batterie HTTP/S.

Nom. C'est un nom qui identifie facilement une ferme. Pour changer le nom d'une ferme donnée, vous devez d'abord l'arrêter. Assurez-vous qu'un nouveau nom n'est pas déjà utilisé.

IP virtuel et port. Il s'agit des adresses IP virtuelles et des paires de ports à partir desquelles la batterie écoutera les connexions entrantes. La nouvelle combinaison d'adresse IP et de port doit être inutilisée et disponible avant d'être configurée.

Auditeur. Ce champ spécifie le protocole de couche 7 pour effectuer la commutation de contenu.

• HTTP. Le service virtuel ne recevra que du contenu HTTP brut.
• HTTPS. Le service virtuel recevra le contenu HTTP sécurisé, gérera les poignées de main SSL, gérera les configurations de chiffrement sécurisé, les certificats SSL (wildcard ou SNI), etc., pour effectuer le déchargement SSL. Cela soulagera les vrais serveurs d'applications de ces lourdes tâches.

Paramètres HTTPS #

Paramètres HTTPS Vous trouverez ci-dessous.

Désactiver SSLV2, Désactiver SSLV3, Désactiver TLSV1, Désactiver TLSV1.1, Désactiver TLSV1.2. Chacun de ces boutons bascule active ou désactive la version SSL ou TLS associée. La désactivation de l'un des protocoles n'est pas recommandée car ses chiffrements associés seront également désactivés.

chiffrements. Cette section est l'endroit où nous construisons des listes de chiffrements que nous utilisons pour renforcer une connexion SSL. Avant qu'un client et un serveur ne commencent à échanger des informations protégées par le protocole TLS, ils doivent échanger ou convenir en toute sécurité d'une clé de chiffrement et d'un chiffrement à utiliser lors du chiffrement des données.

Pour configurer un chiffrement à utiliser, sélectionnez l'une des options suivantes.

• Tous. Avec cette commande sélectionnée, la ferme HTTP(S) à l'écoute gérera toutes les suites de chiffrement disponibles. Ce sont les paramètres par défauts.
• Haute sécurité. Cette commande active les chiffrements suivants :

  kEECDH+ECDSA+AES128:kEECDH+ECDSA+AES256:kEECDH+AES128:kEECDH+AES256:kEDH+AES128:kEDH+AES256:DES-CBC3-SHA:+SHA:!aNULL:!eNULL:!LOW:!kECDH:!DSS:!MD5:!EXP:!PSK:!SRP:!CAMELLIA:!SEED

  L'activation de cette option offre une sécurité suffisamment forte pour passer avec un A+ grade en SSL Labs .

• Sécurité personnalisée. Cette commande vous permet de personnaliser vos propres chiffrements via le Chiffrements personnalisés champ.
• Chiffres personnalisés. Cette commande vous permet de personnaliser des chiffrements spécifiques à autoriser ou à interdire lors de l'établissement d'une connexion SSL. Il doit s'agir d'une chaîne au même format que dans Chiffres OpenSSL . Cette commande s'affichera si Sécurité personnalisée est réglé.
• Déchargement SSL. Cette option permet de décharger les chiffrements AES via le matériel si le processeur le permet. Cela permettra d'optimiser les performances de la tâche de cryptage/déchiffrement SSL.

Certificats disponibles. Il s'agit des certificats SSL disponibles installés sur l'appareil. Pour activer chacun d'eux, sélectionnez le certificat et cliquez sur le bouton fléché ou faites-le simplement glisser et déposez-le de la case Disponible à la case Activé. Vous pouvez également activer/désactiver plusieurs certificats ou même tous.

Certificats activés. Dans cette liste, vous allez gérer les certificats actuellement utilisés par la ferme. Vous pouvez les déplacer vers le haut ou vers le bas avec les doubles flèches haut/bas ou même les désactiver tous. Tenir compte de l'ordre des certificats. Si vous configurez un certificat générique avant un certificat hôte, le caractère générique sera utilisé en premier.

paramètres avancés #

Réécrire les en-têtes d'emplacement. Si activé, la ferme est obligée de modifier le Lieu et Content-location en-têtes en réponse aux clients. S'ils ont la valeur du backend lui-même ou du VIP mais avec un protocole différent, la réponse sera modifiée pour afficher l'hôte virtuel dans la requête. Si le bouton bascule, activé et comparer les backends est activé, seule l'adresse IP principale sera comparée. Ceci est essentiel pour rediriger une demande vers un écouteur HTTPS sur le même serveur que l'écouteur HTTP. Si ce champ est configuré dans la section service, cette directive sera ignorée pour ce service.

Verbes HTTP acceptés. Ce champ indique les méthodes HTTP qui seront utilisées pour valider les requêtes client HTTP. Si la demande du client n'est pas autorisée, une erreur sera affichée au client. Chaque verbe a des niveaux inférieurs supplémentaires de verbes.

• Requête HTTP standard. Requêtes HTTP standard (GET, POST, HEAD).
• + requête HTTP étendue. requêtes HTTP étendues (PUT, DELETE).
• + options HTTP verbe. requêtes HTTP étendues (PUT, DELETE).
• + verbes WebDAV standard. verbes WebDAV standard (VERROUILLER, DÉVERROUILLER, PROPFIND, PROPPATCH, RECHERCHER, MKCOL, DÉPLACER, COPIER, OPTIONS, TRACE, MKACTIVITÉ, DÉPART, FUSION, RAPPORT).
• + Verbes WebDAV des extensions MS. Extensions MS WebDAV verbes (SUBSCRIBE, UNSUBSCRIBE, NOTIFYER, BPROPFIND, BPROPPATCH, POLL, BMOVE, BCOPY, BDELETE, CONNECT).
• + Verbes d'extensions MS RPC. Verbes d'extensions MS RPC (RPC_IN_DATA, RPC_OUT_DATA).

Ignorer 100 Continuer. Si coché, le 100 Continuer la propriété sera désactivée. Selon le protocole HTTP 1.1, lorsque cet en-tête est envoyé, les données du formulaire ne sont pas envoyées avec la requête initiale. Au lieu de cela, cet en-tête est envoyé au backend du serveur Web qui répond par 100 (Continuer). Cela signifie que le serveur a reçu des en-têtes de requête et que le client doit procéder à l'envoi du corps de la requête (dans le cas d'une requête pour laquelle un corps doit être envoyé; par exemple, une requête POST). Si le corps de la requête est volumineux, l'envoyer à un serveur lorsqu'une requête a déjà été rejetée sur la base d'en-têtes inappropriés est inefficace. Pour qu'un serveur vérifie si la demande peut être acceptée en se basant uniquement sur les en-têtes de la demande, un client doit envoyer Attendez-vous: 100-continue comme en-tête dans sa demande initiale et vérifier si un code d'état 100 Continue est reçu en réponse avant de continuer (ou si la réception de l'attente 417 a échoué et ne pas continuer).

Journaux. Activez ou désactivez les journaux de trafic de la batterie de serveurs pour déboguer et analyser ce qui passe par l'équilibreur de charge.

Délai de connexion au backend. Cette valeur indique le temps que la batterie devra attendre pour une connexion au backend en secondes. Habituellement, ce sera le temps d'attente d'ouverture du socket. Par défaut, cette valeur sera fixée à 20 secondes.

Fréquence de vérification des backends ressuscités. C'est la fréquence à laquelle l'équilibreur de charge attendra pour vérifier si un backend est accessible et pour sortir un serveur réel sur liste noire s'il est en place. La ferme vérifiera périodiquement le backend une fois que le serveur réel est marqué comme étant en panne, qu'il y ait ou non une nouvelle connexion client. Par défaut, cette valeur sera fixée à 10 secondes.

Délai de réponse du backend. Cette valeur indique le temps que la batterie devra attendre une réponse des backends en secondes. Par défaut, cette valeur sera fixée à 45 secondes.

Délai d'attente de la demande du client. Cette valeur indique le temps que la batterie devra attendre la demande d'un client. Une fois ce délai d'attente atteint sans obtenir de données du client, la connexion sera interrompue. Par défaut, cette valeur sera fixée à 30 secondes.

Messages d'erreur HTTP #

Messages d'erreur personnalisés. Le service de ferme affichera un message personnalisé sur votre site lorsqu'une erreur de code Web est détectée à partir des serveurs réels. Une page HTML personnalisée s'affichera pour les codes d'erreur 414, 500, 501 et 503.

• 414 : URI de requête trop long. Il s'agit du message d'erreur du profil HTTP/S si l'URI atteint le nombre maximum de caractères autorisés. Si vous recevez cette erreur, raccourcissez la longueur de l'URL.
• 500 : Erreur interne du serveur. Ceci est le message d'erreur par le profil HTTP/S si le backend rencontre une commande inattendue
• 501 : Non implémenté. Il s'agit du message d'erreur du profil HTTP/S si le verbe de requête n'est pas géré ou connu par le proxy ou le backend.
• 503 Service Indisponible. Il s'agit du message d'erreur du profil HTTP/S si le proxy ne trouve pas de backend disponible pour la requête. Cela peut se produire lorsque tous les backends ou serveurs sont arrêtés, ou parce que l'expression régulière de la requête ne correspond à aucun service configuré.
• WAF 403 : Interdit. Il s'agit du message d'erreur du profil HTTP/S si le WAF est activé et que le moteur WAF rejette la requête.

En-têtes #

Dans cette section, nous pouvons ajouter, modifier ou supprimer globalement les en-têtes de requête et de réponse, en appliquant des actions à tous les services configurés. Si un en-tête est configuré dans la section service, cette configuration sera ignorée.

Les actions à utiliser dans cette section incluent :

Créer une règle. Une règle d'en-tête globale sera créée.
Supprimer . Une règle d'en-tête globale sera supprimée.

Cette section nous permet d'ajouter, de modifier ou de créer En-tête demandes et réponses comme indiqué dans l'image ci-dessous.

Type.

• Demande : supprimer l'en-tête. Modèle d'en-tête qui sera supprimé des requêtes HTTP du client.
• Demande : modifier l'en-tête. Modifiez l'en-tête des requêtes HTTP du client.
• Demande : ajouter un en-tête. L'en-tête qui sera ajouté aux requêtes HTTP du client.
• Réponse : supprimer l'en-tête. Modèle d'en-tête qui sera supprimé de la réponse HTTP Backend.
• Réponse : modifier l'en-tête. Modifiez l'en-tête de la réponse HTTP Backend.
• Réponse : ajouter un en-tête. L'en-tête qui sera ajouté à la réponse HTTP Backend.

Paramètres de services #

Les services au sein d'une ferme LSLB avec un profil HTTP fournissent des capacités de commutation de contenu pour les services virtuels Web afin de fournir plusieurs services et applications Web via le même IP virtuel et PORT. Cela aide à unifier les applications web via un seul domaine, gérer les hôtes virtuels, gérer les URL, configurer les redirections, configurer la persistance et les backends par service. Chaque service au sein d'une batterie de serveurs LSLB possède diverses propriétés, vérifications de l'état, persistance, gestion des en-têtes et une liste principale. Des expressions régulières peuvent être utilisées pour faire correspondre des conditions qui spécifieront le service à utiliser par requête.

Chaque condition de correspondance de service sera vérifiée par le cœur du profil de batterie HTTP en mode prioritaire (qui peut être modifié si nécessaire). Si aucun service ne correspond, le noyau de la ferme renverra une erreur (erreur HTTP 503). Pour cette raison, des définitions spécifiques de services multiples sont autorisées. Si les champs URL et Hôte ne sont pas définis, toutes les requêtes correspondront. Les conditions du service HTTP seront déterminées par un hôte virtuel et/ou un modèle d'URL.

Premièrement, créer et ajouter au moins un serveur principal à un service est une nécessité. Une fois le nouveau service appliqué, les services HTTP seront évalués de haut en bas dans l'ordre de la liste. Le premier service à correspondre dans le champ Hôte et/ou URL traitera la demande. Ces conditions de service sont déterminées par des modèles d'URL ou d'hôte.

Les conditions de service à respecter sont :

hôte virtuel. Cette fonctionnalité vous permet de définir une condition basée sur le nom de domaine en utilisant la même adresse IP virtuelle et le même port au sein d'une ferme HTTP. Si vous souhaitez supprimer cette condition, vous pouvez laisser le champ vide. Les expressions régulières au format PCRE sont prises en charge dans ce champ.

Modèle d'URL. L'objectif de ce champ est d'identifier un service Web en fonction du chemin d'URL demandé par le client. L'URL sera évaluée par rapport à un modèle désigné, garantissant que sa syntaxe est correcte. Si vous souhaitez ignorer cette condition, vous pouvez laisser le champ vide. Les expressions régulières au format PCRE sont prises en charge dans ce champ, ce qui permet une correspondance de modèle avancée.

Le hôte virtuel et Modèle d'URL les valeurs sont des expressions régulières. Si laissé vide, n'importe quelle valeur correspondra. Les deux champs doivent correspondre ou il passera au service suivant. Il est recommandé d'en utiliser au moins un, servant de valeur par défaut s'il n'y a pas de correspondance détectée en bas.

Réécrire les en-têtes d'emplacement. Si activé, le service est obligé de modifier le Lieu et Content-location en-têtes en réponse aux clients. S'ils ont la valeur du backend lui-même ou du VIP (mais avec un protocole différent), la réponse sera modifiée pour afficher l'hôte virtuel dans la requête. Si le bouton bascule activé et comparer les backends est activé, seule l'adresse IP principale est comparée. Ceci est essentiel lors de la redirection des requêtes vers un écouteur HTTPS sur le même serveur que l'écouteur HTTP. Lorsque l'option Activer et comparer les backends est sélectionnée, un indicateur appelé Activer le chemin pour les en-têtes d'emplacement de réécriture sera disponible. Activez ce drapeau si vous travaillez avec Réécrire les URL. Cette valeur vous obligera à vérifier les réponses URL et remplacera la réponse par l'original si une règle est configurée dans Réécrire les URL. Si ce champ est activé, il remplacera la même directive dans la section globale.

Réorienter #

Si l'option de redirection du service est activée, les serveurs principaux ne peuvent pas être utilisés car toutes les requêtes seront envoyées à l'URL spécifiée.

Type de redirection. Il existe deux types de redirection : Réglage par défaut et Ajouter. Avec le Réglage par défaut type, l'URL est considérée comme un hôte absolu et un chemin vers lequel rediriger. Avec le Ajouter type, le chemin de la demande d'origine sera ajouté à l'hôte et au chemin que vous avez spécifié.

URL de redirection. Ce paramètre contrôle où le client sera redirigé après une réponse à une demande. La demande du client est répondue automatiquement en redirigeant vers une nouvelle URL. Si vous configurez une valeur de redirection, NE configurez PAS les backends dans cette prestation. Si la hôte virtuel et de la Modèle d'URL correspondance, l'appliance enverra un message HTTP En-tête d'emplacement réponse au client pour être redirigé vers l'URL configurée.

Code de redirection. Plusieurs codes HTTP de redirection peuvent être utilisés : 301 (Moved Permanently), 302 (Moved Temporarily) ou 307 (Temporary Redirect).

Persistence #

Persistence. Ce paramètre définit comment le service HTTP va gérer la session client et quelle connexion HTTP doit être contrôlée pour maintenir des sessions client sécurisées. Lorsqu'un type de session de persistance est sélectionné, sa durée de vie TTL (secondes) s'affiche.

• Pas de persistance. Le service de la ferme ne contrôlera pas les sessions client. Les requêtes HTTP ou HTTPS seront livrées à de vrais serveurs.
• IP: adresse du client. L'adresse IP du client sera utilisée pour garder les sessions client ouvertes via les vrais serveurs.
• BASIC: authentification de base. L'en-tête d'authentification de base HTTP sera utilisé pour contrôler les sessions client. Par exemple, lorsqu'une page Web demande une authentification de base au client, un en-tête HTTP contiendra une chaîne comme celle-ci :

  		HTTP/1.1 401 Autorisation requise Serveur : HTTPd/1.0 Date : samedi 27 novembre 2011 10:18:15 GMT
  		WWW-Authentification : Basic realm="Secure Area"
  		Type de contenu : texte/HTML Longueur du contenu : 31
  

  Ensuite, le client répond avec l'en-tête:

                  GET /private/index.html Hôte HTTP/1.1 : localhost
  		Autorisation : Basique QWxhZGRpbjpvcGVuIHNlc2FtZQ==
  

  Cette chaîne d'authentification de base est utilisée comme identifiant pour la session afin d'identifier la session client.

• PARM : un paramètre URI. Une autre façon d'identifier une session client consiste à utiliser un paramètre URI séparé d'un point-virgule utilisé comme identifiant de session utilisateur. Dans l'exemple http://www.example.com/private.php;EFD4Y7 le paramètre sera utilisé comme identifiant de session.
• URL: un paramètre de requête. Lorsque l'ID de session est envoyé via un paramètre GET avec l'URL, ce paramètre indique que le nom associé à l'ID de session client sera possible. Par exemple, une demande client comme http://www.example.com/index.php?sid=3a5ebc944f41daa6f849f730f1 doit être configuré avec le paramètre Identifiant de session de persistance (valeur sid dans cet exemple) et la durée de vie de la session de persistance (TTL)
• BISCUIT: . Vous pourrez sélectionner une variable de cookie HTTP à lire à partir des en-têtes HTTP et l'utiliser pour maintenir les sessions client pendant un temps donné. Le nom de cookie configuré dans le identifiant de session de persistance est créé par un programmeur et intégré dans une page Web pour identifier la session client, par exemple :

                  GET /spec.html Hôte HTTP/1.1 : www.example.org
                  Cookie : sessionidexample=75HRSd4356SDBfrte
  

  De plus, la session de persistance Time To Life (TTL) doit être configurée. Cette valeur gère le temps gagné par l'équilibreur de charge lorsque le client et le backend sont inactifs.

• HEADER : un en-tête de requête. Un champ personnalisé d'en-tête HTTP peut être utilisé pour identifier la session client. La durée de vie de la session de persistance et l'identifiant de session de persistance doivent être configurés. Par exemple:

                 GET /index.html Hôte HTTP/1.1 : www.example.org
                 X-session : 75HRSd4356SDBfrte
  

Cookies #

Cookie insert. S'il est défini, l'équilibreur de charge créera un gâteau dans chaque réponse avec la clé appropriée du backend. Même si la table de session est vidée ou si les sessions sont désactivées, le backend approprié sera choisi. Cette fonctionnalité évite de modifier le code réel du serveur pour créer un cookie de session.

Le Nom Cookie Nom d'un cookie qui sera créé et ajouté à la demande client/réponse backend. La Chemin des cookies est l'URI ou le chemin relatif où le nouveau cookie sera créé. Pour l'ensemble du domaine, le caractère doit être défini. Domaine du cookie est le domaine où le cookie va être créé. Finalement, Cookie TTL est le nombre de secondes pendant lesquelles le cookie sera conservé en mémoire entre le client et le backend. Ce champ doit être supérieur à 0. Et ce temps est lié au temps sans aucune activité. Après avoir lu les secondes indiquées sans aucune activité, la session de persistance sera supprimée.

Farmguardian #

Les fermes HTTP fournissent une vérification de l'état de base et native du backend, mais la configuration Farmguardian est recommandée pour des vérifications de l'état heuristiques plus intelligentes du backend afin de garantir que l'application est saine.

Certaines vérifications de l'état avancées ou personnalisées peuvent être attribuées à ce service à partir des vérifications Farmguardian déjà créées.

Pour plus d'informations sur Farmguardian, allez à Surveillance >> Farmguardian .

Notez qu'après avoir sélectionné Farmguardian, il sera automatiquement appliqué à la ferme.

Les backends HTTPS. Cette case à cocher indique à la ferme que les serveurs backend définis dans le service courant utilisent le protocole HTTPS donc les données seront chiffrées avant d'être envoyées.

Backends #

En ce qui concerne la Backends, le profil HTTP de la ferme permet de configurer les propriétés suivantes : Tous les backends doivent être IPv4 ou IPv6, et avec la même version IP que la Farm VIP.

ACTIONS. Utilisez les actions suivantes pour gérer les backends :
Pour les moteurs déjà créés:

• Activer la maintenance. Utilisez cette action si le backend a été précédemment désactivé. Placer un serveur réel en mode maintenance signifie qu'aucune nouvelle connexion ne sera redirigée vers celui-ci. Il existe deux méthodes pour activer le mode maintenance :
  • Mode vidange. Conserve les connexions établies et la persistance si activé, mais n'admet pas de nouvelles connexions.
  • Mode de coupe. Supprime toutes les connexions actives contre le backend
• Désactiver la maintenance. Utilisez cette action lorsque le backend est en mode maintenance. Activez à nouveau les nouvelles connexions au serveur réel après avoir désactivé le mode de maintenance.
• Supprimer . Supprimer les configurations d'un service virtuel sélectionné. L'alias ne sera pas supprimé s'il y en a un.

ALIAS. Alias ​​de base, si un alias a été sélectionné.
IP. L'adresse IP d'un backend donné.
PORT. Le numéro de port du serveur réel actuel.
TIMEOUT. Le temps qu'un backend met pour répondre. Cette valeur remplace le paramètre du délai d'expiration global de la connexion au backend, mais elle est limitée à la batterie sélectionnée.
POIDS. La valeur de pondération pour le serveur réel actuel. Plus de poids indique plus de connexions livrées au backend actuel. Par défaut, une valeur de poids de 1 sera définie. La plage de valeurs disponible est de 1 à 9.
STATUT. Les valeurs possibles sont :

• Up. La ferme est en cours d'exécution et le backend est prêt à recevoir des connexions.
• Vers le bas. La ferme est en cours d'exécution et le service a détecté que le backend ne fonctionne pas
• Entretien. Le backend est marqué comme n'étant pas prêt à recevoir des connexions par l'administrateur, cette option est utile pour les tâches de maintenance du backend
• Indéfini. L'état du backend n'a pas été vérifié.

PRIORITÉ. La valeur de priorité pour le serveur réel actuel. Les valeurs inférieures ont plus de priorité. La valeur de priorité de service par défaut est 1. Lorsqu'un backend échoue, la priorité de service est augmentée de 1. Lorsque le backend est à nouveau actif, la valeur de priorité de service est diminuée de 1. Les backends actifs contiennent des valeurs de priorité inférieures ou égales à la priorité de service .
LIMITE DE CONNEXION. Le nombre maximal de connexions simultanées que le backend gérera. Si cette valeur est atteinte, les nouvelles connexions au backend seront bloquées et le client recevra une erreur HTTP 503.

Ajouter un formulaire backend:

Grâce à la Action bouton de menu, les actions suivantes sont disponibles pour un ou plusieurs backends sélectionnés :
Ajouter le backend. Cette commande ouvre le formulaire de création du backend.
Les actions citées ci-dessus : Activer la maintenance (Vidanger et Cut/Taille mode), Désactiver la maintenance et Supprimer .

Réécrire les URL #

Il vérifie un modèle pour obtenir des chaînes à partir d'URL et les remplacer. Plusieurs configurations peuvent être ajoutées. Tous seront appliqués séquentiellement à l'URL entrante à moins que le dernier indicateur ne soit défini, ce qui terminera la phase de réécriture de l'URL et les autres modèles d'URL de réécriture ne seront pas évalués.

Dans cette section, la demande d'URL est analysée par le moteur proxy HTTP, si la demande d'URL correspond au Patron de Couture puis la demande d'URL est envoyée au client avec le remplacer expression régulière configurée. Lorsque la réponse est reçue par l'équilibreur de charge du backend, la modification de l'URL réelle sera effectuée juste au cas où l'en-tête d'emplacement de réécriture est activé pour le service avec la valeur Activer le chemin pour les en-têtes d'emplacement de réécriture.

Par exemple, si Pattern est configuré avec la valeur /média/(.+)$ et remplacer par la valeur /svc1/$1, la requête client https://vhost.domain.com/media/console sera envoyée au backend avec la valeur https://vhost.domain.com/svc1/console

Règles IPDS pour les batteries HTTP #

Cette section vous permet d'activer les règles IPDS. La liste présente différents types de protection et une zone de sélection pour les activer. Pour plus d'informations, veuillez vous rendre au IPDS >> Règles des listes noires, IPDS >> Règles DoS, IPDS >> Règles RBL or IPDS >> Règles WAF documentation spécifique.

Pour chacun des quatre types de règles IPDS, Liste noire, DoS, WAF et RBL, il existe deux tableaux, Disponible et Activé. Il y a aussi une icône de chaîne. Sous le tableau Disponible, vous verrez que toutes les règles disponibles sont du même type et peuvent être appliquées à une ferme donnée. Concernant la table activée, vous verrez que les règles appliquées à la ferme sélectionnée sont du même type. Il y a aussi un symbole d'état pour chaque règle qui indique si la règle est arrêtée (couleur rouge) couleur ou s'il est en cours d'exécution (couleur verte).

Chaque règle est accessible en cliquant sur l'icône d'édition qui vous permettra de modifier les paramètres de la règle ou même de démarrer/arrêter la règle. Vous ne pourrez pas créer de nouvelle règle dans cette vue de batterie. Modifiez-le via le IPDS .

Ajoutez une règle en cliquant sur la règle souhaitée, puis en cliquant sur la flèche simple droite. Ou, vous pouvez en sélectionner plusieurs en appuyant simultanément sur la touche Maj et en sélectionnant les règles que vous souhaitez ajouter. Vous cliquerez ensuite sur la flèche simple droite. Vous pouvez également ajouter toutes les listes noires disponibles en cliquant sur la double flèche droite.

Pour supprimer une ou plusieurs règles, sélectionnez-les et cliquez sur la flèche gauche ou cliquez sur la double flèche pour toutes les supprimer.

Initiatives connexes #

Regardez notre vidéo pour savoir à quel point il est simple de configurer une redirection HTTPS avec RELIANOID.