参照情報 › アプライアンス カタログ リファレンス ガイド › システム カタログ › ゲートウェイ › INSSLR2 - SSL サポート付き冗長 HTTP 入力ゲートウェイ

INSSLR2 - SSL サポート付き冗長 HTTP 入力ゲートウェイ

最新バージョン： 1.0.1-2

INSSLR2 アプライアンスはセキュアな HTTP リクエストのレイヤ 7 ゲートウェイです。 リクエストをエンコードされていない HTTP リクエストに変換します。 クライアント側で安全な HTTP をサポートするためにこの機能を使用できます。

ただし、バックエンド処理インフラストラクチャでは、以下のような場合の SSL をサポートしないかサポートできません。

• SSL サポートがない軽量の高速 HTTP サーバの使用
• パフォーマンスまたは冗長性を目的として、負荷分散スイッチを介して接続される複数のバックエンド サーバの使用
• 関連のない機能を実行するために URL スイッチを介して接続される複数のバックエンド サーバの使用
• スループットを改善するための SSL 暗号化または復号化の個別サーバへのオフロード

設定された場合、INSSLR2 はクライアント証明書認証もサポートします。 SSL 相互認証の場合には、クライアントおよびサーバの両方が証明書および対応する公開鍵を交換します。 処理を進める前に、クライアントおよびサーバの両方は証明書を発行した証明機関（CA）に連絡して証明書が信頼できることを確認することができます。

そのデフォルト設定で、INSSLR2 は安全な HTTP リクエスト用のレイヤ -7 ゲートウェイとして動作します。 また、アプリケーションに送信されるネットワーク トラフィックに対してファイアウォール保護されたエントリ ポイントを提供します。 これはインターネット アクセス可能な静的 IP アドレスを使用して設定できます。

設定されると、2 つの INSSLR2 アプライアンスは冗長サービスを提供するためにフェールオーバ モードで使用できます。 この場合、INSSLR2 IP アドレスは 1 つのノード上でのみ実行され、失敗した場合には他の INSSLR2 アプライアンスに自動で転送されます。 一度にアクティブにする INSSLR2 アプライアンスは 1 つのみです。 フェールオーバ モードで実行する場合。INSSLR2 は複数のモードで動作するよう設定できます。

• Asymmetric - アプライアンスのうちの 1 つがプライマリとして使用されます。 プライマリ アプライアンスがオンラインの場合、IP アドレスを引き継ぎ、アクティブになります。

  プライマリ ノードが失敗または停止した場合、バックアップ アプライアンスがアクティブになります。 プライマリ アプライアンスが再度使用可能になると、IP アドレスを再び引き継ぎ、アクティブになります。 プライマリ アプライアンスは、fover インターフェースで最も低い IP アドレス（文字列比較）のものになります。

• Symmetric - アプライアンスは両方ともプライマリとなります。 最初に起動したアプライアンスの方が IP アドレスを引き継ぎ、アクティブになります。 もう一方のアプライアンスは、最初のアプライアンスが失敗または停止した場合のみアクティブになります。

  最初のアプライアンスが再度使用可能なった場合、自動で IP アドレスを引き継ぐことはありません。

冗長モードで実行されるとき、INSSLR2 は以下について ctl 端子へのインターフェースを提供します。

• INSSLR2 を強制的にプライマリにする
• INSSLR2 を強制的にバックアップにする
• プライマリまたはバックアップ INSSLR2 の状態を確認する

INSSLR2 は、その http 端子へ接続されたバックエンド アプライアンスの健全性を常にモニタします。 INSSLR2 が行う健全性状態チェックには、簡易 TCP 接続チェックまたはより複雑な HTTP リクエスト（INSSLR2 の境界上で指定されている場合）が含まれる場合があります。

接続されたアプライアンスが失敗した場合には、INSSLR2 は、グリッド ダッシュボードへエラーをレポートします。または、冗長モードで、設定されている場合は、バックアップ INSSLR2 アプライアンスにフェールオーバを実行します。

