Citrix ADC Ingress Controller

HTTP-Callout mit der Rewrite- und Responder-Richtlinie

Mit einem HTTP-Callout kann Citrix ADC im Rahmen der Richtlinienbewertung eine HTTP- oder HTTPS-Anforderung an einen externen Server (Callout-Agent) generieren und an einen externen Server (Callout-Agent) senden. Die Informationen, die vom Server abgerufen werden (Callout-Agent), können mit erweiterten Richtlinienausdrücken analysiert werden, und es kann eine entsprechende Aktion durchgeführt werden. Weitere Informationen zum HTTP-Callout finden Sie in der Citrix ADC-Dokumentation.

Sie können den HTTP-Callout mit den folgenden Ausdrücken mit der von Citrix bereitgestellten Rewrite- und Responder-CRD initiieren:

  • sys.http_callout(): Dieser Ausdruck wird verwendet, um den Aufruf zu blockieren, wenn die Antwort des HttpCallout-Agenten ausgewertet werden muss.

  • sys.non_blocking_http_callout(): Dieser Ausdruck wird für nicht blockierende Anrufe verwendet (zum Beispiel: Verkehrsspiegelung)

Diese Ausdrücke akzeptieren den in der CRD definierten httpcallout_policy Namen als Parameter, wobei der Name in doppelten Anführungszeichen angegeben werden muss.

Beispiel: sys.http_callout("callout_name"). In diesem Ausdruck bezieht sich callout_name auf die entsprechende httpcallout_policy Definition in der Rewrite- und Responder-CRD-YAML-Datei.

In der folgenden Tabelle werden die Attribute der HTTP-Callout-Anforderung in der Rewrite- und Responder-CRD erläutert.

Parameter Beschreibung
name Gibt den Namen des Callouts an, das Maximum beträgt bis zu 32 Zeichen.
server_ip Gibt die IP-Adresse des Servers (Callout-Agent) an, an den der Callout gesendet wird.
server_port Gibt den Port des Servers (Callout-Agent) an, an den der Callout gesendet wird.
http_method Gibt die Methode an, die in der HTTP-Anforderung verwendet wird, die dieser Callout sendet. Der Standardwert ist GET.
host_expr Gibt den Textausdruck zum Konfigurieren des Host-Headers an. Dieser Ausdruck kann ein Literalwert sein (z. B. 192.101.10.11) oder ein erweiterter Ausdruck (z. B. http.req.header (“Host”)), der den Wert ableitet. Der Literalwert kann eine IP-Adresse oder ein vollqualifizierter Domainname sein. Mit dem vollständigen Ausdruck der HTTP-Anforderung schließen sich gegenseitig aus.
url_stem_expr Gibt einen Zeichenfolgenausdruck zum Generieren des URL-Stamms an Der Zeichenfolgenausdruck kann eine literale Zeichenfolge (z. B. “/mysite/index.html “) oder einen Ausdruck enthalten, der den Wert ableitet (z. B. http.req.url).
headers Gibt einen oder mehrere Header an, die in die HTTP-Anforderung eingefügt werden sollen. Jeder Header name und exp, wo exp ist ein Ausdruck, der zur Laufzeit ausgewertet wird, um den Wert für den benannten Header bereitzustellen.
parameters Gibt einen oder mehrere Abfrageparameter an, die in die URL der HTTP-Anforderung (für eine GET-Anforderung) oder in den Text der Anforderung (für eine POST-Anforderung) eingefügt werden. Jeder Parameter wird durch ein name und ein dargestellt expr, wobei ein Ausdruck expr ist, der zur Laufzeit ausgewertet wird, um den Wert für den benannten Parameter (Name=Wert) bereitzustellen. Die Parameterwerte sind URL-codiert.
body_expr Ein erweiterter Zeichenfolgenausdruck zum Generieren des Hauptkörpers der Anforderung. Der Ausdruck kann eine literale Zeichenfolge oder einen Ausdruck enthalten, der den Wert ableitet (z. B. client.ip.src).
full_req_expr Gibt die genaue HTTP-Anforderung in Form eines Ausdrucks an, den Citrix ADC an den Callout-Agenten sendet. Der Anforderungsausdruck wird durch das Feature eingeschränkt, für das das Callout verwendet wird. Beispielsweise kann ein HTTP.RES-Ausdruck nicht in einer Richtlinienbank zur Anforderungszeit oder in einer TCP-Content Switching-Richtlinienbank verwendet werden.
scheme Gibt den Typ des Schemas für den Callout-Server an. Beispiel: HTTP, HTTPS
return_type Gibt den Datentyp an, den der Ziel-Callout-Agent als Reaktion auf den Callout zurückgibt. Die verfügbaren Einstellungen funktionieren wie folgt: TEXT - Behandelt den zurückgegebenen Wert als Textzeichenfolge. NUM - Behandelt den zurückgegebenen Wert wie eine Zahl. BOOL - Behandelt den zurückgegebenen Wert als booleschen Wert.
cache_for_secs Gibt die Dauer in Sekunden an, für die die Callout-Antwort zwischengespeichert wird. Die zwischengespeicherten Antworten werden in einer integrierten Caching-Content-Gruppe namens gespeichert calloutContentGroup. Wenn die Dauer nicht konfiguriert ist, werden die Callout-Antworten nicht zwischengespeichert, es sei denn, eine normale Caching-Konfiguration wird verwendet, um sie zu cachen. Dieser Parameter hat Vorrang vor jeder normalen Caching-Konfiguration, die sonst für diese Antworten gelten würde.
result_expr Gibt den Ausdruck an, der die Callout-Ergebnisse aus der vom HTTP-Callout-Agenten gesendeten Antwort extrahiert. Dieser Ausdruck muss ein antwortbasierter Ausdruck sein, das heißt, er muss mit beginnen HTTP.RES. Die Operationen in diesem Ausdruck müssen mit dem Rückgabetyp übereinstimmen. Wenn Sie beispielsweise einen Rückgabetyp von konfigurieren TEXT, muss der Ergebnisausdruck ein textbasierter Ausdruck sein. Wenn der Rückgabetyp ist NUM, muss der Ergebnisausdruck (result_expr) einen numerischen Wert zurückgeben, wie im folgenden Beispiel: http.res.body(10000).length
comment Gibt alle Kommentare an, um die Informationen zu diesem HTTP-Callout beizubehalten.

