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

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

最新バージョン： 2.0.2-1

機能の概要

INSSLR アプライアンスはセキュアな HTTP リクエストのレイヤ 7 ゲートウェイです。 リクエストをエンコードされていない HTTP リクエストに変換します。 クライアント側で安全な HTTP をサポートする必要がある場合は、常にこのアプライアンスを使用できますが、バックエンド処理インフラストラクチャでは、以下のような場合の SSL をサポートしないかサポートできません。

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

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

デフォルト設定では、INSSLR は CA AppLogic アプリケーションへのファイアウォールで保護されたエントリ ポイントをネットワーク トラフィックに提供する、セキュアな HTTP リクエストのレイヤ 7 ゲートウェイとして動作します。これはインターネットによってアクセス可能な静的 IP アドレスと共に設定できます。

設定されると、2 つの INSSLR アプライアンスは冗長サービスを提供するためにフェールオーバ モードで使用できます。 この場合、INSSLR IP アドレス（ip_addr を介して設定）は 1 つのノード上でのみ実行され、失敗した場合にはもう一方の INSSLR アプライアンスに自動で転送されます。 どの時点においても、アクティブなのは INSSLR アプライアンスのうち 1 つだけです。 フェールオーバ モードで実行する場合。INSSLR は複数のモードで動作するよう設定できます。

• Asymmetric - アプライアンスのうちの 1 つがプライマリとして使用されます。オンラインの場合は常に IP アドレスを引き継ぎ、アクティブになります。 バックアップのアプライアンスは、プライマリ ノードが失敗（または停止）した場合のみアクティブになります。 プライマリ アプライアンスが再度使用可能になると、IP アドレスを引き継ぎ、アクティブになります。 プライマリ アプライアンスは、fover_local_ip プロパティに設定される、最も低い IP アドレス（文字列比較）のものになります。
• Symmetric - アプライアンスは両方ともプライマリとなります。最初に起動したアプライアンスの方が IP アドレスを引き継ぎ、アクティブになります。 もう一方のアプライアンスは、最初のアプライアンスが失敗（または停止）した場合のみアクティブになります。 最初のアプライアンスが再度使用可能なった場合、自動で IP アドレスを引き継ぐことはありません。

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

• INSSLR を強制的にプライマリにする
• INSSLR を強制的にバックアップにする
• INSSLR（プライマリ/バックアップ）の状態の確認

INSSLR は、その http 端子へ接続されたバックエンド アプライアンスの健全性を常にモニタします。 INSSLR が行う健全性状態チェックには、簡易 TCP 接続チェックまたはより複雑な HTTP リクエスト（INSSLR の境界上で指定）が含まれる場合があります。 接続されたアプライアンスが失敗した場合には、INSSLR は、グリッド ダッシュボードへエラーをレポートします。または、冗長モードで、設定されている場合は、バックアップ INSSLR アプライアンスにフェールオーバを実行します。

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

リソース

CA AppLogic 2.7 リリース用のデフォルト メモリは 128MB に変更されました。 最小メモリは 64MB のままです。

ノート

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

端子

プロパティ

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

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

ボリューム

エラー メッセージ

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

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

パフォーマンス

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

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

リクエスト レート

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

データ スループット

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

同時接続

デフォルト メモリで、INSSLR は 500 以上の同時保留リクエストをサポートします （クライアントからのオープン TCP 接続である保留リクエストで、1 つ以上の未完了 HTTP リクエストが進行中です）。 同時接続の最大数は、利用可能な空きメモリに依存します。 16MB の増設メモリは、それぞれ同時 http トランザクションの数を 500 ずつ増やします。 たとえば、冗長モードで実行していて、2000 の同時接続に対応できるようにするには、100M+3*=148M （冗長モードでの実行時の最小メモリは 100M）が必要となります。

通知

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

INSSLR 次の 2 つの通知を送信します。

