Authentification

La page Bibliothèque > Authentification vous permet de configurer des serveurs d'authentification et de créer des règles d'authentification avec des options pour Basic ou Forms côté client et NTLM ou BASIC côté serveur.

Configuration de l'authentification - un flux de travail

Veuillez effectuer les étapes suivantes au minimum pour appliquer l'authentification à votre service.

1. Créer un serveur d'authentification.

2. Créez une règle d'authentification qui utilise un serveur d'authentification.

3. Créez une règle flightPATH qui utilise une règle d'authentification.

4. Appliquer la règle flightPATH à un service

Serveurs d'authentification

Pour mettre en place une méthode d'authentification fonctionnelle, nous devons d'abord configurer un serveur d'authentification.

· Cliquez sur le bouton Ajouter un serveur.

· Cette action produira une ligne vierge prête à être complétée.

Option	Description
Nom	Donnez un nom à votre serveur à des fins d'identification - ce nom est utilisé dans les règles.
Description	Ajouter une description
Méthode d'authentification	Choisissez une méthode d'authentification LDAP - LDAP de base avec des noms d'utilisateur et des mots de passe envoyés en texte clair au serveur LDAP. LDAP-MD5 - LDAP de base avec le nom d'utilisateur en clair et le mot de passe haché en MD5 pour une sécurité accrue. LDAPS - LDAP sur SSL. Envoie le mot de passe en clair dans un tunnel crypté entre l'ADC et le serveur LDAP. LDAPS-MD5 - LDAP sur SSL. Le mot de passe est haché en MD5 pour plus de sécurité dans un tunnel crypté entre l'ADC et le serveur LDAP.
Domaine	Ajoutez le nom de domaine du serveur LDAP.
Adresse du serveur	Ajoutez l'adresse IP ou le nom d'hôte du serveur d'authentification. LDAP - Adresse IPv4 ou nom d'hôte. LDAP-MD5 - nom d'hôte uniquement (l'adresse IPv4 ne fonctionne pas) LDAPS - adresse IPv4 ou nom d'hôte. LDAPS-MD5 - nom d'hôte uniquement (l'adresse IPv4 ne fonctionne pas).
Port	Utilisez le port 389 pour LDAP et le port 636 pour LDAPS par défaut. Il n'est pas nécessaire d'ajouter le numéro de port pour LDAP et LDAPS. Lorsque d'autres méthodes seront disponibles, vous pourrez les configurer ici.
Conditions de recherche	Les conditions de recherche doivent être conformes à la norme RFC 4515. Exemple : (MemberOf=CN=Phone- VPN,CN=Users,DC=mycompany,DC=local).
Base de recherche	Cette valeur est le point de départ de la recherche dans la base de données LDAP. Exemple dc=mycompany,dc=local
Format de connexion	Utilisez le format de connexion dont vous avez besoin. Nom d'utilisateur - avec ce format choisi, vous ne devez saisir que le nom d'utilisateur. Toutes les informations d'utilisateur et de domaine saisies par l'utilisateur sont supprimées et les informations de domaine du serveur sont utilisées. Nom d'utilisateur et domaine - L'utilisateur doit saisir la syntaxe complète du domaine et du nom d'utilisateur. Exemple : mycompany\gchristie OR someone@mycompany. Les informations relatives au domaine saisies au niveau du serveur sont ignorées. Blanc - le CDA accepte tout ce que l'utilisateur saisit et l'envoie au serveur d'authentification. Cette option est utilisée lorsque vous utilisez MD5.
Phrase de passe	Cette option n'est pas utilisée dans cette version.
Temps mort	Non utilisé dans cette version

Règles d'authentification

L'étape suivante consiste à créer les règles d'authentification à utiliser avec la définition du serveur.

Champ	Description
Nom	Ajoutez un nom approprié pour votre règle d'authentification.
Description	Ajoutez une description appropriée.
Domaine de la racine	Ce champ doit être laissé vide, sauf si vous avez besoin d'une authentification unique pour les sous-domaines.
Serveur d'authentification	Il s'agit d'une boîte déroulante contenant les serveurs que vous avez configurés.
Authentification du client :	Choisissez la valeur appropriée à vos besoins : Basic (401) - Cette méthode utilise la méthode d'authentification standard 401. Formulaires - ce formulaire présente le formulaire par défaut du CDA à l'utilisateur. Dans le formulaire, vous pouvez ajouter un message. Vous pouvez sélectionner un formulaire que vous avez téléchargé en utilisant la section ci-dessous.
Authentification du serveur	Choisissez la valeur appropriée. Aucun - si votre serveur n'a pas d'authentification existante, sélectionnez ce paramètre. Ce paramètre signifie que vous pouvez ajouter des capacités d'authentification à un serveur qui n'en avait aucune auparavant. Basic - si l'authentification de base (401) est activée sur votre serveur, sélectionnez BASIC. NTLM - si l'authentification NTLM est activée sur votre serveur, sélectionnez NTLM.
Formulaire	Choisissez la valeur appropriée Défaut - En sélectionnant cette option, le CDA utilisera sa forme intégrée. Personnalisé - vous pouvez ajouter un formulaire que vous avez conçu et le sélectionner ici.
Message	Ajoutez un message personnel au formulaire.
Délai d'attente	Ajoutez un délai d'attente à la règle, après lequel l'utilisateur devra s'authentifier à nouveau. Notez que le paramètre Timeout n'est valable que pour l'authentification basée sur les formulaires.

Ouverture de session unique

Si vous souhaitez fournir une authentification unique aux utilisateurs, remplissez la colonne Domaine racine avec votre domaine. Dans cet exemple, nous avons utilisé edgenexus.io. Nous pouvons maintenant avoir plusieurs services qui utiliseront edgenexus.io comme domaine racine, et vous ne devrez vous connecter qu'une seule fois. Si nous considérons les services suivants :

· Sharepoint.monentreprise.com

· usercentral. mycompany.com

· appstore. mycompany.com

Ces services peuvent résider sur un seul VIP ou être répartis sur 3 VIP. Un utilisateur accédant à usercentral. mycompany.com pour la première fois se verra présenter un formulaire lui demandant de se connecter en fonction de la règle d'authentification utilisée. Le même utilisateur peut ensuite se connecter à appstore. mycompany.com et sera authentifié automatiquement par le CDA. Vous pouvez définir le délai d'attente, qui forcera l'authentification une fois cette période d'inactivité atteinte.

Formulaires

Cette section vous permettra de télécharger un formulaire personnalisé.

Comment créer votre formulaire personnalisé

Bien que le formulaire de base fourni par le CDA soit suffisant dans la plupart des cas, il y aura des occasions où les entreprises souhaiteront présenter leur propre identité à l'utilisateur. Vous pouvez créer votre propre formulaire personnalisé que les utilisateurs devront remplir dans de tels cas. Ce formulaire doit être au format HTM ou HTML.

Option	Description
Nom	nom du formulaire = loginform action = %JNURL Méthode = POST
Nom d'utilisateur :	Syntaxe : name = "JNUSER"
Mot de passe :	name="JNPASS"
Message facultatif1 :	%JNMESSAGE
Message facultatif2 :	%JNAUTHMESSAGE%
Images	Si vous souhaitez ajouter une image, veuillez l'ajouter en ligne en utilisant le codage Base64.

Exemple de code html d'un formulaire très basique et simple

<HTML>

<HEAD>

<TITLE>SAMPLE AUTH FORM</TITLE>

</HEAD>

<BODY>

%JNMESSAGE%<br>

PASS : <input type="password" name="JNPASS" size="20" value=""></br>

</form>

</BODY>

</HTML>

Ajout d'un formulaire personnalisé

Une fois que vous avez créé un formulaire personnalisé, vous pouvez l'ajouter en utilisant la section Formulaires.

1. Choisissez un nom pour votre formulaire

2. Recherchez localement votre formulaire

3. Cliquez sur Télécharger

Prévisualisation de votre formulaire personnalisé

Pour visualiser le formulaire personnalisé que vous venez de télécharger, vous le sélectionnez et cliquez sur Aperçu. Vous pouvez également utiliser cette section pour supprimer les formulaires qui ne sont plus nécessaires.

Cache

L'ADC est capable de mettre en cache des données dans sa mémoire interne et de vider périodiquement ce cache vers le stockage interne de l'ADC. Les paramètres qui gèrent cette fonctionnalité sont fournis dans cette section.

Paramètres globaux du cache

Taille maximale du cache (Mo)

Cette valeur détermine la RAM maximale que le cache peut consommer. Le cache de l'ADC est un cache en mémoire qui est aussi périodiquement vidé sur le support de stockage pour maintenir la persistance du cache après les redémarrages, les redémarrages et les opérations d'arrêt. Cette fonctionnalité signifie que la taille maximale du cache doit s'inscrire dans l'empreinte mémoire de l'appareil (plutôt que dans l'espace disque) et ne doit pas dépasser la moitié de la mémoire disponible.