Verwenden der Rewrite- und Responder-CRD, um zu überprüfen, ob eine Client-IP-Adresse auf der Blockliste steht

In diesem Abschnitt wird erläutert, wie ein HTTP-Callout mit der Rewrite- und Responder-CRD initiiert wird, um zu überprüfen, ob eine Client-IP-Adresse auf der Blockliste steht oder nicht, und die entsprechenden Maßnahmen zu ergreifen.

Das folgende Diagramm erklärt den Workflow einer Anforderung, wobei jede Zahl im Diagramm einen Schritt im Workflow kennzeichnet: HTTP-Callout

  1. Anfrage des Kunden

  2. HTTP-Callout-Anforderung, um zu überprüfen, ob der Client auf der Blockliste steht (Die Client-IP-Adresse wird als Abfrageparameter mit dem Namen gesendet Cip)

  3. Antwort vom HTTP-Callout-Server

  4. Die Anforderung wird an den Dienst weitergeleitet, wenn die Antwort in Schritt 3 auf eine sichere IP-Adresse hinweist (die Client-IP-Adresse stimmt nicht mit den IP-Adressen auf der Blockliste auf dem Callout-Server überein).

  5. Reagieren Sie auf den Client Access denied, als ob die Antwort in Schritt 3 auf eine fehlerhafte IP-Adresse hindeutet (die Client-IP-Adresse stimmt mit den IP-Adressen auf der Blockliste auf dem Callout-Server überein).

Im Folgenden finden Sie ein Beispiel für eine YAML-Datei (ip_validate_responder.yaml) zum Validieren einer IP-Adresse auf der Blockliste:

Hinweis:

Sie müssen die Rewrite- und Responder-CRD bereitstellen, bevor Sie die YAML-Datei ip_validate_responder bereitstellen.

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-->

Verwenden der Rewrite- und Responder-CRD, um die URL mit einem vom Client angeforderten gültigen Pfad zu aktualisieren

In diesem Abschnitt wird erläutert, wie ein HTTP-Callout mit der Rewrite- und Responder-CRD initiiert wird, wenn sich ein dem Client offengelegter Pfad aus Sicherheitsgründen vom tatsächlichen Pfad unterscheidet.

Der Arbeitsablauf einer Anforderung wird in der folgenden Abbildung erläutert, wobei jede Zahl im Diagramm einen Schritt im Workflow bezeichnet.

HTTP-Aufruf

  1. Anfrage des Kunden

  2. HTTP-Callout-Anforderung zum Abrufen des gültigen Pfades (der vom Client angeforderte Pfad wird als Abfrageparameter mit dem Namen Pfad zum Callout-Server gesendet)

  3. Antwort vom HTTP-Callout-Server

  4. Die URL-Anforderung wird mit einem gültigen Pfad umgeschrieben und an den Service weitergeleitet (wobei der gültige Pfad zwischen den Tags newpath in der Callout-Antwort erwähnt wird).

Im Folgenden finden Sie ein Beispiel für eine YAML (path_rewrite) -Datei.

Hinweis:

Sie müssen die Rewrite- und Responder-CRD bereitstellen, bevor Sie die YAML-Datei path_rewrite bereitstellen.

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-->
HTTP-Callout mit der Rewrite- und Responder-Richtlinie