リバースプロキシの使用
このページでは、リバースプロキシの背後にあるコントローラの設定方法について説明します。
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.
General Guidelines
The following describes general requirements, considerations, and features for deploying the Splunk AppDynamics On-Premises Controller and App Agents with a reverse proxy.
-
Set the deep link JVM option,
-Dappdynamics.controller.ui.deeplink.url, to the value of the Controller URL. Use either the hostname or IP address of the Controller host (if directly accessible to clients) or to the VIP for the Controller as exposed at the proxy in the following format:modifyJvmOptions add ‑Dappdynamics.controller.ui.deeplink.url=http[s]://controller.corp.example.com[:port]/controller
Use the URI scheme (http or https), hostname and port number appropriate for your Controller. The Controller uses the deep link value to compose URLs it exposes in the UI.
-
If terminating SSL at the proxy, also set the following JVM options:
-Dappdynamics.controller.services.hostName=<external_DNS_hostname> -Dappdynamics.controller.services.port=<external_port_usually_443>
- You should use the Enterprise Console's Controller Settings page to edit the JVM options to retain your settings. See Update Platform Configurations for more information.
- If the proxy sits between monitored tiers in the application, make sure that the proxy passes through the custom header that Splunk AppDynamics adds for traffic correlation, singularity header. Most proxies pass through custom headers by default.
- For App Agents, the Controller Host and Controller Port connection settings should point to the VIP or hostname and port exposed for the Controller at the reverse proxy. For details see Agent-to-Controller Connections.
- If using SSL from the agent to the proxy, ensure that the security protocols used between the App Agent and proxy are compatible. See the compatibility table for the SSL protocol used by each version of the agent.
-
If the proxy (or another network device) needs to check for the availability of the Controller, it can use Controller REST resource at:
http://<host>:<port>/controller/rest/serverstatus. If the Controller is active and if in high availability mode, is the primary, it returns an XML response similar to this one:<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>
If the Controller is in standby mode, this resource returns a 503 response.
The following sections provide notes and sample configurations for a few specific types of proxies, including Nginx and Apache Web Server.
Using Nginx as a Simple HTTP Reverse Proxy
Nginx is a commonly used web server and reverse proxy available at http://nginx.org/.
To use Nginx as a reverse proxy for the Controller, simply include the Controller as the upstream server in the Nginx configuration. If deploying two Controllers in a high availability pair arrangement, include the addresses of both the primary and secondary Controllers in the upstream server definition.
The following steps walk you through the set up at a high level. It assumes you have already installed the Controller and have an Nginx instance, and you only need to modify the existing configuration to have Nginx route traffic to the Controller.
To route Controller traffic through an Nginx reverse proxy-
Add a JVM option named
-Dappdynamics.controller.ui.deeplink.url. Set its value to the URL for the Controller, as described in the guidelines above. -
Shut down the Controller.
-
If terminating SSL at the proxy, also set the
-Dappdynamics.controller.services.hostNameand-Dappdynamics.controller.services.portJVM options to the external DNS hostname for the Controller and the external port number, typically 443. -
In the Nginx home directory on the reverse proxy machine, open the
conf/nginx.conffile for editing. -
In the configuration file, add a cluster definition the specifies each Controller as an upstream server. For example:In the sample, the Controller resides on 127.0.15.11 and has the fully qualified domain name 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; } } -
Restart the Nginx server to have the change take effect.
-
Restart the Controller.
After the Controller starts, it should be able to receive traffic through Nginx. As an initial test of the connection, try opening the Controller UI via the proxy, that is, in a browser, go to http://<virtualip>:80/controller
After the Controller starts, it should be able to receive traffic through Nginx. As an initial test of the connection, try opening the Controller UI via the proxy, that is, in a browser, go to http://<virtualip>:80/controller general guidelines above.リバースプロキシとして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 Off ProxyPreserveHost On 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フラグにより、クライアントは安全な接続上のみで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 を構成したことを確認して、構成を完了します。