• グリッド ダッシュボードへの通知： INSSLR appliance APP_NAME:COMP_NAME <acquired|gave up> resource ip_addr
• nfy 端子を介した http リクエスト。 受信側によって、通知に基づいたアクションが実行されます。 リクエストされる URL は以下のとおりです。

  http://nfy/fover_nfy_prefixfover_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 秒に設定されます。

ヘルス チェック

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

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

上記のいずれかが true の場合は、エラー メッセージがグリッド ダッシュボードに送信されます。 複数のテストに失敗した場合は、すべてのエラーを示すサマリ メッセージがグリッド ダッシュボードにポストされます。 それぞれのエラーは 1 時間に 1 回のみグリッド ダッシュボードに送信されます。 アプライアンス起動後の最初の 5 分間はエラーはレポートされません。これは、レプリケーションでの他のノードが開始されていないときの間違ったアラームを防止するためです。

サーバ証明書

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

サーバ証明書の生成

CA AppLogic では、サーバ証明書を生成することができます。

サーバ証明書を生成する方法

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

   openssl genrsa -out privkey.pem 2048 
   

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

   openssl genrsa -des3 -out privkey.pem 2048 
   

2. 次に、証明書が必要です。 ここでは 2 つのオプションがあります。つまり、証明書リクエストを作成し、信頼された CA（それに基づいて請求）による署名を受けるか、テスト目的（この場合は、サイトをリクエストするブラウザによって、証明書が信頼された CA によって署名されていないという警告が発行されます）で自己署名証明書を作成します。

   証明書リクエスト生成するには、以下のコマンドを実行します。

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

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

3. 自己署名証明書を生成するには、以下のコマンドを実行します。

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

サーバ証明書の使用

これで、証明書とキーを 1 つのファイルに入れて、INSSLR で使用できるようになります。

cat privkey.pem  server.crt > server.pem 

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

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

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

Apache で使用する既存の証明書を持っている場合は、INSSLR 内でもそれを使用できます。 キーがパスワード保護されていないことを確認し（上記参照）、秘密キーと証明書をこの順序で 1 つのファイル内に配置してください。

例：

cat privkey.pem  server.csr > server.pem 

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

例：

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

重要： サーバ署名キーは、ユーザの Web サイトのアイデンティティを証明するものです。 パスワード暗号化されないので、脆弱でもあります（ユーザの助けがなくてもアプライアンスが読み取れるようにするためです）。 データ ボリュームにインストールするときは、キー ファイルを保護するために必要な手段を講じます。 同じデータ ボリュームを他の目的に使用したり、Web アクセス可能なデータ（HTML ページ、スクリプトなど）をホストするなどのように、Web サーバから見られる状態にはしないでください。

クライアント証明書

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

証明機関の作成

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

証明機関を作成する方法

1. 安全なホスト システムで、以下のコマンドを使用して、作業ディレクトリおよび作業ディレクトリ内のプライベート ディレクトリを作成します。

   mkdir CA 
   mkdir CA/private 
   

2. 証明機関用に、パスワード保護された RSA キーをキーの長さ 2048 ビットで作成します。

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

• 秘密キーを使用して、証明機関用の公開キー証明書を作成します。

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

重要： 証明機関用の秘密キーはアプリケーションの信頼の基本です。したがって、誰にでもわかるような保管や、他者への提供をしてはなりません。

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

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

証明機関の署名付きクライアント証明書を作成する方法

1. RSA 秘密キーを生成します（パスワード保護されたキーを作成するには、-des3 スイッチを使用します）。

   openssl genrsa -out clientA_privkey.pem 2048 
   

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_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
  

