一般的なアプリケーション ルールは次のとおりです。

条件に基づく HTTP/HTTPS のリダイレクト

アプリケーション プロファイルでは、要求 URL に関係なく常にトラフィックをリダイレクトする、HTTP/HTTPS のリダイレクトを指定できます。また、HTTP/HTTPS トラフィックをリダイレクトする条件を柔軟に指定できます。 
move the login URL only to HTTPS. 
acl clear dst_port 80
acl secure dst_port 8080
acl login_page url_beg /login 
acl logout url_beg /logout 
acl uid_given url_reg /login?userid=[^&]+ 
acl cookie_set hdr_sub(cookie) SEEN=1
redirect prefix https://mysite.com set-cookie SEEN=1 if !cookie_set
redirect prefix https://mysite.com if login_page !secure
redirect prefix http://mysite.com drop-query if login_page !uid_given
redirect location http://mysite.com/ if !login_page secure
 redirect location / clear-cookie USERID= if logout

ドメイン名によるルーティング

ドメイン名に応じて要求を特定のロード バランサ プールにダイレクトするアプリケーション ルールを作成できます。次のルールは、foo.com への要求を pool_1 に、bar.com への要求を pool_2 にダイレクトします。 
acl is_foo hdr_dom(host) -i foo
  acl is_bar hdr_dom(host) -i bar
  use_backend pool_1 if is_foo
  use_backend pool_2  if is_bar

Microsoft RDP のロード バランシングおよび保護

次のサンプル シナリオでは、ロード バランサが負荷の少ないサーバに新しいユーザーを分散し、切断されたセッションを再開します。このシナリオでは、NSX Edge の内部インターフェイス IP アドレスが 10.0.0.18、内部インターフェイス IP アドレスが 192.168.1.1、仮想サーバが 192.168.1.100、192.168.1.101、192.168.1.102 になります。
  1. MSRDP セッション維持を含む TCP トラフィックのアプリケーション プロファイルを作成します。
  2. TCP 健全性モニター (tcp_monitor) を作成します。
  3. 192.168.1.100:3389、192.168.1.101:3389、192.168.1.102:3389 をメンバーとする（rdp-pool という名前の）プールを作成します。
  4. tcp_monitor を rdp-pool に関連付けます。
  5. 次のアプリケーション ルールを作成します。 
    tcp-request content track-sc1 rdp_cookie(mstshash) table rdp-pool
tcp-request content track-sc2 src table ipv4_ip_table
 
#   each single IP can have up to 2 connections on the VDI infrastructure
tcp-request content reject if { sc2_conn_cur ge 2 }

#   each single IP can try up to 5 connections in a single minute
tcp-request content reject if { sc2_conn_rate ge 10 }

# Each user is supposed to get a single active connection at a time, block the second one
tcp-request content reject if { sc1_conn_cur ge 2 }

# if a user tried to get connected at least 10 times over the last minute, 
# it could be a brute force
tcp-request content reject if { sc1_conn_rate ge 10 }
  6. （rdp-vs という名前の）仮想サーバを作成します。
  7. アプリケーション プロファイルをこの仮想サーバに関連付け、手順 4 で作成したアプリケーション ルールを追加します。

仮想サーバで新規に適用されるアプリケーション ルールは、RDP サーバを保護します。

高度なログ

NSX ロード バランサは、デフォルトで基本的なログ作成をサポートしています。トラブルシューティングで、より詳細なログ メッセージを表示するには、次のようなアプリケーション ルールを作成します。 
 # log the name of the virtual server
 capture request  header Host len 32

 # log the amount of data uploaded during a POST
 capture request  header Content-Length len 10
# log the beginning of the referrer
capture request  header Referer len 20

# server name (useful for outgoing proxies only)
capture response header Server len 20

# logging the content-length is useful with "option logasap"
capture response header Content-Length len 10

# log the expected cache behaviour on the response
capture response header Cache-Control len 8

# the Via header will report the next proxy's name
 capture response header Via len 20

