Contrôleur d'entrée Citrix ADC

Appel HTTP avec la stratégie de réécriture et de répondeur

Une légende HTTP permet à Citrix ADC de générer et d’envoyer une demande HTTP ou HTTPS à un serveur externe (agent de légende) dans le cadre de l’évaluation de la stratégie. Les informations récupérées à partir du serveur (agent d’accroche) peuvent être analysées par des expressions de stratégie avancées et une action appropriée peut être effectuée. Pour plus d’informations sur la légende HTTP, consultez la documentation Citrix ADC.

Vous pouvez lancer la légende HTTP via les expressions suivantes avec le CRD de réécriture et de répondeur fourni par Citrix :

  • sys.http_callout(): Cette expression est utilisée pour bloquer l’appel lorsque la réponse de l’agent httpcallout doit être évaluée.

  • sys.non_blocking_http_callout(): Cette expression est utilisée pour les appels non bloquants (par exemple : mise en miroir du trafic)

Ces expressions acceptent le nom httpcallout_policy défini dans le CRD en tant que paramètre, où le nom doit être spécifié entre guillemets.

Par exemple : sys.http_callout("callout_name"). Dans cette expression, callout_name fait référence à la valeur appropriée httpcallout_policy définie dans le fichier YAML de réécriture et de réponse CRD.

Le tableau suivant explique les attributs de la demande d’appel HTTP dans le CRD de réécriture et de répondeur.

Paramètre Description
name Spécifie le nom de la légende, le maximum est de 32 caractères.
server_ip Spécifie l’adresse IP du serveur (agent de légende) auquel l’appel est envoyé.
server_port Spécifie le port du serveur (agent de légende) auquel la légende est envoyée.
http_method Spécifie la méthode utilisée dans la demande HTTP envoyée par cette légende. La valeur par défaut est GET.
host_expr Spécifie l’expression de texte pour configurer l’en-tête de l’hôte. Cette expression peut être une valeur littérale (par exemple, 192.101.10.11) ou une expression avancée (par exemple, http.req.header (« Host »)) qui dérive la valeur. La valeur littérale peut être une adresse IP ou un nom de domaine complet. Exclusivité mutuelle avec l’expression de requête HTTP complète.
url_stem_expr Spécifie une expression de chaîne pour générer le radical d’URL. L’expression de chaîne peut contenir une chaîne littérale (par exemple, “/mysite/index.html”) ou une expression qui dérive la valeur (par exemple, http.req.url).
headers Spécifie un ou plusieurs en-têtes à insérer dans la demande HTTP. Chaque en-tête name et exp, où exp représente une expression évaluée au moment de l’exécution pour fournir la valeur de l’en-tête nommé.
parameters Spécifie un ou plusieurs paramètres de requête à insérer dans l’URL de la demande HTTP (pour une demande GET) ou dans le corps de la demande (pour une demande POST). Chaque paramètre est représenté par un name et un expr, où expr est une expression évaluée au moment de l’exécution pour fournir la valeur du paramètre nommé (nom=valeur). Les valeurs des paramètres sont codées par URL.
body_expr Expression de chaîne avancée permettant de générer le corps de la requête. L’expression peut contenir une chaîne littérale ou une expression qui dérive la valeur (par exemple, client.ip.src).
full_req_expr Spécifie la demande HTTP exacte, sous la forme d’une expression, que Citrix ADC envoie à l’agent d’appel externe. L’expression de demande est contrainte par la fonctionnalité pour laquelle la légende est utilisée. Par exemple, une expression HTTP.RES ne peut pas être utilisée dans une banque de stratégies au moment de la demande ou dans une banque de stratégies de changement de contenu TCP.
scheme Spécifie le type de schéma pour le serveur d’appels externes. Exemple : HTTP, HTTPS
return_type Spécifie le type de données que l’agent d’légende cible renvoie en réponse à la légende. Les paramètres disponibles fonctionnent comme suit : TEXTE - Traiter la valeur renvoyée comme une chaîne de texte. NUM : traite la valeur renvoyée comme un nombre. BOOL - Traite la valeur renvoyée comme une valeur booléenne.
cache_for_secs Spécifie la durée, en secondes, pendant laquelle la réponse de légende est mise en cache. Les réponses mises en cache sont stockées dans un groupe de contenus de mise en cache intégré nommé calloutContentGroup. Si la durée n’est pas configurée, les réponses de légende ne sont pas mises en cache, sauf si une configuration de mise en cache normale est utilisée pour les mettre en cache. Ce paramètre prévaut sur toute configuration normale de mise en cache qui s’appliquerait autrement à ces réponses.
result_expr Spécifie l’expression qui extrait les résultats de la légende de la réponse envoyée par l’agent de légende HTTP. Cette expression doit être basée sur une réponse, c’est-à-dire qu’elle doit commencer par HTTP.RES. Les opérations de cette expression doivent correspondre au type de retour. Par exemple, si vous configurez un type de retour de TEXT, l’expression de résultat doit être une expression basée sur du texte. Si le type de retour est NUM, l’expression de résultat (result_expr) doit renvoyer une valeur numérique, comme dans l’exemple suivant : http.res.body(10000).length
comment Spécifie tous les commentaires destinés à conserver les informations relatives à cette légende HTTP.

