Kubernetesでリライトおよびレスポンダーポリシーを使用する

最終公開日 : Oct 02, 2026
Kubernetes環境で、次のようなシナリオを処理するために特定のレイヤー7ポリシーを展開するには：
  • HTTPトラフィックを特定のURLにリダイレクトする
  • DDoS攻撃を軽減するために一連のIPアドレスをブロックする
  • HTTPからHTTPSへの強制
マイクロサービス内に適切なライブラリを追加し、ポリシーを手動で構成する必要があります。代わりに、Ingress NetScalerデバイスが提供するリライトおよびレスポンダー機能を使用して、これらのポリシーを展開できます。
NetScalerは、NetScaler Ingress Controllerと連携して、Ingressデバイスとして使用されるNetScaler上のこれらのポリシーの構成と展開を自動化するために使用できるKubernetesのカスタムリソース定義 (CRD) を提供します。
NetScalerが提供するリライトおよびレスポンダーCRDは、最前線のNetScalerで使用される一連のツールを公開するように設計されています。これらの機能を使用すると、イングレスおよびエグレスHTTPトラフィックのヘッダーとペイロードを書き換えたり、マイクロサービスに代わってHTTPトラフィックに応答したりできます。
KubernetesクラスターにリライトおよびレスポンダーCRDを展開すると、データセット、パターンセット、文字列マップを使用して広範なリライトおよびレスポンダーポリシーを定義し、イングレスデバイスの統計のために監査ログを有効にすることができます。NetScaler ADCが提供するリライトおよびレスポンダーポリシー機能の詳細については、リライトポリシーおよびレスポンダーポリシーを参照してください。
注：
リライトおよびレスポンダーCRDはOpenShiftルートではサポートされていません。リライトおよびレスポンダーCRDを使用するには、OpenShiftイングレスを使用できます。
Related information
CRD

NetScaler®リライトおよびレスポンダーCRDを展開する

NetScalerリライトおよびレスポンダーCRD展開YAMLファイル：rewrite-responder-policies-deployment.yaml。
注：
展開YAMLファイルを変更しないようにしてください。
次のコマンドを使用して、CRD をデプロイします。
kubectl create -f rewrite-responder-policies-deployment.yaml
例:
root@master:~# kubectl create -f rewrite-responder-policies-deployment.yaml
customresourcedefinition.apiextensions.k8s.io/rewritepolicies.citrix.com created

リライトおよびレスポンダー CRD 属性

CRD は、リライトおよびレスポンダーポリシーを定義するために必要なさまざまなオプションの属性を提供します。また、リライトおよびレスポンダーポリシー内で使用するデータセット、パターンセット、文字列マップ、および監査ログの属性も提供します。これらの CRD 属性は、それぞれ NetScaler コマンドおよび属性に対応しています。

リライトポリシー

次の表に、リライトポリシーを定義するために使用できる CRD 属性を示します。また、この表には対応する NetScaler コマンドと属性も示されています。
CRD 属性 NetScaler コマンド NetScaler 属性
リライト条件 リライトポリシーの追加 ルール
デフォルトアクション リライトポリシーの追加 undefAction
操作 リライトアクションの追加 タイプ
ターゲット リライトアクションの追加 ターゲット
変更式 リライトアクションの追加 stringBuilderExpr
複数回変更 リライトアクションの追加 検索
追加の複数回変更 リライトアクションの追加 検索の絞り込み
方向 LB仮想サーバーをバインド タイプ

レスポンダーポリシー

次の表に、レスポンダーポリシーを定義するために使用できるCRD属性を示します。また、この表には対応するNetScalerコマンドと属性も記載されています。
CRD属性 NetScalerコマンド NetScaler属性
リダイレクト レスポンダーアクションを追加 タイプ (typeの値)
URL レスポンダーアクションを追加 ターゲット
リダイレクトステータスコード レスポンダーアクションを追加 responseStatusCode
リダイレクト理由 レスポンダーアクションを追加 reasonPhrase
～で応答 レスポンダーアクションを追加 タイプ（type の値）
HTTPペイロード文字列 レスポンダーアクションを追加 ターゲット
何もしない レスポンダーポリシーを追加 アクション（action の値）
リセット レスポンダーポリシーを追加 アクション (action の値)
ドロップ レスポンダーポリシーを追加 アクション (action の値)
応答基準 レスポンダーポリシーを追加 ルール
デフォルトアクション レスポンダーポリシーを追加 undefAction

