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
|
Une 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.edgenexus.io
|
|
Avoir la longueur
|
La chaîne de caractères a une longueur de la valeur
|
Host - Does - Have Length - 16
www.edgenexus.io = VRAI
www.edgenexus.com = FAUX
|
|
Match RegEx
|
Vous 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.