Utilisation du CRD de réécriture et de réponse pour vérifier si l’adresse IP d’un client est bloquée

Cette section explique comment lancer une légende HTTP à l’aide du CRD de réécriture et de réponse pour vérifier si une adresse IP du client est bloquée ou non et prendre les mesures appropriées.

Le diagramme suivant explique le flux de travail d’une demande où chaque chiffre du diagramme indique une étape du flux de travail : Appel HTTP

  1. Demande du client

  2. Demande d’appel HTTP pour vérifier si le client est sur liste de blocage (l’adresse IP du client est envoyée en tant que paramètre de requête avec le nom Cip)

  3. Réponse du serveur d’appels externes HTTP

  4. La demande est transmise au service si la réponse de l’étape 3 indique une adresse IP sûre (l’adresse IP du client ne correspond pas aux adresses IP bloquées sur le serveur d’appel).

  5. Répondez au client en tant que Access denied, si la réponse de l’étape 3 indique une adresse IP incorrecte (l’adresse IP du client correspond aux adresses IP bloquées sur le serveur d’appel).

Voici un exemple de fichier YAML (ip_validate_responder.yaml) pour valider une adresse IP bloquée :

Remarque :

Vous devez déployer le CRD de réécriture et de répondeur avant de déployer le fichier YAML ip_validate_responder.

apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: validateip
spec:
  responder-policies:
    - servicenames:
        - frontend
      responder-policy:
        respondwith:
          http-payload-string: '"HTTP/1.1 401 Access denied\r\n\r\n"'
        respond-criteria: 'sys.http_callout("blocklist_callout").CONTAINS("IP Matched")' #Callout name needs to be given in double quotes to pick httpcallout_policy
        comment: 'Invalid access'

  httpcallout_policy:
    - name: blocklist_callout
      server_ip: "192.2.156.160"
      server_port: 80
      http_method: GET
      host_expr: '"192.2.156.160"'
      url_stem_expr: '"/validateIP.pl"'
      headers:
      - name: X-Request
        expr: '"Callout Request"'
      parameters:
      - name: Cip
        expr: 'CLIENT.IP.SRC'
      return_type: TEXT
      result_expr: 'HTTP.RES.BODY(100)'
<!--NeedCopy-->

Utilisation du CRD de réécriture et de réponse pour mettre à jour l’URL avec un chemin valide demandé par le client

Cette section explique comment lancer une légende HTTP à l’aide du CRD de réécriture et de réponse lorsqu’un chemin exposé au client est différent du chemin réel pour des raisons de sécurité.

Le flux de travail d’une demande est expliqué dans le diagramme suivant où chaque chiffre du diagramme indique une étape du flux de travail.

Appel sortant HTTP

  1. Demande du client

  2. Demande d’appel HTTP pour obtenir le chemin d’accès valide (le chemin demandé au client est envoyé en tant que paramètre de requête avec le chemin d’accès du nom au serveur de légende)

  3. Réponse du serveur d’appels externes HTTP

  4. La demande d’URL est réécrite avec un chemin d’accès valide et transmise au service (où le chemin valide est mentionné entre les balises newpath dans la réponse de l’appel).

Voici un exemple de fichier YAML (path_rewrite).

Remarque :

Vous devez déployer le CRD de réécriture et de répondeur avant de déployer le fichier YAML path_rewrite.

apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: getvalidpath
spec:
  rewrite-policies:
    - servicenames:
        - frontend
      rewrite-policy:
        operation: replace
        target: http.req.url
        modify-expression: 'sys.http_callout("mapping_callout")' #Callout name needs to be given in double quotes to pick httpcallout_policy
        comment: 'Get the valid path'
        direction: REQUEST
        rewrite-criteria: 'TRUE'

  httpcallout_policy:
    - name: mapping_callout
      server_ip: "192.2.156.160"
      server_port: 80
      http_method: GET
      host_expr: '"192.2.156.160"'
      url_stem_expr: '"/getPath.pl"'
      headers:
      - name: X-Request
        expr: '"Callout Request"'
      parameters:
      - name: path
        expr: 'http.req.url'
      return_type: TEXT
      result_expr: '"HTTP.RES.BODY(500).AFTER_STR("<newpath>").BEFORE_STR("</newpath>")"'
<!--NeedCopy-->
Appel HTTP avec la stratégie de réécriture et de répondeur