Taille souhaitée du cache (Mo)

Cette valeur indique la RAM optimale à laquelle le cache sera réduit. Alors que la taille maximale de l'antémémoire représente la limite supérieure absolue de l'antémémoire, la taille souhaitée de l'antémémoire est conçue comme la taille optimale que l'antémémoire doit essayer d'atteindre à chaque fois qu'une vérification automatique ou manuelle de la taille de l'antémémoire est effectuée. L'écart entre la taille maximale et la taille souhaitée de l'antémémoire existe pour tenir compte de l'arrivée et du chevauchement de nouveaux contenus entre les vérifications périodiques de la taille de l'antémémoire pour éliminer les contenus périmés. Une fois encore, il peut être plus efficace d'accepter la valeur par défaut (30 Mo) et de vérifier périodiquement la taille du cache sous "Moniteur -> Statistiques" pour un dimensionnement approprié.

Temps de mise en cache par défaut (J/HH:MM)

La valeur saisie ici représente la durée de vie du contenu sans valeur d'expiration explicite. La durée de mise en cache par défaut est la période pendant laquelle est stocké le contenu sans directive "no-store" ou délai d'expiration explicite dans l'en-tête de trafic.

L'entrée du champ prend la forme "J/HH:MM" - ainsi, une entrée de "1/01:01" (par défaut, 1/00:00) signifie que l'ADC conservera le contenu pendant un jour, "01:00" pendant une heure et "00:01" pendant une minute.