監査ログ

次の表に、リライトポリシーまたはレスポンダーポリシー内で監査ログを有効にするために提供される CRD 属性を示します。また、この表には対応するNetScalerコマンドと属性も示されています。
CRD属性 NetScalerコマンド NetScaler属性
ログ式 監査メッセージアクションの追加 stringBuilderExpr
ログレベル 監査メッセージアクションの追加 ログレベル

データセット

次の表に、リライトポリシーまたはレスポンダーポリシー内で使用できるデータセットのCRD属性を示します。また、この表には対応するNetScalerコマンドと属性も記載されています。
CRD属性 NetScalerコマンド NetScaler属性
名前 ポリシーデータセットの追加 名前
タイプ ポリシーデータセットの追加 タイプ
値 ポリシーデータセットのバインド 値

パットセット

CRD属性 NetScalerコマンド NetScaler属性
名前 ポリシーパットセットの追加 名前
値 ポリシーパットセットのバインド 文字列

文字列マップ

CRD属性 NetScalerコマンド NetScaler属性
名前 ポリシー文字列マップの追加 名前
キー ポリシー文字列マップのバインド キー
値 ポリシー文字列マップのバインド 値

Goto-優先度-式

次の表に、複数の連続するポリシーのグループをサービスにバインドするためのCRD属性であるgoto-priority-expression属性に関する情報を示します。
CRD属性 NetScalerコマンド NetScaler属性 サポートされている値 デフォルト値
ゴートゥー・プリロティ・エクスプレッション LB仮想サーバーをバインド gotoPriorityExpression ネクストとエンド End
goto-priority-expression属性の使用方法の詳細については、例「要求されたURLの文字列とホスト名を変更する」を参照してください。

ポリシー構成の記述方法

NetScalerによって提供されるCRDをKubernetesクラスターに展開した後、.yamlファイルでポリシー構成を定義できます。.yamlファイルでは、kindフィールドでrewritepolicyを使用し、要件に基づいて、ポリシー構成のためにspecに次の個別のセクションのいずれかを追加します。
  • rewrite-policy - リライトポリシー構成を定義します。
  • responder-policy - レスポンダーポリシー設定を定義するため。
  • logpackets - 監査ログを有効にするため。
  • dataset - 広範なポリシー設定にデータセットを使用するため。
  • patset - 広範なポリシー設定にパターンセットを使用するため。
  • stringmaps - 広範なポリシー設定に文字列マップを使用するため。
これらのセクションでは、ポリシーを定義するために、それぞれのポリシー設定（リライトまたはレスポンダー）に提供されているCRD属性を使用する必要があります。
また、specセクションでは、ポリシーを適用する必要があるサービスを指定するために、rewrite-policiesセクションを含める必要があります。詳細については、ポリシー設定の例を参照してください。
.yamlファイルをデプロイすると、NetScaler Ingress ControllerはIngress NetScalerデバイスにポリシー設定を適用します。

ポリシー設定のガイドライン

  • CRDが名前空間に関連付けられている場合、デフォルトでは、ポリシーはその名前空間に関連付けられているサービスに適用されます。たとえば、複数の名前空間に同じサービス名が関連付けられている場合、ポリシーはCRDに関連付けられている名前空間に属するサービスに適用されます。
  • 単一の.yamlファイルで複数のポリシーを定義している場合、ファイル内で最初に定義されたポリシー設定が優先され、その後のポリシー設定は順序に従って適用されます。異なるファイルで複数のポリシーを定義している場合、最初にデプロイしたファイルで定義された最初のポリシー設定が優先されます。