複数のサービス用に単一 IP アドレスで表示する必要があるアプリケーションをサポートするには、非 HTTP トラフィックを透過的に個別の出力端子に転送するように INSSLR2 を設定します。 そのような接続で、このアプライアンスはレイヤ -3 ファイアウォール/NAT ルータとして動作します。

境界

リソース

メモ

• INSSLR2 をフェールオーバ モードで使用する（fover_mode が none 以外である）場合、最小メモリは 192 M です。
• INSSLR2 に割り当てられたメモリの量は、そのスループットに影響しません。 より多くのメモリを使用するのは、バックエンド サーバが過度の長時間にわたってリクエストを保持できるように、多くの同時リクエストをサポートする目的のためのみです。

端子

プロパティ

path/to/keys/ca_list_client.pem 

path/to/keys/ca_list_client.pem 

ヘルス チェック プロパティ

フェールオーバ シナリオで使用する詳細プロパティ

ボリューム

エラー メッセージ

アプライアンスが開始に失敗すると、以下のメッセージが、アプライアンスのログ ファイルまたはグリッド コントローラのシステム ログのいずれかに表示される場合があります。

• データ ボリュームをマウントできませんでした
• データ共有の許可を設定できませんでした
• Samba を起動できませんでした
• NFS を起動できませんでした
• Apache を起動できませんでした

パフォーマンス

アプリケーション フェールオーバ

INSSLR2 は、およそ 10 秒で INSSLR2 の失敗を検出し、別のアプリケーションへのフェールオーバにさらに 10 秒を必要とします。 アプリケーションの失敗が最初に発生してから、別のアプリケーションにトラフィックが引き継がれるまでの合計時間は、約 20 秒です。

リクエスト レート

ドキュメント サイズや利用可能なネットワーク帯域幅にもよりますが、INSSLR2 は毎秒 3000 以上のトランザクション（リクエスト/応答ペア）をルーティングします。

データ スループット

ドキュメント サイズや利用可能なネットワーク帯域幅にもよりますが、INSSLR2 は 7 MB/秒以上でルーティングします。

同時接続

デフォルト メモリで、INSSLR2 は 500 以上の同時保留リクエストをサポートします。 クライアントからのオープン TCP 接続である保留リクエストで、1 つ以上の未完了 HTTP リクエストが進行中です。

同時接続の最大数は、利用可能な空きメモリに依存します。 16MB の増設メモリは、それぞれ同時 http トランザクションの数を 500 ずつ増やします。

たとえば、冗長モードで実行していて、2000 の同時接続に対応できるようにするには、100M + 3*16M = 148M が必要となります。 冗長モードで実行する場合の最小メモリは 100M です。

通知

冗長モード（fover_mode が none ではない）で実行する場合、INSSLR2 はアクティブまたはパッシブに移行するごとに通知をトリガします。 これは、アクティブなノードの起動時またはフェールオーバの発生時に実行されます。 アクティブまたはパッシブになると通知が各ノードによって送信されます。

INSSLR2 は、次の 2 つの通知を送信します。

• グリッド ダッシュボードへの通知： INSSLR2 appliance APP_NAME:COMP_NAME <acquired|gave up=""> resource ip_addr
• nfy 端子を使用する HTTP リクエスト。 受信側によって、通知に基づいたアクションが実行されます。

  リクエストされる URL は以下のとおりです。

  http://nfy/ fover_nfy_prefix fover_mode= fover_mode &state= <start|stop> &ip_addr= ip_addr &fover_local_ip= fover_local_ip &fover_remote_ip= fover_remote_ip &fover_netmask= fover_netmask

fover_nfy_prefix を使用して、呼び出されるリモート スクリプトの場所を変更するか、またはパラメータを追加できます（またはその両方）。

fover_nfy_prefix 値の例：

