Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページで
 

ルーティングエンジンベースの静的HTTPリダイレクトサービスの設定

メモ：

Junos OSリリース19.3R2以降、MXシリーズで次世代サービスを有効にしている場合、HTTPリダイレクトサービスもサポートされます。

MS-MPC/MS-MICまたはMX-SPC3サービスカードを使用する代わりに、ルーティングエンジンでHTTPリダイレクトサービスを設定できます。ウォールド ガーデンをファイアウォール サービス フィルターとして設定します。ウォールド ガーデンとは、壁に囲まれた庭園内のサイトへの加入者アクセスを提供するサーバーのグループで、キャプティブ ポータルを介して再認証する必要はありません。ウォールド ガーデン サービス フィルターは、壁に囲まれた庭園を宛先とするトラフィックと、壁に囲まれた庭園の外に送信されるトラフィックを識別します。HTTP リダイレクト サービスによる処理のために、壁に囲まれた庭園の外に送信される HTTP トラフィックのみがルーティング エンジンに送信されます。CPCD サービスは、サービス・セットによってルーティング・エンジン上のサービス・インターフェースに関連付けられます。

ルーティング エンジン上のサービス インターフェイスは、si- プレフィックス(例:si-1/1/0)で識別されます。si-インターフェイスは、ルーティングエンジンのトラフィックとサービスのリダイレクトと書き換えのすべてを処理します。キャプティブ ポータル コンテンツ配信(CPCD)サービスを有効にしてアクティブにするには、si- インターフェイスをアップのステータスで動作させる必要があります。CPCDサービスが有効になった後、si-インタフェースの動作状態の変更は、既存のCPCDサービスには影響しません。

CPCD サービスは、ウォールド ガーデン宛てではない加入者 HTTP 要求トラフィックをリダイレクト サーバーに送信し、リダイレクト URL で応答します。リダイレクト URL は、許可されていない外部サイトではなく、キャプティブ ポータルにトラフィックを送信します。キャプティブ ポータルは、壁に囲まれた庭園の外にある保護されたサーバーへのアクセスを許可する前に、リダイレクトされた加入者に認証および許可サービスを提供します。

リダイレクトサーバーは、ローカルまたはリモートにできます。

  • ローカルリダイレクトサーバー-ルーター上に常駐し、壁に囲まれた庭園内のキャプティブポータルに加入者トラフィックをリダイレクトします。

  • リモート リダイレクト サーバー —ルーターの背後にある壁に囲まれた庭園内のポリシー サーバーなどのデバイスに常駐します。加入者のHTTPトラフィックの宛先アドレスは、リモートリダイレクトサーバーのアドレスに書き換えられます。リモートサーバーは、壁に囲まれた庭園内のキャプティブポータルに加入者トラフィックをリダイレクトします。

ウォールドガーデンをファイアウォールサービスフィルターとして設定する

ウォールド ガーデンをファイアウォール サービス フィルターとして設定すると、ウォールド ガーデン内のサーバー宛てのトラフィックが特定され、スキップされます。その他のすべての HTTP トラフィックは、壁に囲まれた庭園の外のアドレス宛てになります。このトラフィックはフィルター条件に一致しないため、処理のためにルーティング エンジンにフローされます。