Goto-priority-expressionの使用に関するガイドライン

  • リライトポリシーとレスポンダーポリシーは、goto-priority-expressionフィールド内のNEXTキーワードを使用して複数のグループとして組み合わせることができます。
  • 現在のポリシー内でgoto-priority-expressionフィールドがNEXTであり、現在のポリシーがTrueと評価される場合、goto-priority-expressionフィールドがENDを指していない限り、グループ内の次のポリシーが実行され、フローは次の連続するポリシーに移動します。
  • 現在のポリシーがFALSEと評価される場合、ポリシーの実行は現在のポリシーで停止するため、goto-priority-expressionは影響を与えません。
  • リライトまたはレスポンダーポリシー内のリライトまたはレスポンダーポリシーグループは、goto-priority-expressionがNEXTとして割り当てられたポリシーから始まり、goto-priority-expressionフィールドにENDが割り当てられるまですべての連続するポリシーを含みます。
  • goto-priority-expressionを使用してリライトまたはレスポンダーポリシーをグループ化する場合、グループ内のポリシーにバインドされているサービス名は同じである必要があります。
  • リライトポリシーまたはレスポンダーポリシー内の最後のポリシーは、常にgoto-priority-expressionをENDとして持つ必要があります。
  • ポリシーに対してgoto-priority-expressionフィールドが指定されていない場合、デフォルト値のENDがgoto-priority-expressionに割り当てられます。
注:
goto-priority-expressionフィールドの使用方法の詳細については、例「要求されたURLの文字列とホスト名を変更する」を参照してください。

リライトおよびレスポンダーポリシーの作成と検証

NetScalerで、すべての受信URLをnew-url-for-the-applicationに書き換え、マイクロサービスに送信するポリシーを定義するシナリオを考えてみましょう。target-url-rewrite.yamlという名前の.yamlファイルを作成し、適切なCRD属性を使用して、リライトポリシーを次のように定義します。
apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: targeturlrewrite
spec:
  rewrite-policies:
    - servicenames:
        - citrix-svc
      logpackets:
        logexpression: "http.req.url"
        loglevel: INFORMATIONAL
      rewrite-policy:
        operation: replace
        target: 'http.req.url'
        modify-expression: '"new-url-for-the-application"'
        comment: 'Target URL Rewrite - rewrite the url of the HTTP request'
        direction: REQUEST
        rewrite-criteria: 'http.req.is_valid'
ポリシー構成を定義したら、次のコマンドを使用して.yamlファイルをデプロイします。
kubectl create -f target-url-rewrite.yaml
.yamlファイルをデプロイすると、NetScaler Ingress Controllerは、Ingress NetScalerデバイスにポリシー構成を適用します。
Kubernetesクラスターのマスターノードで、次のコマンドを使用して、適用されたリライトポリシーCRDのステータスを確認できます。
Kubectl get rewritepolicies.citrix.com targeturlrewrite
ステータスは次のように表示されます。
kubectl get rewritepolicies.citrix.com targeturlrewrite
NAME               STATUS    MESSAGE
targeturlrewrite   Success   CRD Activated
CRDの作成または適用中に問題が発生した場合、citrix-k8s-ingress-controllerログを使用してデバッグできます。
kubectl logs citrixingresscontroller
また、次の手順を使用して、構成がNetScalerに適用されているかどうかを確認できます。
  1. NetScalerコマンドラインにログオンします。
  2. 以下のコマンドを使用して、設定がNetScalerに適用されているかを確認します。
    show run | grep `lb vserver`
    add lb vserver k8s-citrix_default_80_k8s-citrix-svc_default_80_svc HTTP 0.0.0.0 0 -persistenceType NONE -cltTimeout 180
    bind lb vserver k8s-citrix_default_80_k8s-citrix-svc_default_80_svc k8s-citrix_default_80_k8s-citrix-svc_default_80_svc
    bind lb vserver k8s-citrix_default_80_k8s-citrix-svc_default_80_svc -policyName k8s_crd_rewritepolicy_rwpolicy_targeturlrewrite_0_default -priority 100300076 -gotoPriorityExpression END -type REQUEST
    ポリシー k8s_crd_rewritepolicy_rwpolicy_targeturlrewrite_0_default がロードバランシング仮想サーバーにバインドされていることを確認できます。

ポリシー設定の例

レスポンダーポリシー設定

以下はレスポンダーポリシー設定の例です (block-list-urls.yaml)
apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: blocklisturls
spec:
  responder-policies:
    - servicenames:
        - citrix-svc
      responder-policy:
        respondwith:
          http-payload-string: '"HTTP/1.1 401 Access denied"'
        respond-criteria: 'http.req.url.equals_any("blocklistUrls")'
        comment: 'Blocklist certain Urls'


  patset:
    - name: blocklistUrls
      values:
        - '/app1'
        - '/app2'
        - '/app3'