/path/to/script.php?, /path/to/script.php?username=user&password=pass&。 

注：

• デフォルトと異なる fover_nfy_prefix を使用するときは、次の場合に必ず終わりに ? を付けてください。 fover_nfy_prefix が単にパスまたはスクリプトである場合。または fover_nfy_prefix に追加パラメータが含まれる場合は & を付けます。
• ノードが利用不能になると、パッシブになったときに通知を送信できなくなる可能性があります。 アクティブになったノードのみによって通知が送信されます。
• http リクエストのタイムアウトは、フェールオーバが遅れないように 5 秒に設定されます。

ヘルス チェック

INSSLR2 は、1 分ごとに以下を確認する cronjob を実行します。

• データ ボリュームの空き容量が 20% 未満になっている
• rsync デーモンが実行されている（ただしスレーブとして設定されている場合のみ）
• レプリケーション プロセスが実行されている（ただしマスタとして設定されている場合のみ） そうなっていない場合は、レプリケーション プロセスを再開します。

いずれかが true の場合は、エラー メッセージがグリッド ダッシュボードに送信されます。 複数のテストに失敗した場合は、すべてのエラーを示すサマリ メッセージがグリッド ダッシュボードにポストされます。

それぞれのエラーは 1 時間に 1 回のみグリッド ダッシュボードに送信されます。 アプライアンス起動後の最初の 5 分間はエラーはレポートされません。 これは、レプリケーションでの他のノードが開始されていないときの間違ったアラームを防止するためです。

サーバ証明書

SSL を使用するには、署名された証明書と暗号化に使用された秘密キーの両方が必要です。 キーと証明書は、PEM 形式にし、cert_file プロパティによって指定された単一のファイルに配置する必要があります。

サーバ証明書の生成

信頼された証明機関（CA）によって有料で署名できるサーバ証明書を生成するか、自己署名証明書を作成できます。

以下の手順に従います。

1. 以下のコマンドを使用して、秘密キーを生成します。

   openssl genrsa -out privkey.pem 2048 
   

   また、以下のコマンドを使用して、パスワード保護されたキーを生成できます。 ただし、パスワード保護されたキーを作成する場合は、INSSLR2 で使用する前にパスワードを削除する必要があります。 INSSLR2 ではパスワードなしのキーが必要です。

   openssl genrsa -des3 -out privkey.pem 2048 
   

2. 以下のいずれかのオプションを使用して、証明書を作成します。
   • 証明書リクエストを作成し、信頼された CA による署名を有料で受けます。

     以下を実行します。

     openssl req -new -key privkey.pem -out server.csr 
     

     信頼された証明機関へ .csr ファイルを送信した後、署名付き証明書（.crt ファイル）が戻されるので、これを使用できます。

   • テスト目的用の自己署名証明書を作成します。 サイトをリクエストするブラウザは、証明書が信頼された CA によって署名されていないという警告を発行します。

     以下を実行します。

     openssl req -new -x509 -key privkey.pem -out server.crt -days 1095 
     

サーバ証明書の使用

これで、ファイルに証明書とキーを配置し、以下のコマンドを実行することにより INSSLR2 で使用できるようになります。

cat privkey.pem server.crt > server.pem 

キーがパスワード保護されている場合は、以下のコマンドを実行してパスワードを削除できます。

openssl rsa -in key_with_pass.pem -out privkey.pem 

既存の apache+mod_ssl サーバ証明書の使用

INSSLR2 では、Apache で使用する既存の証明書を使用できます。 上記の手順に従ってキーがパスワード保護されていないことを確認し、単一のファイルにプライベート証明書とキーを配置します。

例：

• cat privkey.pem server.csr > server.pem

チェーン証明書を使用する場合は、発行者によって提供される中間証明書も含める必要があります。 秘密キー、証明書、中間証明書をこの順序で単一ファイル内に配置してください。

例：