ウォールド ガーデンにキャプティブ ポータルまたはサーバーのリストとして 1 つのサーバーが含まれるように、サービス フィルターを設定できます。

  • 単一のサーバーをキャプティブ ポータルとしてウォールド ガーデンを設定します。

    1. サービス フィルターを作成します。

    2. キャプティブ ポータルへのトラフィックの処理を識別してスキップするフィルター条件を定義します。

      1. キャプティブ ポータルと宛先ポートの宛先アドレスを指定して、キャプティブ ポータルを宛先とするトラフィックを一致させるフィルター条件を指定します。

      2. 一致するトラフィックがラインカードでの処理をスキップすることを指定します。

    3. フィルター条件を定義して、前の条件に一致しないすべてのトラフィックからの HTTP トラフィックを識別し、CPCD サービス ルールによる処理のために送信します。

      1. スキップされた HTTP トラフィックに一致する 1 つ以上の HTTP ポート番号を指定します。

      2. 一致するトラフィックが CPCD サービスによって処理されるように指定します。

    4. フィルター条件を定義して、残りの HTTP 以外のトラフィックに対してさらにアクションをスキップします。

    たとえば、以下の設定では、192.0.2.0 のキャプティブ ポータルを使用して、IPv4 HTTP トラフィック(walled-v4)のフィルターを作成します。アドレスに一致するトラフィックの処理はスキップされます。キャプティブ ポータルにトラフィックが送信されます。非一致トラフィックは http という用語で、HTTP トラフィックはスキップされたすべてのトラフィックから選択され、CPCD サービスに従って処理されるように送信されます。最後に、用語スキップにより、残りのHTTP以外のトラフィックはすべてスキップされます。

  • ウォールド ガーデンをサーバーのリストまたはサブネットとして構成します。

    1. サービス フィルターを作成します。

    2. フィルター条件を定義します。

      1. ウォールド ガーデン内の任意のサーバー宛てのトラフィックを照合するフィルター条件を指定するには、サーバーの宛先プレフィックス リストを指定します。

      2. 一致するトラフィックがラインカードでの処理をスキップすることを指定します。

    3. フィルター条件を定義して、前の条件に一致しないすべてのトラフィックからの HTTP トラフィックを識別し、CPCD サービス ルールによる処理のために送信します。

      1. スキップされた HTTP トラフィックに一致する 1 つ以上の HTTP ポート番号を指定します。

      2. 一致するトラフィックが CPCD サービスによって処理されるように指定します。

    4. フィルター条件を定義して、残りの HTTP 以外のトラフィックに対してさらにアクションをスキップします。

    5. (オプション)壁のある庭園内のサーバーを指定するプレフィックス リストを定義します。サブネットまたは複数の個別アドレスを指定できます。

    たとえば、以下の構成では、壁のある庭園に 2 つのサーバーを指定するプレフィックス リスト wg-list を含む IPv6 HTTP トラフィック(walled-v6-list)のフィルターを作成します。フィルター条件 portal6 は、壁に囲まれた庭園を宛先とする IPv6 トラフィックを識別します。一致しないトラフィックは http6 と呼ばれ、HTTP トラフィックはスキップされたすべてのトラフィックから選択され、CPCD サービスに従って処理されるように送信されます。最後に、用語 skip6 により、残りの HTTP 以外のトラフィックはすべてスキップされます。

ローカルおよびリモートリダイレクトサーバーのHTTPリダイレクトの設定

壁に囲まれた庭園の外のサイトに対して HTTP 要求が行われると、CPCD は認証と許可のためにトラフィックをキャプティブ ポータルにリダイレクトできます。

壁に囲まれた庭園の外を宛先とするトラフィックに対して実行するアクションを指定する CPCD サービス ルールを設定します。このトラフィックは、ウォールド ガーデン サービス フィルターによって識別され、サービスに渡されるか、またはウォールド ガーデン サービス ルールによって識別および受け入れられました。設定するアクションは、ローカルまたはリモートのHTTPリダイレクトサーバーのどちらを使用しているかによって異なります。

  • ルーターでローカルHTTPリダイレクトサーバーを使用している場合は、リダイレクトアクションを指定します。

  • ルーターの背後にある壁に囲まれた庭園に存在するリモートHTTPリダイレクトサーバーを使用している場合、リダイレクトURLを指定するだけではいけません。この場合、サービス ルールはトラフィックの IP 宛先アドレスを書き換える必要があります。新しい宛先アドレスは、リモート HTTP リダイレクト サーバーのアドレスです。その後、リモート サーバーからリダイレクト URL が提供され、キャプティブ ポータルにトラフィックが送信されます。

CPCD サービスは、サービス・セットによってサービス・インターフェースに関連付けられます。サービス セットとウォールド ガーデン サービス フィルターの両方が静的に設定されたインターフェイスに適用されます。

  1. CPCD サービス構成レベルにアクセスします。
  2. 壁のある庭の外を宛先とするトラフィックに適用するルールを作成します。
  3. ルールが受信トラフィックに適用されるように指定します。
  4. HTTP トラフィックにアクションを適用する CPCD のルール条件を定義します。ウォールド ガーデンはサービス フィルターとして構成されているため、トラフィックはサービスに送信される前に HTTP トラフィックとして既にフィルタリングされています。

    • ローカルHTTPリダイレクトサーバーでは、リダイレクトURLを指定します。これは元のURL(ウォールドガーデンの外)が付加されたキャプティブポータルのURLです。

    • リモート HTTP リダイレクト サーバーの場合は、リモート サーバーの宛先アドレスを指定します。

たとえば、ローカル サーバーの以下の構成では、CPCD サービス ルール redir-svc はキャプティブ ポータル http://www.portal.example.comにトラフィックをリダイレクトします。加入者が入力した元の URL がリダイレクト URL の末尾に追加されます。