この例では、NetScalerが patset で定義された /app1、/app2、または /app3 の文字列に一致するURLを受信した場合、NetScalerはそのURLをブロックします。

監査ログが有効なポリシー

以下は、監査ログが有効なポリシーの例です (block-list-urls-audit-log.yaml)。
apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: blocklisturls
spec:
  responder-policies:
    - servicenames:
        - citrix-svc
      logpackets:
        logexpression: "http.req.url"
        loglevel: INFORMATIONAL
      responder-policy:
        respondwith:
          http-payload-string: '"HTTP/1.1 401 Access denied"'
        respond-criteria: 'http.req.url.equals_any("blocklistUrls")'
        comment: 'Blocklist certain Urls'


  patset:
    - name: blocklistUrls
      values:
        - '/app1'
        - '/app2'
        - '/app3'

複数のポリシー設定

単一の .yaml ファイルに複数のポリシー設定を追加し、NetScalerデバイスにポリシーを適用できます。各ポリシー設定には個別のセクションを追加する必要があります (multi-policy-config.yaml)。
apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: multipolicy
spec:
  responder-policies:
    - servicenames:
        - citrix-svc
      responder-policy:
        redirect:
          url: '"www.citrix.com"'
        respond-criteria: 'client.ip.src.TYPECAST_text_t.equals_any("redirectIPs")'
        comment: 'Redirect IPs to citrix.com'
    - servicenames:
        - citrix-svc
      responder-policy:
        redirect:
          url: 'HTTP.REQ.HOSTNAME+http.req.url.MAP_STRING_DEFAULT_TO_KEY("modifyurls")'
        respond-criteria: 'http.req.is_valid'
        comment: 'modify specific URLs'

  rewrite-policies:
    - servicenames:
        - citrix-svc
      rewrite-policy:
        operation: insert_http_header
        target: 'sessionID'
        modify-expression: '"48592th42gl24456284536tgt2"'
        comment: 'insert SessionID in header'
        direction: RESPONSE
        rewrite-criteria: 'http.res.is_valid'



  dataset:
    - name: redirectIPs
      type: ipv4
      values:
        - 10.1.1.100
        - 1.1.1.1 - 1.1.1.100
        - 2.2.2.2/10

  stringmap:
    - name: modifyurls
      comment: Urls to be modified string
      values:
        - key: '"/app1/"'
          value: '"/internal-app1/"'
        - key: '"/app2/"'
          value: '"/internal-app2/"'
この例には、2つのレスポンダーポリシーと1つの書き換えポリシーが含まれており、これらのポリシーに基づいてNetScalerは以下を実行します。
  • redirectIPs データセットで指定されたクライアントIPアドレス、つまり 10.1.1.100、範囲 1.1.1.1 - 1.1.1.100 のIPアドレス、およびサブネット 2.2.2.2/10 のIPアドレスに一致するすべてのリクエストは、www.citrix.com にリダイレクトされます。
  • modifyurls ストリングマップで提供される文字列を含むすべての受信URLは、ストリングマップで提供される値に修正されます。たとえば、受信URLに /app1/ の文字列がある場合、/internal-app1/ に修正されます。
  • クライアントへの応答に、セッションIDを新しいヘッダーとして追加します。

使用例

レスポンスヘッダーを追加

クライアントからのリクエストURLに /citrix-app/ が含まれている場合、リライトポリシーを使用して、マイクロサービスからクライアントへのHTTPレスポンスに以下のヘッダーを追加できます。
  • クライアントのソースポートをヘッダーに
  • サーバーの宛先IPアドレス
  • ランダムなHTTPヘッダー
次のサンプルリライトポリシー定義は、これらのヘッダーをマイクロサービスからクライアントへのHTTPレスポンスに追加します。
apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
name: addresponseheaders
spec:
rewrite-policies:
  - servicenames:
      - frontend
    rewrite-policy:
      operation: insert_before_all
      target: http.res.full_header
      modify-expression: '"\r\nx-port: "+client.tcp.srcport+"\r\nx-ip:"+client.ip.dst+"\r\nx-new-dummy-header: Sending_a_gift"'
      multiple-occurence-modify: 'text("\r\n\r\n")'
      comment: 'Response header rewrite'
      direction: RESPONSE
      rewrite-criteria: 'http.req.url.contains("/citrix-app/")'