• cat privkey.pem server.csr sf_issuing.crt > server.pem

重要： サーバ署名キーは、ユーザの Web サイトのアイデンティティを証明するものです。 ユーザの介入なしでアプライアンスが読み取れるようにするためにパスワード暗号化されないので、脆弱でもあります。

データ ボリュームにインストールするときは、キー ファイルを保護するための手段を講じます。 同じデータ ボリュームを他の目的に使用しないでください。また、Web サーバから見られる状態にしないでください。 （例： HTML ページやスクリプトなどの Web アクセス可能なデータをホストするなど）

クライアント証明書

以下の例は、ユーザ自身の証明機関を作成し、OpenSSL を使用して、自分の証明書に署名する方法の概要を示しています。 これは OpenSSL 0.9.8b （INSSLR2 にインストールされているものと同じバージョン）を使用してテストされました。

証明機関の作成

自己署名付きサーバ証明書の作成に使用するご自身の証明機関をすでにお持ちの場合は、この手順をスキップして、その証明機関を使用することができます。 ユーザのアプリケーションに対する信頼された権限のインスツルメントを作成するときは、環境が安全であることが重要です。

重要： 証明機関用の秘密キーはアプリケーションの信頼性の基盤です。 誰にでもわかるような場所に保管したり、他者に提供したりしないでください。

以下の手順に従います。

1. 安全なホスト上の該当するディレクトリ内に、作業ディレクトリを作成します。
   • mkdir CA
   • mkdir CA/private
2. 証明機関用に、パスワード保護された RSA キーを、2048 ビットのキーの長さで作成します。

   openssl genrsa -des3 -out CA/private/CA_key.pem 2048 
   

3. 秘密キーから、CA 用の公開キー証明書を作成します。

   openssl req -new -key CA/private/CA_key.pem -x509 -days 365 -out CA/CA_cert.pem 
   

証明機関の署名付きクライアント証明書の作成

証明機関の署名付きクライアント証明書を作成することができます。

以下の手順に従います。

1. RSA 秘密キーを生成します。

   openssl genrsa -out clientA_privkey.pem 2048 
   

   パスワード保護されているキーを作成するには、-des3 スイッチを使用します

2. 秘密キーから証明書署名要求（CSR）を生成します。

   openssl req -new -key clientA_privkey.pem -out clientA_request.csr 
   

3. CA 用に生成された証明書を使用して、CSR 内の証明書に署名します。

   openssl x509 -req -days 365 -in clientA_request.csr -CA CA/CA_cert.pem -CAkey CA/private/CA_key.pem -CAcreateserial -out clientA.cer 
   

注：

• -CAcreateserial スイッチは、発行済み証明書への一意のシリアル番号の割り当てを有効にします。 この証明書が CA によって発行された最初の証明書である場合、シリアル番号の割り当てを追跡するためのファイル CA/CA_cert.srl が作成されます。 この後、クライアント証明書の作成時には、-CAcreateserial スイッチの代わりに -CAserial スイッチが使用されます。

  例：

  openssl genrsa -out clientB_privkey.pem 2048 
  

  openssl req -new -key clientB_privkey.pem -out clientB_request.csr 
  

  openssl x509 -req -days 365 -in clientB_request.csr -CA CA/CA_cert.pem -CAkey CA/private/CA_key.pem -CAserial CA/CA_cert.srl -out clientB.cer 
  

• クライアント証明書とキーの両方が含まれる単一の PEM 形式のファイルを作成する方法は、以下のとおりです。

  cat clientA_privkey.pem clientA.cer > clientA.pem 
  

• ほとんどのブラウザで使用可能な pkcs12 形式で同等のファイルを作成する方法は、以下のとおりです。

  openssl pkcs12 -export -in clientA.cer -inkey clientA_privkey.pem -out clientA.p12 
  

INSSLR2 によって使用される CA リスト ファイルの作成

CA の署名付きクライアント証明書の無効化