Codes de réponse HTTP cachables

Les réponses HTTP constituent l'un des ensembles de données mis en cache. Les codes de réponse HTTP qui sont mis en cache sont :

· 200 - Réponse standard pour les demandes HTTP réussies

· 203 - Les en-têtes ne sont pas définitifs mais proviennent d'une copie locale ou d'une tierce partie.

· 301 - Une nouvelle URL permanente a été attribuée à la ressource demandée.

· 304 - Non modifié depuis la dernière demande et la copie en cache locale doit être utilisée à la place.

· 410 - La ressource n'est plus disponible sur le serveur et aucune adresse de transfert n'est connue.

Ce champ doit être édité avec précaution, car les codes de réponse cachables les plus courants sont déjà répertoriés.

Temps de vérification du cache (J/HH:MM)

Ce paramètre détermine l'intervalle de temps entre les opérations d'ajustement du cache.

Compte de remplissage du cache

Ce paramètre est une fonction d'aide qui permet de remplir le cache lorsqu'un certain nombre de 304 a été détecté.

Appliquer une règle de mise en cache

Cette section vous permet d'appliquer une règle de cache à un domaine :

· Ajouter le domaine manuellement avec le bouton Ajouter des enregistrements. Vous devez utiliser un nom de domaine entièrement qualifié ou une adresse IP en notation décimale en pointillés. Exemple www. mycompany.com ou 192.168.3.1:80