# log the URL location during a redirection
capture response header Location len 20
アプリケーション ルールを仮想サーバに関連付けると、ログには次の例のように、詳細なメッセージが記載されます。 
2013-04-25T09:18:17+00:00 edge-187 loadbalancer[18498]: [org1]: 10.117.7.117 - - [25/Apr/2013:09:18:16 +0000] "GET /favicon.ico HTTP/1.1" 404 1440 "" "" 51656 856 "vip-http-complete" 
"pool-http-complete" "m2" 145 0 1 26 172 --NI 1 1 0 0 0 0 0 "" "" "10.117.35.187" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 
(KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31" "Apache/2.2.15 (Linux" ""

2013-04-25T09:18:17+00:00 edge-187 loadbalancer[18498]: [org1]: 10.117.7.117 - - [25/Apr/2013:09:18:16 +0000] "GET /favicon.ico HTTP/1.1" 404 1440 "" "" 51657 856 "vip-http-complete" 
"pool-http-complete" "m2" 412 0 0 2 414 --NI 0 0 0 0 0 0 0 "" "" "10.117.35.187" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 
(KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31" "Apache/2.2.15 (Linux" ""
HTTPS トラフィックのトラブルシューティングでは、複数のルールが必要になる場合があります。ほとんどの Web アプリケーションでは、（通常、ログインまたは POST 呼び出しの後に）クライアントをページにリダイレクトするロケーション ヘッダの付いた 301/302 応答を使用します。また、アプリケーションの Cookie が必要です。そのため、アプリケーション サーバがクライアントの接続情報を認識することが難しい場合や、適切に応答できない場合があります。また、アプリケーションが機能しなくなる場合もあります。
Web アプリケーションで SSL オフロードをサポートするには、次のルールを追加します。 
# See clearly in the log if the application is setting up response for HTTP or HTTPS
capture response header Location   len 32
capture response header Set-Cookie len 32

# Provide client side connection info to application server over HTTP header
http-request set-header X-Forwarded-Proto https if  { ssl_fc }
http-request set-header X-Forwarded-Proto http  if !{ ssl_fc }
SSL 経由で接続される場合は、ロード バランサにより次のヘッダが挿入されます。 
X-Forwarded-Proto: https
HTTP 経由で接続される場合は、ロード バランサにより次のヘッダが挿入されます。 
X-Forwarded-Proto: http

特定の URL のブロック

URL に特定のキーワードが含まれる要求をブロックできます。次のサンプル ルールは、要求が /private または /finance で始まるかどうかを確認して、これらのキーワードを含む要求をブロックします。 

# Check if the request starts with "/private" or "/finance" (case insensitive)
acl block_url_list path_beg -i /private /finance

# If the request is part of the list forbidden urls,reply "Forbidden"(HTTP response code
 403)
http-request deny if block_url_list

Cookie を含まない場合の認証への　HTTP リダイレクト

Cookie を含まないクライアント要求が認証を受けるようにリダイレクトできます。次のサンプル ルールは、HTTP 要求が信頼できるものであり、Cookie をヘッダーに含んでいることを確認します。要求が Cookie を含まない場合、ルールは要求が認証を受けるように /authent.php にリダイレクトします。 

acl authent_url url /authent.php
acl cookie_present hdr_sub(cookie) cookie1=
redirect prefix /authent.php if !authent_url !cookie_present

デフォルト ページへのリダイレクト

クライアント要求 / をデフォルトのページにリダイレクトできます。次のサンプル ルールは、HTTP 要求が / であるかどうかを確認して、そのような要求をデフォルトのログイン ページにリダイレクトします。

acl default_url url /
redirect location /login.php if default_url

メンテナンス サイトへのリダイレクト

プライマリ プールがダウンしているときに、メンテナンス サーバ プールを使用して、URL をメンテナンス Web サイトにリダイレクトできます。 

redirect location http://maitenance.xyz.com/maintenance.htm

NT LAN Manager (NTLM) 認証

デフォルトでは、NSX は各要求の後に TCP 接続をサーバ側で終了します。各要求の後にサーバ セッションを終了しないようにする場合、NTLM プロトコルを使用することで、サーバ セッションを保持および保護できます。 

no option http-server-close

デフォルトでは、NSX は各要求の間に確立された TCP 接続を、クライアント側で維持します。ただし「X-Forwarded-For」オプションが設定されている場合は、セッションは各要求の後に終了します。次のオプションでは、XFF が設定されている場合でも、各要求間でクライアント接続が開かれた状態が維持されます。 

no option httpclose

サーバ ヘッダーの置き換え

既存の応答サーバ ヘッダーを削除して、別のサーバに置き換えることができます。次のサンプル ルールは、サーバ ヘッダーを削除して NGINX Web サーバに置き換えます。NGINX Web サーバは、HTTP、HTTPS、SMTP、POP3 および IMAP プロトコルのリバース プロキシ サーバ、HTTP キャッシュ、およびロード バランサとして機能することが可能です。 

rspidel Server
rspadd Server:\ nginx

リダイレクトの書き換え

ロケーション ヘッダーを HTTP から HTTPS に書き換えることができます。次のサンプル ルールは、ロケーション ヘッダーを特定して、HTTP を HTTP に置き換えます。 

rspirep ^Location:\ http://(.*)  Location:\ https://\1

ホスト ベースの特定プールの選択

特定のホストが指定された要求を、定義されたプールにリダイレクトできます。次のサンプル ルールは、特定のホスト（app1.xyz.com、app2.xyz.com、host_any_app3）が指定された要求を確認して、これらの要求をそれぞれに定義されたプール（pool_app1、pool_app2、pool_app3）にリダイレクトします。その他すべての要求は、仮想サーバに定義された既存のプールにリダイレクトされます。 

acl host_app1 hdr(Host) -i app1.xyz.com
acl host_app2 hdr(Host) -i app2.xyz.com
acl host_any_app3 hdr_beg(host) -i app3

各ホスト名で特定のプールを使用します。 

use_backend pool_app1 if host_app1
use_backend pool_app2 if host_app2
use_backend pool_app3 if host_any_app3

URL に基づく特定プールの選択

URL キーワードが指定された要求を、特定のプールにリダイレクトできます。次のサンプル ルールは、要求が /private または /finance で始まるかどうかを確認して、これらの要求を定義されたプール（pool_private または pool_finance）にリダイレクトします。その他すべての要求は、仮想サーバに定義された既存のプールにリダイレクトされます。 

acl site_private path_beg -i /private
acl site_finance path_beg -i /finance
use_backend pool_private if site_private
use_backend pool_finance if site_finance

プライマリ プールがダウンしている場合のリダイレクト

プライマリ プールのサーバがダウンしている場合に、セカンダリ プールのサーバを使用するようにユーザーをリダイレクトできます。次のサンプル ルールは、pool_production がダウンしているかどうかを確認して、ユーザーを pool_sorry_server に転送します。 

acl pool_production_down nbsrv(pool_production) eq 0
use_backend pool_sorry_server if pool_production_down

TCP 接続のホワイトリスト

クライアント IP アドレスがサーバにアクセスしないようにブロックできます。次のサンプル ルールでは、定義された IP アドレスをブロックし、クライアントの IP アドレスがホワイトリストに含まれていない場合に接続をリセットします。 

acl whitelist src 10.10.10.0 20.20.20.0
tcp-request connection reject if !whitelist

SSLv3 と TLSv1 を有効にする

デフォルトでは、SSLv3 と TLSv1 は無効に設定されているサービス モニター エクステンションです。次のアプリケーション ルールを使用して、これらを有効にすることができます。 

sslv3 enable
tlsv1 enable

クライアントのセッション タイムアウト設定

セッション タイムアウトとは、クライアント接続が非アクティブ状態になった場合の最長期限のことです。非アクティブ状態のタイムアウトは、想定していたクライアントからのデータが確認または送信されない場合に適用されます。HTTP モードでは、クライアントが要求を送信する最初の段階、およびサーバから送信されたデータをクライアントが読み取る応答時に、このタイムアウトを考慮することが特に重要です。デフォルトのタイムアウトは、5 分間です。

次のサンプル ルールでは、タイムアウト期間を 100 秒に設定します。 

timeout client 100s

時間は、ミリ秒、秒、分、時間、または日を単位として整数で設定できます。

HTTPS サイトへのリダイレクト

HTTP にアクセスするクライアントを HTTPS の同じページにリダイレクトできます。 

# Redirect all HTTP requests to same URI but HTTPS redirect scheme
https if !{ ssl_fc }

他のオプションは次のとおりです。 

rspirep ^Location:\ http://(.*) Location:\ https://\1

認証されないクライアントのリダイレクト

Cookie のないクライアント要求は "/authent.php" にリダイレクトします。 

# Check the HTTP request if request is "/authent.php"
acl authent_url url /authent.php
# Check the cookie "cookie1" is present
acl cookie_present hdr_sub(cookie) cookie1=
# If the request is NOT "/authent.php" and there is no cookie, then redirect to "/authent.php"
redirect prefix /authent.php if !authent_url !cookie_present

HTTP 応答ヘッダの書き換え

応答サーバ ヘッダ "Server" を値 "nginx" に書き換えます。 

# Delete the existing Response Server header "Server"
rspidel Server
# Add the Response Server header "Server" with the value "nginx"
rspadd Server:\ nginx

Sorry サーバ

プライマリ プール内のサーバがすべて停止している場合は、セカンダリ プール内のサーバを使用します。 

# detect if pool "pool_production" is still up
acl pool_production_down nbsrv(pool_production) eq 0
# use pool "pool_sorry_server" if "pool_production" is dead
use_backend pool_sorry_server if pool_production_down
# Option 1: # Redirect everything to maintenance site
redirect location http://maintenance.xyz.com/maintenance.htm
# Option 2: #Use a specific maintenance server pool and rewrite all URLs to maintenance.php
acl match_all always_true
use_backend maint_pool if match_all
reqirep ^GET\(.*)\HTTP/(.*) GET\ /maintenance.php\ HTTP/\2