リバースプロキシの使用
このページでは、リバースプロキシの背後にあるコントローラの設定方法について説明します。
Reverse Proxy Architectures
The Splunk AppDynamics On-Premises Controller is often deployed behind a reverse proxy. The proxy presents a virtual IP address to external connections, such as agents and browser clients. The proxy often resides in the DMZ for the network, where it terminates SSL connections from external clients.
The proxy provides a security layer for the Controller, but it also enables you to move a Controller to another machine or switch between high availability pairs without having to reconfigure agents.
The following diagram illustrates the scenario:
As shown, the reverse proxy listens for incoming requests on a given path, /controller in this case, on port 80. It forwards matching requests to the HTTP listening port of the primary Controller at appdhost1:8090.
In terms of network impact in this scenario, switching active Controllers from the primary to the secondary in this scenario only requires the administrator to update the routing policy at the proxy so that traffic directed to the secondary instead of the primary.
These instructions describe how to set up the Controller with a reverse proxy. They also provide sample configurations for a few specific types of proxies, including NGINX and Apache Web Server.
This information is intended for illustration purposes only. The configuration requirements for your own deployment are likely to vary depending on your existing environment, the applications being monitored, and the policies of your organization.
While Splunk AppDynamics On-Premises supports Controllers that are deployed with a reverse proxy, Splunk AppDynamics Support cannot guarantee help with specific set up questions and issues particular for your environment or the type of proxy you are using. For this type of information, please consult the documentation provided with your proxy technology. Alternatively, ask the Cisco AppDynamics Community.
一般的なガイドライン
以下では、リバースプロキシを使用した Splunk AppDynamics オンプレミスコントローラとアプリケーションエージェントのデプロイメントに関する一般的な要件、考慮事項、機能を説明しています。
-
JVM のディープリンクオプション
Dappdynamics.controller.ui.deeplink.urlの値を、コントローラの URL に設定します。以下の形式で、コントローラホストのホスト名か IP アドレス(クライアントに直接アクセス可能な場合)、またはプロキシで公開されているコントローラ用 VIP を使用してください。modifyJvmOptions add ‑Dappdynamics.controller.ui.deeplink.url=http[s]://controller.corp.example.com[:port]/controller
ご使用のコントローラに適したURIスキーム(httpまたはhttps)、ホスト名、ポート番号を使用してください。コントローラはディープリンクの値を使用して、UI で公開する URL を構成します。
-
プロキシで SSL を終了する場合、次の JVM オプションも設定します。
-Dappdynamics.controller.services.hostName=<external_DNS_hostname> -Dappdynamics.controller.services.port=<external_port_usually_443>
- 設定内容を保持するには、Enterprise ConsoleのController SettingsページでJVMオプションを編集する必要があります。詳細については、「Update Platform Configurations」を 参照してください。
- プロキシがアプリケーションの監視対象階層間にある場合、Splunk AppDynamics がトラフィック相関に追加するカスタムヘッダー(singularity ヘッダー)をプロキシが通過することを確認します。大部分のプロキシはデフォルトでカスタムヘッダを通過します。
- アプリケーションエージェントの場合、コントローラホストとコントローラポートの接続設定は、リバースプロキシでコントローラ用に公開されているVIPまたはホスト名、およびポートを指している必要があります。詳細については、「エージェントとコントローラの接続」を参照してください。
- エージェントからプロキシにSSLを使用する場合は、アプリケーションエージェントとプロキシ間で使用されるセキュリティプロトコルに互換性があることを確認します。エージェントの各バージョンで使用されるSSLプロトコル用の互換性表を参照してください。
-
プロキシ(またはその他のネットワークデバイス)がコントローラの可用性を確認する必要がある場合、コントローラ REST リソース(
http://<host>:<port>/controller/rest/serverstatus)を使用できます。コントローラがアクティブ、高可用性モード、かつプライマリである場合、この REST リソースは次のような XML の応答を返します。<serverstatus vendorid="" version="1"> <available>true</available> <serverid/> <serverinfo> <vendorname>AppDynamics</vendorname> <productname>AppDynamics Application Performance Management</productname> <serverversion>003-008-000-000</serverversion> </serverinfo> </serverstatus>
コントローラが待機モードの場合、このリソースは503応答を返します。
以下のセクションでは、Nginx や Apache Web Server など、特殊なプロキシの備考とサンプル構成を紹介します。
シンプルなHTTPリバースプロキシとしてNginxを使用する
Nginx は、http://nginx.org/ で入手可能な、広く使われている Web サーバーかつリバースプロキシです。
コントローラのリバースプロキシとしてNginxを使用するには、Nginxの構成にアップストリームサーバーとしてコントローラを追加するだけです。高可用性のペア構成に 2 つのコントローラをデプロイする場合は、アップストリームサーバの定義にプライマリコントローラとセカンダリコントローラのアドレス両方を追加します。
次の手順では、上位レベルでのセットアップを説明します。すでにコントローラのインストールを完了し、Nginx インスタンスを持ち、既存の構成を変更して、Nginx にトラフィックをコントローラにルーティングさせるのみという状況を想定しています。
Nginxリバースプロキシを経由してコントローラのトラフィックをルーティングするには-
-Dappdynamics.controller.ui.deeplink.urlという名前の JVM オプションを追加します。このオプションの値は、上記ガイドラインにあるようにコントローラのURLに設定します。 -
コントローラをシャットダウンします。
-
プロキシで SSL を終了する場合は、
-Dappdynamics.controller.services.hostNameと-Dappdynamics.controller.services.portJVM オプションもコントローラの外部 DNS ホスト名と外部ポート番号(通常 443)に設定します。 -
リバースプロキシマシンの Nginx ホームディレクトリで、編集のために
conf/nginx.confファイルを開きます。 -
構成ファイルで、アップストリームサーバーとして各コントローラを指定するクラスタ定義を追加します。たとえば、サンプルでは、コントローラは 127.0.15.11 に存在し、完全修飾ドメイン名は appdcontroller.example.com です。
upstream appdcontroller { server 127.0.15.11:8090 fail_timeout=0; } server { listen 80; server_name appdcontroller.example.com; expires 0; add_header Cache-Control private; location / { proxy_set_header Host $host; proxy_set_header X-Real- IP $remote_addr; proxy_set_header X-Forwarded-Proto https; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://appdcontroller; } } -
Nginxサーバーを再起動し、変更を適用します。
-
コントローラを再起動します。
コントローラは起動後、Nginxを経由してトラフィックを受信する必要があります。接続の最初のテストとして、プロキシを経由して、つまりブラウザでコントローラUIを開き、 http://<virtualip>:80/controller に移動します。
コントローラは起動後、Nginxを経由してトラフィックを受信する必要があります。接続の最初のテストとして、プロキシ経由でコントローラー UI を開いてみます。つまり、ブラウザで、上記の一般的なガイドラインに従って http://<virtualip>:80/controller に移動します。リバースプロキシとしてApacheを使用する
リバースプロキシとして Apache を使用するには、適切な Apache モジュールがインストールされ、Apache インスタンスで有効になっている必要があります。HTTP プロキシの場合、これは通常 mod_proxy_http になります。mod_proxy_http モジュールでは、HTTP または HTTPS を使用するプロキシ接続がサポートされています。
-
-Dappdynamics.controller.ui.deeplink.urlという名前の JVM オプションを追加します。このオプションの値は、上記ガイドラインにあるようにコントローラのURLに設定します。 -
コントローラをシャットダウンします。
-
プロキシで SSL を終了する場合は、
-Dappdynamics.controller.services.hostNameと-Dappdynamics.controller.services.portJVM オプションもコントローラの外部 DNS ホスト名と外部ポート番号(通常 443)に設定します。 -
Apacheを実行するマシンで、次のコマンドを実行して、Apacheインスタンスにより必要なモジュールがすでにアップロードされていることを確認します。
apache2ctl -M
出力で、次のようなプロキシモジュールを探します。このproxy_module (shared) proxy_http_module (shared)
proxy_moduleは、proxy_module_httpに依存しています。 -
必須モジュールがロードされていない場合は、Apacheのディストリビューションに応じてApacheモジュールを有効化します。たとえば、Debian/Ubuntu では次の手順を実行します。
-
次のように入力します:
sudo a2enmod proxy_http
-
Apacheを再起動します。
sudo service apache2 restart
-
-
Apache にプロキシ設定を追加します。たとえば、プロキシホストの標準 Web ポート 80 へのクライアントリクエストを、コントローラに移動させる構成は次のようになります。
<Proxy *> Order deny,allow Allow from all </Proxy> ProxyRequests オフ ProxyPreserveHost オン ProxyPass / http://controller.example.com:8090/controller ProxyPassReverse / http://controller.example.com:8090/controller
-
Apacheモジュールをリロードして、構成の変更を適用します。たとえば、次のように入力します。
sudo service apache2 reload
-
コントローラを起動します。
リバースプロキシでのSSLの終了を構成する
このセクションでは、クライアント側のプロキシ接続でプロキシで終了される SSL を使用している場合のセキュリティの設定方法を説明しています。これは、プロキシとコントローラが安全なデータセンターにあり、アプリケーション エージェントまたは UI ブラウザのクライアント接続が、安全でない可能性があるネットワークから行われている場合を想定しています。
プロキシでSSLを終了すると、コントローラからプロキシへのSSL処理の負荷を取り除くことができます。コントローラを大規模で高負荷の環境にデプロイする場合に、この構成を推奨しています。プロキシで SSL を終了することには、セキュリティ証明書とキーの管理をデータセンターに集約できるという利点もあります。
このセクションでは、Nginx のサンプル構成を提示していますが、その概念は他の種類のリバースプロキシにもつながります。
SSL終了用プロキシを構成する
リバースプロキシでSSLの終了を実行するには、次の手順を行う必要があります。
- アプリケーションエージェントが、プロキシを使用して安全な接続を確立できることを確認します。エージェントの各バージョンの SSL 設定については、「エージェントとコントローラの互換性」を参照してください。プロキシに、エージェントが信頼する機関により署名されたサーバー証明書が含まれていることを確認します。含まれていない場合、プロキシマシンのサーバキーをインストールする必要があります。
- ご使用の環境で、.NET アプリケーション エージェントを使用している場合、リバースプロキシサーバが証明機関(CA)が署名したサーバ証明書を使用していることを確認します。.NET アプリケーション エージェントでは、自己署名サーバ証明書に基づいた SSL 接続は許可されません。
- プロキシとコントローラ間のトラフィックをプロキシとクライアント間の安全なポートに転送するように、プロキシを構成します。
- この構成のクライアント アプリケーション エージェントとブラウザクライアントは、コントローラとの通信に安全なポート(つまりプロキシ)を使用する必要があります。説明にあるように、コントローラ上で混合チャネルを構成すると、エージェントは安全なポートを使用している場合と同じように動作するため、エージェントが安全なポートのみを使用するようにしてください。
コントローラの SSL 終了を実行する Nginx を使用した構成の例は、次のようになります。
upstream appdcontroller {
server 127.0.15.11:8191 fail_timeout=0;
}
server {
listen 80;
server_name appdcontroller.example.com;
return 301 https://$host$request_uri;
}
server {
listen 443;
server_name appdcontroller.example.com;
ssl on;
ssl_certificate /etc/nginx/server.crt;
ssl_certificate_key /etc/nginx/server.key);
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+EXP;
ssl_prefer_server_ciphers on;
expires 0;
add_header Cache-Control private;
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_redirect http:// https://;
proxy_pass http://appdcontroller;
}
}
この例は、ssl_certificate_key ssl_certificate のシンプルなパススルーの例で示されている構成に基づいています。この例では、非SSLポート80が受信したリクエストはポート443にルーティングされます。ポート443のサーバーには、SSL終了の設定が含まれています。値は、
この構成は、接続に対して受け入れられる SSL プロトコルと暗号方式も示しています。「エージェントとコントローラの互換性」のページで説明されているように、セキュリティ設定は Splunk AppDynamics アプリケーション エージェントのセキュリティ機能と互換性がある必要があります。
Cookieセキュリティ
コントローラは、HTTPS を介して送信された X-CSRF-TOKEN Cookie に Secure フラグを立てます。Secureフラグにより、クライアントは安全な接続上のみでCookieを送信します。
コントローラの手前のリバースプロキシで HTTPS を終了する場合は、コントローラへの接続が HTTP で起こるため、デフォルトでコントローラは Cookie のセキュリティを設定しません。
Cookie セキュリティを確保するには、Secure ステートメントが set-cookie ステートメントに含まれるようにリバースプロキシを構成します。セキュアフラグを追加する方法は、使用するリバースプロキシのタイプによって異なります。
次に、HAProxy を使用して Cookie セキュリティを設定する例を示します。
-
HAProxy バージョン 2.0 以前を使用している場合は、次のように入力します。
rspirep ^(set-cookie:.*) \ 1 ;\ Secure
-
HAProxy バージョン 2.1 以降を使用している場合は、次のように入力します。
>acl secured_cookie res.hdr(Set-Cookie),lower -m sub securehttp-response replace-header Set-Cookie (.*) \1;\ Secure if !secured_cookie
リバースプロキシからコントローラへSSLを使用する
SSLを使用してプロキシをコントローラに接続するには、プロキシの構成を少々変更する必要があります。バックエンドまたはアップストリームサーバーに接続するプロトコルとしてHTTPSの使用を指定するだけです。つまり、Nginx の構成については、次のように proxy_pass 値を変更するだけです。
proxy_pass https://appdcontroller;
「コントローラ SSL と証明書」にあるように、コントローラ上で SSL を構成したことを確認して、構成を完了します。