· Cliquez sur la flèche déroulante et choisissez votre domaine dans la liste.

· La liste sera remplie tant que le trafic aura transité par un service virtuel et qu'une stratégie de mise en cache aura été appliquée au service virtuel.

· Choisissez votre règle de mise en cache en double-cliquant sur la colonne Base de règles de mise en cache et en la sélectionnant dans la liste.

Créer une règle de mise en cache

Cette section vous permet de créer plusieurs règles de mise en cache différentes qui peuvent ensuite être appliquées à un domaine :

· Cliquez sur Ajouter des enregistrements et donnez un nom et une description à votre règle.

· Vous pouvez soit taper vos conditions manuellement, soit utiliser la fonction "Ajouter une condition".

Pour ajouter une condition à l'aide de la base de règles de sélection :

· Choisissez Inclure ou Exclure

· Choisir toutes les images JPEG

· Cliquez sur le symbole + Ajouter

· Vous verrez que 'include *.jpg' a été ajouté aux conditions.

· Vous pouvez ajouter d'autres conditions. Si vous choisissez de le faire manuellement, vous devez ajouter chaque condition sur une NOUVELLE ligne. Veuillez noter que vos règles s'afficheront sur la même ligne jusqu'à ce que vous cliquiez dans la case Conditions, puis elles s'afficheront sur une ligne distincte.

flightPATH

flightPATH est la technologie de gestion du trafic intégrée à l'ADC. flightPATH vous permet d'inspecter le trafic HTTP et HTTPS en temps réel et d'effectuer des actions en fonction des conditions.

Les règles flightPATH doivent être appliquées à un VIP lorsque des objets IP sont utilisés dans les règles.

Une règle de trajectoire de vol est constituée de quatre éléments :

1. Détails, où vous définissez le nom du flightPATH et le service auquel il est rattaché.

2. Condition(s) pouvant être définie(s) et entraînant le déclenchement de la règle.

3. Évaluation qui permet de définir des variables qui peuvent être utilisées dans les actions

4. Les actions qui sont utilisées pour gérer ce qui doit se passer lorsque les conditions sont remplies.

Détails

La section Détails présente les règles FlightPATH disponibles. Vous pouvez ajouter de nouvelles règles flightPATH et supprimer celles qui ont été définies dans cette section.

Ajout d'une nouvelle règle flightPATH

Champ	Description
Nom de FlightPATH	Ce champ est réservé au nom de la règle flightPATH. Le nom que vous indiquez ici apparaît et est référencé dans d'autres parties du CDA.
Appliqué à VS	Cette colonne est en lecture seule et indique le VIP auquel la règle flightPATH est appliquée.
Description	Valeur représentant une description fournie à des fins de lisibilité.

Étapes à suivre pour ajouter une règle flightPATH

1. Tout d'abord, cliquez sur le bouton Ajouter nouveau situé dans la section Détails.

2. Saisissez un nom pour votre règle. Exemple Auth2

3. Entrez une description de votre règle

4. Une fois que la règle a été appliquée à un service, vous verrez la colonne Applied To se remplir automatiquement avec une adresse IP et une valeur de port.

5. N'oubliez pas d'appuyer sur le bouton Mettre à jour pour enregistrer vos modifications. Si vous faites une erreur, appuyez simplement sur Annuler pour revenir à l'état précédent.

Condition

Une règle FlightPATH peut comporter un nombre quelconque de conditions. Les conditions fonctionnent sur la base d'un ET, ce qui vous permet de définir la condition à partir de laquelle l'action est déclenchée. Si vous souhaitez utiliser une condition OR, créez une règle flightPATH supplémentaire et appliquez-la au VIP dans l'ordre correct.

Vous pouvez également utiliser RegEx en sélectionnant Match RegEx dans le champ Check et la valeur RegEx dans le champ Value. L'inclusion de l'évaluation RegEx étend considérablement les capacités de flightPATH.

Création d'une nouvelle condition flightPATH

Condition