CA によって発行されたクライアント証明書を無効にするには、以下のコマンドを使用します。

openssl ca -config openssl.conf -revoke clientB.cer -crl_reason keyCompromise 

この例で「openssl.conf」は以下に示すとおりであり、「crl_reason」パラメータは、unspecified、keyCompromise、CACompromise、affiliationChanged、superseded、cessationOfOperation、certificateHold、removeFromCRL のうちのいずれかです。 理由の一致では、大文字と小文字を区別しません。

証明書失効リスト（CRL）を再生成する方法

openssl ca -config openssl.conf -gencrl -out CA/crl.pem 

この例で、「crl.pem 」は「cert_revocation_list」プロパティとして INSSLR2 に提供されるファイルです。

上記の例に使用される環境設定ファイルの一例を以下に示します。 

      ####################################################################

      [ ca ]

      default_ca      = CA_default            # The default ca section

      ####################################################################

      [ CA_default ]

      dir             = ./CA                  # Where everything is kept

      certs           = $dir/certs            # Where the issued certs are kept

      crl_dir         = $dir/crl              # Where the issued crl are kept

      database        = $dir/index.txt        # database index file.

      #unique_subject = no                    # Set to 'no' to allow creation of

                                        # several ctificates with same subject.

      new_certs_dir   = $dir/newcerts         # default place for new certs.

      certificate     = $dir/cacert.pem       # The CA certificate

      serial          = $dir/serial           # The current serial number

      crlnumber       = $dir/crlnumber        # the current crl number

                                        # must be commented out to leave a V1 CRL

      crl             = $dir/crl.pem          # The current CRL

      private_key     = $dir/private/cakey.pem# The private key

      RANDFILE        = $dir/private/.rand    # private random number file

      default_days    = 365                   # how long to certify for

      default_crl_days= 30                    # how long before next CRL

      default_md      = sha1                  # which md to use.

      preserve        = no                    # keep passed DN ordering

      policy          = policy_anything

      [ policy_anything ]

      countryName             = optional

      stateOrProvinceName     = optional

      localityName            = optional

      organizationName        = optional

      organizationalUnitName  = optional

      commonName              = supplied

      emailAddress            = optional

INSSLR2 が使用する証明機関リスト ファイルの作成

INSSLR2 が使用する証明機関リスト ファイルを作成できます。

ca_list_client プロパティによって識別されるファイルを作成する方法

1. 以下のファイルにアクセスします。

   cat CA/private/CA_key.pem CA/CA_cert.pem > ca_list_client.pem 
   

2. このファイルを、キー ボリュームまたは fs 端子経由で nfs マウントされたボリュームのいずれかに置きます。

   必要であれば、INSSLR2 サーバ証明書（server.pem など）もクライアント証明書と同じ方法で作成し、作成済みの証明機関によって同様に署名することができます。 この証明書にはパスワードを使用しないでください。

3. server.pem と ca_list_client.pem を所定の場所に置いたら、以下の方法でクライアント証明書認証をテストします。
   • ブラウザからテストするには、以下のメニュー項目を使用して、pkcs12 形式のクライアント証明書を FireFox へインポートします。

     ［ツール］-［オプション］-［証明書を表示］-［あなたの証明書］-［インポート］。 INSSLR2 の IP アドレスでブラウザをポイントします。

   • リモート ホストから SSL ハンドシェイクをテストするには、以下のコマンドを使用します。

     openssl s_client -host IP-address -port 443 -showcerts -ssl3 -cert clientA.cer -key clientA_privkey.pem -state 
     

クライアント証明書ヘッダ

HTTPS を使用してクライアントを INSSLR2 に接続する場合、およびクライアント証明書を提示する場合、INSSLR2 はバックエンド サーバに返されるリクエストに以下のヘッダを追加します。