INSSLR によって使用される 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」プロパティとして INSSLR に提供されるファイルです。

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

      ####################################################################
      [ 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

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

CA AppLogic では、INSSLR が使用する証明機関リスト ファイルを作成できます。

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

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

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

2. このファイルを、キー ボリュームまたは fs 端子経由で nfs マウントされたボリュームのいずれかに置きます。
3. 必要であれば、INSSLR サーバ証明書（たとえば server.pem）もクライアント証明書と同じ方法で作成し、作成済みの証明機関によって同様に署名することができます。 この証明書にはパスワードを使用しないでください。
4. server.pem と ca_list_client.pem を所定の場所に置いたら、以下の方法でクライアント証明書認証をテストできます。
   • ブラウザからテストするには、［ツール］-［オプション］-［証明書を表示］-［あなたの証明書］-［インポート］を使って、pkcs12 形式のクライアント証明書を Firefox へインポートします。 INSSLR の IP アドレスでブラウザをポイントします。
   • リモート ホストから SSL ハンドシェイクをテストする方法

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

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

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

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

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

Web アプリケーション

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

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

Web アプリケーション用の設定

設定例の一覧は、デフォルト以外の値に設定され、ネットワーク設定されていないプロパティのみを表示しています（ip_addr、netmask、gateway）。

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

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

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

複数の tcp/udp サービスおよび http がある場合、INSSLR を使用して http トラフィックをその http 端子へ渡し、aux を使用して PS8 への残りのトラフィックをフィードします。これがバック エンド サーバへ必要なトラフィックをフィードします。

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

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

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

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

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

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

プライマリ アプリケーション上の INSSLR は次のとおりです。

バックアップ アプリケーション上の INSSLR は次のとおりです。

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

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

in1

in2

db1

db2

冗長性のある Web アプリケーション（2 つの同一アプリケーション）

同じグリッド（ただしサーバの 1 つが失敗してもアプリケーションのうちの 1 つにしか影響しないようにサーバが別々であること）、または別のグリッド上で使用する IP アドレスが両方のグリッドからアクセス可能である場合、2 つの同一のアプリケーションを実行できます。 以下の例は、冗長モードでも実行されているデータベース アプライアンスを使用したアプリケーションを示しています。このため、1 つのアプリケーションで失敗した場合でも、別のアプリケーションが引き継ぐのでデータが損失しません。

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

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

クライアント リクエストが in1 ゲートウェイに到達します。 ゲートウェイは Web ロード バランサにリクエストを転送し、Web ロード バランサは web1 と web2 のいずれかの Web サーバにリクエストを伝えます。 Web サーバは db データベースにアクセスします。 db アプライアンスはリモート アプリケーション（これは同じもののコピーで、唯一異なるのは server_id が db かネットワーク設定であるかのみです）に接続され、データベースをレプリケートします。 リモート アプリケーションは、リモート アプリケーションの repl_out ゲートウェイからのみ接続が許可されるように設定された repl_in ゲートウェイ経由で、db アプライアンスに接続します。 2 つのアプリケーション内の db アプライアンスはマスタ/マスタ設定で実行されるので、これらのデータは常に同一です。

プロパティ設定の例（リストに表示されていないプロパティはデフォルト値のままにしてください）：

db への Web アクセスは、ポート 8080 上の admin ゲートウェイを使用すれば可能です。

in1

db

重要： アプリケーションのうち 1 つのみが常にアクティブです。もう一方は単にフェールオーバのために実行されており、アクティブなアプリケーションが失敗したときに使用されます。

注

INSSLR は HTTP 1.0 および HTTP 1.1 をサポートしますが、クライアントがそれ自体で MSIE として識別する場合、HTTP 1.1 サポートはその接続に対してオフになります（MSIE の一部のバージョン内のバグを回避）。

クライアントが MSIE でない場合、INSSLR はクライアントのために HTTP 1.1 をサポートします（TCP セッション機能を通じた複数のリクエストを含む）。これは、バックエンド サーバの使用によって HTTP 1.0 のみがサポートされる場合も同様です。

INSSLR は 1 つの外部 IP をサポートします。したがって、単一の SSL 証明書のみを使用できます。

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

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