Nous fournissons plusieurs conditions prédéfinies dans le menu déroulant et couvrent tous les scénarios prévus. Lorsque de nouvelles conditions seront ajoutées, elles seront disponibles via les mises à jour de Jetpack.

Les choix disponibles sont les suivants :

CONDITION	DESCRIPTION	EXEMPLE
<form>	Les formulaires HTML sont utilisés pour transmettre des données à un serveur.	Exemple "le formulaire n'a pas la longueur 0".
Localisation de GEO	Compare l'adresse IP source aux codes de pays ISO 3166.	GEO Location est égal à GB, OU GEO Location est égal à Allemagne
Hôte	Hôte extrait de l'URL	www.mywebsite.com ou 192.168.1.1
Langue	Langue extraite de l'en-tête HTTP langue	Cette condition produira une liste déroulante avec une liste de langues.
Méthode	Liste déroulante des méthodes HTTP	Liste déroulante qui inclut GET, POST, etc.
IP d'origine	Si le proxy en amont prend en charge X-Forwarded-for (XFF), il utilisera l'adresse d'origine réelle.	IP du client. Il peut également utiliser plusieurs IP ou sous-réseaux. 10\.1\.2\.* est 10.1.2.0 /24 sous-réseau10\ .1\.2\.3\|10\.1\.2\.4 Utilisez \| pour plusieurs adresses IP
Chemin d'accès	Chemin du site web	/mywebsite/index.asp
POST	Méthode de demande POST	Vérifier les données téléchargées sur un site web
Requête	Nom et valeur d'une requête, et peut accepter soit le nom de la requête soit une valeur également	"Best=jetNEXUS" où la correspondance est Best et la valeur est edgeNEXUS
Chaîne de requête	La chaîne de requête complète après le caractère ?
Demande de cookie	Nom d'un cookie demandé par un client	MS-WSMAN=afYfn1CDqCDqUD: :
En-tête de la demande	Tout en-tête HTTP	Referrer, User-Agent, From, Date
Demande de version	La version HTTP	HTTP/1.0 OU HTTP/1.1
Organe de réponse	Une chaîne définie par l'utilisateur dans le corps de la réponse	Serveur UP
Code de réponse	Le code HTTP pour la réponse	200 OK, 304 Non modifié
Cookie de réponse	Le nom d'un cookie envoyé par le serveur	MS-WSMAN=afYfn1CDqCDqUD: :
En-tête de réponse	Tout en-tête HTTP	Referrer, User-Agent, From, Date
Version de réponse	La version HTTP envoyée par le serveur	HTTP/1.0 OU HTTP/1.1
Source IP	Soit l'IP d'origine, l'IP du serveur proxy ou une autre adresse IP agrégée.	ClientIP , Proxy IP, Firewall IP. Vous pouvez également utiliser plusieurs IP et sous-réseaux. Vous devez échapper les points car il s'agit de RegEX. Exemple 10\.1\.2\.3 est 10.1.2.3

Match

Le champ "Match" peut être une liste déroulante ou une valeur de texte et il est définissable en fonction de la valeur du champ "Condition". Par exemple, si la Condition est définie sur Hôte, le champ Correspondance n'est pas disponible. Si la Condition est définie sur <form>, le champ Correspondance est présenté comme un champ de texte, et si la Condition est POST, le champ Correspondance est présenté comme un menu déroulant contenant des valeurs pertinentes.

Les choix disponibles sont les suivants :