リモート サーバーの以下の構成では、元の宛先アドレスをリモート サーバーのアドレス 192.0.2.230 に書き換える CPCD サービス ルールの再作成-svc を作成します。

サービスプロファイルとサービスセットを設定して、サービスプロファイルをサービスインターフェイスに関連付ける

サービス セットは、ルーティング エンジンが実行する 1 つ以上のサービスを定義します。HTTP リダイレクト・サービスの場合は、CPCD ルールを含む CPCD サービス・プロファイルを定義します。サービス セットは、CPCD サービス プロファイルを特定のサービス インターフェイスに適用します。

  1. サービス プロファイルを作成します。
  2. サービス プロファイルに対して 1 つ以上の CPCD ルールを指定します。
  3. サービス セットを作成します。
  4. サービス セットがルーティング エンジンベースの CPCD 用であることを指定します。
  5. CPCD サービス プロファイルを指定します。
  6. サービスインターフェイスを指定します。

例えば、以下の構成では、CPCD サービス・プロファイルの redir-prof が作成され、CPCD ルールの redir-svc を参照します。サービス・セット ss2 は、ルーティング・エンジン・ベースの CPCD 用として指定されます。このセットは、CPCD サービス プロファイル redir-prof をサービス インターフェース si-4/0/0 に関連付けます。

CPCD サービス セットとサービス フィルターを論理インターフェイスにアタッチする

HTTP リダイレクト・サービスを使用するには、CPCD サービス・セットを論理インターフェースにアタッチする必要があります。ウォールド ガーデンがサービス フィルターとして構成されている場合は、サービス セットと同じインターフェイスにアタッチする必要があります。インターフェイスに到着してインターフェイスを離れるトラフィックは、サービスフィルターによってフィルタリングされます。サービス用に識別されたトラフィックは、CPCD プロファイルが適用されるルーティング エンジン サービス インターフェイスに送信されます。

  1. インラインサービスを有効にし、帯域幅を指定します。
  2. 論理インラインサービスインターフェイスを設定します。
  3. アドレスファミリーを設定します。
  4. サービスセットとサービスフィルターをインターフェイスにアタッチします。

    • 静的インターフェイス:

    • 動的インターフェイス

例えば、以下の設定では、シャーシ スロット4のラインカードと、ラインカードのスロット0のMICでインラインサービスを有効にします。論理インターフェイスにアドレスを割り当てます。その後、IPv4アドレスファミリーに対して、サービスセットsset2とサービスフィルター walled-v4をge-2/0/1.0にアタッチします。サービス セットとフィルターは、両方ともインターフェイスの入力と出力に適用されます。

HTTP サーバーがコンテンツ アクセスの制御に使用できる GET ヘッダー タグの挿入

場合によっては、HTTP サーバーでユーザーにコンテンツへのアクセスを許可するかどうかを決定することもできます。Junos OS リリース 19.1 以降では、ルーティング エンジンベースの静的 HTTP リダイレクト サービス フィルターを設定して、この目的でルーティング エンジンが HTTP GET メッセージのパケット ヘッダーに挿入するタグを指定できます。ルーターホスト名または加入者のMACアドレス、IPv4アドレス、またはIPv6アドレスのタグを挿入できます。

次の手順は 、図 1 に対応しています。

  1. ユーザーのデバイスである HTTP クライアントは、HTTP サーバーとの TCP ハンドシェイク シーケンスを実行します。

  2. ハンドシェイクが成功すると、クライアントはユーザーから要求された URL を含む HTTP GET を送信します。

  3. ルーティング エンジンは、/$ と $/ で囲まれたランダムな文字の文字列を連結して、その URL を変更します。文字列の長さは、後で挿入されるタグの結合長と一致します。この文字列は、クライアントから返されたときに識別子として機能します。

    挿入するタグの長さが 30 文字で、要求された URL が http://192.51.100.20/test.html とします。ルーティング エンジンは、次の例のように、30 個のランダム文字の文字列で変更された URL を返します。

    http://192.51.100.20/test.html/$IIGSbVdNDTDvnJFIAyoysXwVJawoYj$/

  4. ルーティング エンジンは、ステータス コードが 302(検出済み)または 307(一時リダイレクト)の変更された URL を送信します。送信されるコードは、使用する HTTP のバージョンと BNG 上の Junos OS のバージョンによって異なります。どちらのコードも、アクセス要求を変更された URL で再送信する必要があることをクライアントに示します。

  5. ルーティング エンジンは、クライアントとサーバーとの TCP 接続をリセットします。

  6. クライアントは、変更された URL に対して HTTP サーバーとの TCP ハンドシェイクを実行します。

  7. クライアントは、変更された URL を含む HTTP GET を送信します。

  8. ルーティング エンジンは、連結された文字列の長さがクライアントに送信されたのと同じかどうかをチェックします。

    • 長さが正しい場合は、URL を元の要求された URL に取り除き、タグを GET ヘッダーに挿入して、GET を HTTP サーバーに転送します。構成されている場合、GET は必要に応じて元の要求されたサーバーではなくリダイレクト URL に転送できます。

    • 長さが正しくない場合、ルーティング エンジンはパケットをドロップし、ドロップ カウンターをインクリメントします。

  9. HTTP サーバーは GET メッセージを評価し、要求が拒否された場合はアクセスを許可する場合は 200(OK)、または 403(禁止)の状態コードを持つ応答をクライアントに送信します。

  10. ルーティング エンジンは、クライアントとサーバーとの TCP 接続を終了します。