• X-SSL-Subject： 証明書の所有者に関する詳細。
• X-SSL-Issuer： 証明書の発行者（証明機関）に関する詳細。
• X-SSL-Serial： 証明書のシリアル番号（10 進数）。
• X-SSL-Cipher： 現在使用されている暗号。
• X-SSL-Certificate： 完全なクライアント証明書（PEM 形式による複数行）。

これらのヘッダを利用するかどうかはアプリケーションによって判断されます。 INSSLR2 は、特に確認せずに（シグネチャと正しい暗号化のチェックは例外）この情報を渡します。

典型的な使用状況

Web アプリケーション

アプリケーションへの http または https アクセスを行うには、WEB アプライアンスに http 端子を直接接続します。

拡張性のある Web アプリケーションの場合は、HALB アプライアンスに http 端子をフックします。

設定例の一覧は、デフォルト以外の値に設定されたプロパティのみを表示しています。

サービスを追加した Web アプリケーション

アプリケーション内に http 以外にもサービスがある場合、INSSLR2 を使用して http トラフィックをその http 端子へ渡し、他のサービス用の aux 端子を使用することができます。

複数サービスを追加した Web アプリケーション

複数の TCP/UDP サービスおよび HTTP を使用する場合、INSSLR2 を使用して HTTP トラフィックをその HTTP 端子へ渡し、aux を使用して残りのトラフィックを PS8 にフィードします。 PS8 から必要なトラフィックがバックエンド サーバにフィードされます。

冗長性のある Web アプリケーション

冗長性のある Web アプリケーションが必要な場合は、アプリケーションをコピーし、INSSLR2 を使用して、外部 IP アドレスにフェールオーバ機能を提供することができます。

注： 同じアプリケーション内の 2 つの INSSLR2 アプライアンスが冗長モードで実行されるように設定する場合、同じ IP アドレスを 2 つの異なるインターフェース上に設定した場合、警告メッセージが表示されます。 そのエラーは無視してください。

バックアップ Web アプリケーション

ユーザにダウンタイムを通知するバックアップ アプリケーションのみが必要な場合は、INSSLR2 を使用して、最小限のリソースを必要とするバックアップ アプリケーションを構築します。

使用中のアプライアンス：

• user： ユーザ リクエスト用の入力ゲートウェイ
• web： メンテナンス メッセージを表示する Web サーバ

プライマリ アプリケーション上の INSSLR2

バックアップ アプリケーション上の INSSLR2

注： アプリケーション設定エディタの［インターフェース］タブを使用して、fover 端子に接続されたインターフェースの属性を設定できます。 例： fover_local_ip および fover_netmask プロパティ。

単一アプリケーション内の冗長性のある Web アプリケーション

新規のアプリケーションを作成しないで、アプリケーションを冗長モードで実行する場合、単純にアプライアンスを二重にすれば冗長モードで実行できます。 この場合は（少なくとも） 2 つの Web サーバと 2 つのデータベース アプライアンスが標準モードで使用され、すべてが使用されるため拡張性が提供されます。 これらはいずれも、一方のアプライアンスに障害が発生した場合、単独でアプリケーションにサービスを提供できます。

追加の拡張性を必要とする場合は、さらに多くの Web とデータベースのアプライアンスを追加できます。 この例では、アプライアンスの半分（in1、sw1、web1、db1）が 1 つのフェールオーバ グループ内で実行され、残り（in2、sw2、web2、db2）は別のフェールオーバ グループ内で実行されるので、アプリケーションはサーバ クラッシュに耐えることができます。 すべてのアプライアンス（要求されるリソースが非常に少ない 1 つの INSSLR2 および 1 つの HALB のアプライアンスを除く）がアクティブ状態にあり、プライマリが失敗したときにのみ実行されるバックアップ アプリケーションにはリソースが費やされないので、このアプリケーションは非常に低コストで冗長性を提供します。

in1

in2

db1

db2

2 つの同一アプリケーションを実行する冗長性のある Web アプリケーション