MATCH	DESCRIPTION	EXEMPLE
Accepter	Types de contenu acceptables	Accepter : text/plain
Accept-Encoding	Encodements acceptables	Accept-Encoding : <compress \| gzip \| deflate \| sdch \| identity>
Accept-Language	Langues acceptables pour la réponse	Accept-Language : en-US
Accept-Ranges	Quels types de plages de contenu partiel ce serveur supporte-t-il ?	Accept-Ranges : bytes
Autorisation	Références d'authentification pour l'authentification HTTP	Autorisation : Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Charge-To	Contient des informations comptables sur les coûts de l'application de la méthode demandée.
Content-Encoding	Le type d'encodage utilisé	Content-Encoding : gzip
Content-Length	La longueur du corps de la réponse en octets (octets de 8 bits).	Content-Length : 348
Content-Type	Le type mime du corps de la demande (utilisé avec les demandes POST et PUT)	Content-Type : application/x-www-form-urlencoded
Cookie	Un cookie HTTP précédemment envoyé par le serveur avec Set-Cookie (ci-dessous)	Cookie : $Version=1 ; Skin=new ;
Date	Date et heure d'origine du message	Date = "Date" " :" HTTP-date
ETag	Un identifiant pour une version spécifique d'une ressource, souvent un résumé de message.	ETag : "aed6bdb8e090cd1:0"
De	L'adresse électronique de l'utilisateur qui fait la demande	De : user@example.com
Si-Modifié-Depuis	Permet de renvoyer un 304 Not Modified si le contenu est inchangé.	If-Modified-Since : Sat, 29 Oct 1994 19:43:31 GMT
Dernière modification	La date de dernière modification de l'objet demandé, au format RFC 2822.	Dernière modification : Tue, 15 Nov 1994 12:45:26 GMT
Pragma	Mise en œuvre : En-têtes spécifiques qui peuvent avoir des effets divers tout au long de la chaîne demande-réponse.	Pragma : no-cache
Référent	Adresse de la page web précédente à partir de laquelle un lien vers la page actuellement demandée a été suivi.	Referrer : HTTP://www.edgenexus.io
Serveur	Un nom pour le serveur	Serveur : Apache/2.4.1 (Unix)
Set-Cookie	Un cookie HTTP	Set-Cookie : UserID=JohnDoe ; Max-Age=3600 ; Version=1
User-Agent	La chaîne de l'agent utilisateur de l'agent utilisateur	User-Agent : Mozilla/5.0 (compatible ; MSIE 9.0 ; Windows NT 6.1 ; WOW64 ; Trident/5.0)
Varier	Indique aux mandataires en aval comment faire correspondre les futurs en-têtes de demande pour décider si la réponse mise en cache peut être utilisée plutôt que de demander une nouvelle réponse au serveur d'origine.	Vary : User-Agent
X-Powered-By	Spécifie la technologie (par exemple, ASP.NET, PHP, JBoss) qui prend en charge l'application Web.	X-Powered-By : PHP/5.4.0

Sense

Le champ Sense est un champ booléen déroulant qui contient les choix Does ou Doesn't.

Vérifiez

Le champ "Contrôle" permet de définir des valeurs de contrôle par rapport à la condition.

Les choix disponibles sont les suivants : Contient, Fin, Egal, Existe, A une longueur, Correspond à RegEx, Correspond à une liste, Début, Dépasse la longueur.

CHECK	DESCRIPTION	EXEMPLE
Existe	Le détail de la condition n'a pas d'importance, il suffit de savoir qu'elle existe ou n'existe pas.	L'hôte - existe - existe
Début	La chaîne de caractères commence par la valeur	Chemin - Does - Start - /secure
Fin	La chaîne se termine par la valeur	Chemin - Fait - Fin - .jpg
Contenir	La chaîne contient bien la valeur	En-tête de la demande - Accepter - Ne - Contenir - image
Equal	La chaîne est égale à la valeur	Hôte - Fait - Égale - www.jetnexus.com
Avoir la longueur	La chaîne de caractères a une longueur de la valeur	L'hôte - a - une longueur - 16www.jetnexus.com = VRAIwww.jetnexus.co.uk = FAUX
Match RegEx	Permet de saisir une expression régulière complète compatible avec Perl.	IP d'origine - Correspond - Regex - 10\..* \| 11\..*

Étapes pour ajouter une condition

L'ajout d'une nouvelle condition flightPATH est très simple. Un exemple est montré ci-dessus.

1. Cliquez sur le bouton Ajouter un nouveau dans la zone des conditions.