図 1: HTTP リダイレクト メッセージ フローのタグ挿入。 Tag Insertion for HTTP Redirect Message Flow.
メモ：

タグは、設定と同じ順序でヘッダーに挿入されます。タグ名は大文字と小文字を区別するため tag ABCD 、 tag abcd 異なる名前として処理されます。

GET ヘッダーに挿入するタグを設定するには:

  1. CPCD サービス構成レベルにアクセスします。
  2. 壁のある庭の外を宛先とするトラフィックに適用するルールを作成します。
  3. ルールが受信トラフィックに適用されるように指定します。
  4. (オプション)1つ以上の宛先アドレスを指定して、トラフィックをタグ付けにフィルタリングします。
    メモ：

    または、ファイアウォール サービス フィルターでトラフィックを識別するための宛先アドレスを指定することもできます。
  5. HTTP トラフィックにアクションを適用する CPCD のルール条件を定義します。ウォールド ガーデンはサービス フィルターとして構成されているため、トラフィックはサービスに送信される前に HTTP トラフィックとして既にフィルタリングされています。

例えば、以下の設定では、入力インターフェイス上のトラフィックに一致するサービス ルール(insert-rule)が作成されます。用語t1は、加入者のMACアドレスを持つx-mac-addrと、加入者のIPv4アドレスの値を持つx-sub-ipの2つのタグを挿入します。

以下のサンプル ルールでは、宛先アドレスが 198.51.100.50 または 198.51.100.75 と一致するトラフィックのみがタグ付けされます。タグは、加入者のIPアドレスとルーターのホスト名に挿入されます。ルールの 2 つ目の条件は、元の要求された URL にトラフィックが送信されるのではなく、トラフィックが転送されるリダイレクト URL を提供します。

ルーティング エンジンベース HTTP リダイレクトの CPCD サービス ルールと同様に、ルールを CPCD サービス プロファイルに含め、CPCD サービス セットを使用してプロファイルをインライン サービス インターフェイスに関連付ける必要があります。ルーティング エンジンは、ルールを使用して、サービス セットと同じ論理インターフェイス上のサービス フィルターによって渡された HTTP トラフィックを処理します。

次の設定例を検討してください。タグリダイレクトルールは、入力インターフェイス上のトラフィックを照合するように定義され、GETヘッダーに2つのタグ、加入者のIPアドレスの値、ルーターのホスト名を挿入します。その後、タグ付きトラフィックのリダイレクト URL がルールによって提供されます。このルールを含むように、CPCD サービス プロファイル http-insert-redirect が定義されています。

サービス セット sset1 は、ルーティング エンジンベースの CPCD 用として定義されます。CPCD サービス プロファイルをインライン サービス インターフェイスに適用します。

サービスフィルターの walled-tagは、192.0.2.100でウォールドガーデンに送信するHTTPトラフィック、198.51.100.50を宛先とするHTTPトラフィック、およびサービス処理に移動する他のすべてのトラフィックを識別し、機能します。これは、サービス ルールではなく、サービス フィルターで宛先アドレスを照会する例です。

サービスセットsset1とサービスフィルターウォールドタグは、論理インターフェイスに適用されます。

関連ドキュメント

リリース履歴テーブル
リリース
説明
19.1
Junos OS リリース 19.1 以降では、ルーティング エンジンベースの静的 HTTP リダイレクト サービス フィルターを設定して、この目的でルーティング エンジンが HTTP GET メッセージのパケット ヘッダーに挿入するタグを指定できます。