2 つの同一のアプリケーションを同じグリッド（ただし、IP アドレスが両方のグリッドからアクセス可能である場合は、別々のサーバまたは別々のグリッド）で実行できます。 これは、サーバの 1 つが失敗してもアプリケーションのうちの 1 つにしか影響しないようにするためです。

注： 同じアプリケーション内の 2 つの INSSLR2 アプライアンスが冗長モードで実行されるように設定する場合、同じ IP アドレスを 2 つの異なるインターフェース上に設定した場合、警告メッセージが表示されます。 そのエラーは無視してください。

以下の例は、冗長モードでも実行されているデータベース アプライアンスを使用したアプリケーションを示しています。 このため、1 つのアプリケーションで失敗した場合でも、別のアプリケーションが引き継ぐのでデータが損失しません。

使用中のアプライアンス：

• insslr - ユーザ リクエスト用の冗長入力ゲートウェイ
• admin - ログ ファイルにアクセスするための入力ゲートウェイ
• sw - ポート 8080 を admin から db 上の ui にリダイレクト
• repl_in - db アプライアンスに接続してデータベースをレプリケートするための、リモート アプリケーションの入力
• web_lb - ユーザ リクエスト用の Web ロード バランサ
• web1、web2 - アクティブなコンテンツ（CGI スクリプトなど）がある Web サーバ
• db - 同時にマスタとスレーブの両方であるように設定された MYSQLR64
• content - データベース エラー ログ ファイル、Web コンテンツおよび Web ログ用のストレージ
• logs - データベース エラー ログ ファイル用のストレージ
• repl_out - データベースをレプリケートするための、リモート アプリケーションに接続する db アプライアンス用出力ゲートウェイ
• mon - MON アプライアンス

クライアント リクエストは insslr ゲートウェイ上に送られます。 ゲートウェイは web_lb ロード バランサにリクエストを転送し、web_lb ロード バランサは web1 と web2 のいずれかの Web サーバにリクエストを伝えます。

Web サーバは db データベースにアクセスします。 db アプライアンスはリモート アプリケーションに接続します。 データベースをレプリケートするには、リモート アプリケーションが同じもののコピーで、唯一異なるのは db の server_id とネットワーク設定のみである必要があります。

リモート アプリケーションは、リモート アプリケーションの repl_out ゲートウェイからのみ接続が許可されるように設定された repl_in ゲートウェイを使用して、db アプライアンスに接続します。 2 つのアプリケーション内の db アプライアンスはマスタ/マスタ設定で実行されるので、これらのデータは常に同一です。

プロパティ設定の例

リストに表示されていないプロパティはデフォルト値のままにしてください。 db への Web アクセスは、ポート 8080 上の admin ゲートウェイを使用すれば可能です。

insslr

db

重要： 常にアクティブなのは 1 つのアプリケーションだけです。他方のアプリケーションはフェールオーバ用に実行され、アクティブなアプリケーションに障害が発生した場合に使用されます。

注：

• INSSLR2 は HTTP 1.0 および HTTP 1.1 をサポートしますが、クライアント自体が MSIE である場合、HTTP 1.1 サポートはその接続に対してオフになります。 これによって、MSIE の一部のバージョン内のバグ問題を回避します。
• クライアントが MSIE でない場合、INSSLR2 はクライアント用の HTTP 1.1 をサポートします。 TCP セッション機能についての複数のリクエストを含みます。 これは、バックエンド サーバで HTTP 1.0 のみがサポートされる場合も同様です。
• INSSLR2 は 1 つの外部 IP をサポートします。したがって、単一の SSL 証明書のみを使用できます。

アプライアンス内で使用されるオープン ソース/サードパーティ ソフトウェア

INSSLR2 は、ベース クラス LUX6 で使用されるサードパーティのオープン ソース パッケージに加えて、以下のサードパーティのオープン ソース パッケージを使用します。