2. Choisissez une condition dans la liste déroulante. Prenons l'exemple de l'hôte. Vous pouvez également taper dans le champ, et le CDA affichera la valeur dans une liste déroulante.

3. Choisissez un sens. Par exemple, est-ce que

4. Choisissez une vérification. Par exemple, Container

5. Choisissez une valeur. Par exemple, mycompany.com

L'exemple ci-dessus montre qu'il y a deux conditions qui doivent toutes deux être VRAIES pour que la règle soit exécutée

· La première consiste à vérifier que l'objet demandé est une image

· Le second vérifie si l'hôte dans l'URL est www.imagepool.com.

Évaluation

La possibilité d'ajouter des variables définissables est une capacité convaincante. Les CDA ordinaires offrent cette possibilité en utilisant des options de script ou de ligne de commande qui ne sont pas idéales pour tout le monde. L'ADC vous permet de définir un nombre quelconque de variables à l'aide d'une interface graphique facile à utiliser, comme indiqué et décrit ci-dessous.

La définition de la variable flightPATH comprend quatre entrées qui doivent être effectuées.

· Variable - c'est le nom de la variable

· Source - une liste déroulante de points sources possibles

· Détail - sélectionnez les valeurs dans une liste déroulante ou saisissez-les manuellement.

· Valeur - la valeur que la variable contient et peut être une valeur alphanumérique ou un RegEx pour un réglage plus fin.

Variables intégrées :

Les variables Built-In ont déjà été codées en dur, il n'est donc pas nécessaire de créer une entrée d'évaluation pour celles-ci.

Vous pouvez utiliser l'une des variables énumérées ci-dessous dans la section Action.

L'explication de chaque variable se trouve dans le tableau "Condition" ci-dessus.

· Méthode = $method

· Chemin = $path$

· Querystring = $querystring$

· Sourceip = $sourceip$

· Code de réponse (le texte inclut également "200 OK") = $resp$.

· Hôte = $host$

· Version = $version$

· Port du client = $clientport

· Clientip = $clientip$.

· Géolocalisation = $geolocation$"

ACTION	CIBLE
Action = Redirection 302	Cible = HTTPs://$host$/404.html
Action = Journal	Cible = Un client de $sourceip$:$sourceport$ vient de faire une demande de page $path$.

Explication :

· Un client accédant à une page qui n'existe pas se verrait normalement présenter la page d'erreur 404 du navigateur.

· Au lieu de cela, l'utilisateur est redirigé vers le nom d'hôte original qu'il a utilisé, mais le chemin incorrect est remplacé par 404.html.

· Une entrée est ajoutée au Syslog disant, "Un client de 154.3.22.14:3454 vient de demander la page wrong.html".

Action

L'étape suivante du processus consiste à ajouter une action associée à la règle et à la condition flightPATH.

Dans cet exemple, nous voulons réécrire la partie chemin d'accès de l'URL pour refléter l'URL tapée par l'utilisateur.

· Cliquez sur Ajouter un nouveau

· Choisissez "Réécrire le chemin" dans le menu déroulant "Action".

· Dans le champ Cible, tapez $path$/myimages

· Cliquez sur Mise à jour

Cette action ajoutera /myimages au chemin, de sorte que l'URL final devienne www.imagepool.com/myimages.

Application de la règle flightPATH

L'application de toute règle flightPATH se fait dans l'onglet flightPATH de chaque VIP/VS.

· Accédez à Services > Services IP et choisissez le VIP auquel vous souhaitez affecter la règle flightPATH.

· Vous verrez la liste des serveurs réels ci-dessous

· Cliquez sur l'onglet flightPATH

· Sélectionnez la règle flightPATH que vous avez configurée ou l'une des règles préétablies prises en charge. Vous pouvez sélectionner plusieurs règles flightPATH si nécessaire.

· Faites glisser et déposez l'ensemble sélectionné dans la section Applied flightPATHs ou cliquez sur le bouton fléché >>.

· La règle sera déplacée vers le côté droit et appliquée automatiquement.