リライトポリシー定義を含むYAMLファイル (add_response_headers.yaml) を作成し、次のコマンドを使用してYAMLファイルをデプロイします。
kubectl create -f add_response_headers.yaml
レスポンスに追加されたHTTPヘッダーは、次のように確認できます。
$ curl -vvv http://app.cic-citrix.org/citrix-app/
*   Trying 10.102.33.176...
* TCP_NODELAY set
* Connected to app.cic-citrix.org (10.102.33.176) port 80 (#0)
> GET /citrix-app/ HTTP/1.1
> Host: app.cic-citrix.org
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.8.1
< Date: Fri, 29 Mar 2019 11:14:04 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< X-Powered-By: PHP/5.5.9-1ubuntu4.14
< x-port: 22481 ==================> NEW RESPONSE HEADER
< x-ip:10.102.33.176 ==================> NEW RESPONSE HEADER
< x-new-dummy-header: Sending_a_gift ==================> NEW RESPONSE HEADER
<
&lt;html>
&lt;head>
&lt;title> Front End App - v1 &lt;/title>


TRIMMED
.......

HTTPレスポンスパケットにカスタムヘッダーを追加

リライトポリシーを使用すると、マイクロサービスからクライアントへのHTTPレスポンスにカスタムヘッダーを追加できます。
次のサンプルリライトポリシー定義は、カスタムヘッダーをマイクロサービスからクライアントへのHTTPレスポンスに追加します。
apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: addcustomheaders
spec:
  rewrite-policies:
    - servicenames:
        - frontend
      rewrite-policy:
        operation: insert_before_all
        target: http.res.full_header
        modify-expression: '"\r\nx-request-time:"+sys.time+"\r\nx-using-citrix-ingress-controller: true"'
        multiple-occurence-modify: 'text("\r\n\r\n")'
        comment: 'Adding custom headers'
        direction: RESPONSE
        rewrite-criteria: 'http.req.is_valid'
リライトポリシー定義を含むYAMLファイル (add_custom_headers.yaml) を作成し、次のコマンドを使用してYAMLファイルをデプロイします。
kubectl create -f add_custom_headers.yaml
レスポンスに追加されたカスタムHTTPヘッダーは、次のように確認できます。
$ curl -vvv http://app.cic-citrix.org/
* Trying 10.102.33.176...
* TCP_NODELAY set
* Connected to app.cic-citrix.org (10.102.33.176) port 80 (#0)
> GET / HTTP/1.1
> Host: app.cic-citrix.org
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.8.1
< Date: Fri, 29 Mar 2019 12:15:09 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< X-Powered-By: PHP/5.5.9-1ubuntu4.14
< x-request-time:Fri, 29 Mar 2019 13:27:40 GMT =============> NEW HEADER ADDED
< x-using-citrix-ingress-controller: true  ===============> NEW HEADER ADDED
<
&lt;html>
&lt;head>
&lt;title> Front End App - v1 &lt;/title>
&lt;style>

TRIMMED
........

リクエスト内のホスト名を置き換える

次のYAML例 (http_request_modify_prefixasprefix.yaml) に示すようにリライトポリシーを定義して、要件に応じてHTTPリクエストのホスト名を置き換えることができます。
apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: httpheadermodifyretainprefix
spec:
  rewrite-policies:
    - servicenames:
        - frontend
      rewrite-policy:
        operation: replace_all
        target: 'http.req.header("host")'
        modify-expression: '"citrix-service-app"'
        multiple-occurence-modify: 'text("app.cic-citrix.org")'
        comment: 'HTTP header rewrite of hostname'
        direction: REQUEST
        rewrite-criteria: 'http.req.is_valid'
リライトポリシー定義を含むYAMLファイル (http_request_modify_prefixasprefix.yaml) を作成し、以下のコマンドを使用してYAMLファイルをデプロイします。
kubectl create -f http_request_modify_prefixasprefix.yaml
curl コマンドを使用してポリシー定義を検証できます。リクエスト内のホスト名は、定義されたホスト名に置き換えられます。
curl http://app.cic-citrix.org/prefix/foo/bar
出力: ホスト名を置き換える

アプリケーションルートの変更

既存のアプリケーションルートが/の場合、アプリケーションルートを変更するリライトポリシーを定義できます。
次のサンプルリライトポリシーは、リクエストURLの/を/citrix-approot/に変更します。
apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
 name: httpapprootrequestmodify
spec:
 rewrite-policies:
   - servicenames:
       - frontend
     rewrite-policy:
       operation: replace
       target: http.req.url
       modify-expression: '"/citrix-approot/"'
       comment: 'HTTP app root request modify'
       direction: REQUEST
       rewrite-criteria: http.req.url.eq("/")
リライトポリシー定義を含むYAMLファイル (http_approot_request_modify.yaml) を作成し、以下のコマンドを使用してYAMLファイルをデプロイします。
kubectl create -f http_approot_request_modify.yaml
curl コマンドを使用して、要件に応じてアプリケーションルートが変更されたかどうかを検証できます。
curl -vvv http://app.cic-citrix.org/
出力:
アプリルートの変更

リクエストされたURL内の文字列を変更する

要件に応じて、リクエストされたURL内の文字列を変更するリライトポリシーを定義できます。
次のサンプルリライトポリシーは、リクエストされたURL内の文字列somethingをsimpleに置き換えます。
apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
name: httpurlreplacestring
spec:
rewrite-policies:
 - servicenames:
     - frontend
   rewrite-policy:
     operation: replace_all
     target: http.req.url
     modify-expression: '"/"'
     multiple-occurence-modify: 'regex(re~((^(\/something\/))|(^\/something$))~)'
     comment: 'HTTP url replace string'
     direction: REQUEST
     rewrite-criteria: http.req.is_valid
リライトポリシー定義を含むYAMLファイル (http_url_replace_string.yaml) を作成し、以下のコマンドを使用してYAMLをデプロイします。
kubectl create -f http_url_replace_string.yaml
curl リクエストと文字列 something を使用してポリシー定義を検証できます。文字列 something は、次の例に示すように文字列 simple に置き換えられます。
例 1:
curl http://app.cic-citrix.org/something/simple/citrix
出力:
文字列を置換
例 2:
curl http://app.cic-citrix.org/something
または、,
curl http://app.cic-citrix.org/something/
出力:
文字列を置換

HTTP リクエスト内に X-Forwarded-For ヘッダーを追加する

HTTP リクエスト内に X-Forwarded-For ヘッダーを追加するには、次の YAML 例 (http_x_forwarded_for_insert.yaml) に示すようにリライトポリシーを定義できます。
apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: httpxforwardedforaddition
spec:
  rewrite-policies:
    - servicenames:
        - frontend
      rewrite-policy:
        operation: insert_http_header
        target: X-Forwarded-For
        modify-expression: client.ip.src
        comment: 'HTTP Initial X-Forwarded-For header add'
        direction: REQUEST
        rewrite-criteria: 'HTTP.REQ.HEADER("X-Forwarded-For").EXISTS.NOT'

    - servicenames:
        - frontend
      rewrite-policy:
        operation: replace
        target: HTTP.REQ.HEADER("X-Forwarded-For")
        modify-expression: 'HTTP.REQ.HEADER("X-Forwarded-For").APPEND(",").APPEND(CLIENT.IP.SRC)'
        comment: 'HTTP Append X-Forwarded-For IPs'
        direction: REQUEST
        rewrite-criteria: 'HTTP.REQ.HEADER("X-Forwarded-For").EXISTS'
リライトポリシー定義を含む YAML ファイル (http_x_forwarded_for_insert.yaml) を作成し、次のコマンドを使用して YAML ファイルをデプロイします。
kubectl create -f http_x_forwarded_for_insert.yaml
curl コマンドを使用して、X-Forwarded-For ヘッダーの有無にかかわらず HTTP パケットを検証できます。
例: X-Forwarded-For ヘッダーなしの HTTP リクエストパケットの出力:
curl http://app.cic-citrix.org/
出力:
Curl 出力
例：X-Forwarded-Forヘッダーを含むHTTPリクエストパケットの出力：
curl  curl --header "X-Forwarded-For: 1.1.1.1" http://app.cic-citrix.org/
出力：
Curl出力

レスポンダーポリシーを使用してHTTPリクエストをHTTPSリクエストにリダイレクトする

HTTPリクエストをHTTPSリクエストにリダイレクトするには、次のYAMLの例(http_to_https_redirect.yaml)に示すように、レスポンダーポリシー定義を定義できます。
apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: httptohttps
spec:
  responder-policies:
    - servicenames:
        - frontend
      responder-policy:
        redirect:
          url: '"https://" +http.req.HOSTNAME.SERVER+":"+"443"+http.req.url'
        respond-criteria: 'http.req.is_valid'
        comment: 'http to https'
レスポンダーポリシー定義を含むYAMLファイル(http_to_https_redirect.yaml)を作成し、次のコマンドを使用してYAMLファイルをデプロイします。
kubectl create -f http_to_https_redirect.yaml
HTTPリクエストがHTTPSにリダイレクトされているかどうかは、次のように確認できます。
例1：
$ curl -vvv  http://app.cic-citrix.org
* Rebuilt URL to: http://app.cic-citrix.org/
*   Trying 10.102.33.176...
* TCP_NODELAY set
* Connected to app.cic-citrix.org (10.102.33.176) port 80 (#0)
> GET / HTTP/1.1
> Host: app.cic-citrix.org
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 302 Found : Moved Temporarily
< Location: https://app.cic-citrix.org:443/   =======> Redirected to HTTPS
< Connection: close
< Cache-Control: no-cache
< Pragma: no-cache
<
* Closing connection 0
例2：
$ curl -vvv  http://app.cic-citrix.org/simple
*   Trying 10.102.33.176...
* TCP_NODELAY set
* Connected to app.cic-citrix.org (10.102.33.176) port 80 (#0)
> GET /simple HTTP/1.1
> Host: app.cic-citrix.org
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 302 Found : Moved Temporarily
< Location: https://app.cic-citrix.org:443/simple     ========> Redirected to HTTPS
< Connection: close
< Cache-Control: no-cache
< Pragma: no-cache
<
* Closing connection 0

リクエストされたURL内の文字列とホスト名を変更する

この例では、goto-priority-expression属性の使用方法を示します。goto-priority-expressionフィールドの使用ガイドラインは、で確認できます。この例では、URL http://www.citrite.org/something/simple/citrixをhttp://app.cic-citrix.org/simple/citrixに変更します。
URLを変更するために、2つのリライトポリシーが記述されています。
  • リライトポリシー1：このポリシーは、ホスト名www.citrite.orgをapp.cic-citrix.orgに変更するために使用されます。
  • リライトポリシー2：このポリシーは、URL /something/simple/citrixを/simple/citrixに変更するために使用されます。
次のYAMLに示すように、goto-priority-expression属性を使用して2つのポリシーをバインドできます。
apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: hostnameurlrewrite
spec:
  rewrite-policies:
    - servicenames:
        - citrix-svc
      goto-priority-expression: NEXT
      rewrite-policy:
        operation: replace_all
        target: 'http.req.header("host")'
        modify-expression: '"app.cic-citrix.org"'
        multiple-occurence-modify: 'text("www.citrite.org")'
        comment: 'HTTP header rewrite of hostname'
        direction: REQUEST
        rewrite-criteria: 'http.req.is_valid.and(HTTP.REQ.HOSTNAME.EQ("www.citrite.org"))'
    - servicenames:
        - citrix-svc
      goto-priority-expression: END
      rewrite-policy:
        operation: replace_all
        target: http.req.url
        modify-expression: '"/"'
        multiple-occurence-modify: 'regex(re~((^(\/something\/))|(^\/something$))~)'
        comment: 'HTTP url replace string'
        direction: REQUEST
        rewrite-criteria: 'http.req.is_valid.and(HTTP.REQ.HOSTNAME.EQ("www.citrite.org"))'`

検証

以下のcurlリクエスト http://www.citrite.org/something/simple/citrix が http://app.cic-citrix.org/simple/citrix に変更されたかどうかを確認できます。
例: 要求されたURLの変更
curl http://www.citrite.org/something/simple/citrix
要求されたURLの変更されたホスト名とURLは、以下に示す画像に表示されています。
Curl 出力

HTTPコールアウト

HTTPコールアウトを使用すると、NetScalerはポリシー評価の一部として外部サーバーにHTTPまたはHTTPSリクエストを生成して送信し、外部サーバーから取得した応答に基づいて適切なアクションを実行できます。リライトおよびレスポンダーCRDを使用して、NetScalerからHTTPコールアウトリクエストを開始できます。詳細については、HTTPコールアウトのドキュメント を参照してください。

関連資料