Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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

手記:

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

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

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

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

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

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

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

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

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

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

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

    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. (オプション)ウォールド ガーデン内のサーバーを指定するプレフィックス リストを定義します。サブネットまたは複数の個別のアドレスを指定できます。

    例えば、以下の構成では、IPv6 HTTPトラフィック用のフィルタ、walled-v6-listを作成し、プレフィックスリストwg-listで、ウォールドガーデンに2台のサーバーを指定します。フィルター条件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(ウォールド ガーデンの外側)を追加したリダイレクト URL を指定します。

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

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

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

サービス プロファイルとサービス インターフェイスを関連付けるためのサービス プロファイルおよびサービス セットの設定

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

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

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

論理インターフェースへの CPCD サービス・セットとサービス・フィルターのアタッチ

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

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

    • ダイナミックインターフェース

例えば、以下の設定では、ラインカードのシャーシ スロット 4 のラインカードとスロット 0 の MIC でインライン サービスが有効になります。論理インターフェイスにアドレスを割り当てます。次に、サービス セット sset2 とサービス フィルター walled-v4 を IPv4 アドレス ファミリの 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. ルーティング エンジンは、変更された URL をステータス コード 302 (Found) または 307 (一時リダイレクト) で送信します。送信されるコードは、使用されている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 ABCDtag 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 トラフィックを処理します。

次の構成例を考えてみます。tag-redirect ルールは、入力インターフェイス上のトラフィックを照合し、加入者の IP アドレスの値とルーターのホスト名の 2 つのタグを GET ヘッダーに挿入するように定義されています。次に、ルールはタグ付けされたトラフィックのリダイレクト URL を提供します。CPCD サービス・プロファイル http-insert-redirect は、この規則を含むように定義されています。

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

サービスフィルターwalled-tagは、192.0.2.100のウォールドガーデンに送信するHTTPトラフィック、198.51.100.50を宛先とするHTTPトラフィックがサービス処理に送信され、その他すべてのトラフィックをスキップする3種類のトラフィックを識別して動作します。これは、サービス ルールではなく、サービス フィルターで宛先アドレスを照合する例です。

サービスセットsset1とサービスフィルターの壁付きタグが論理インターフェイスに適用されます。

変更履歴テーブル

機能のサポートは、使用しているプラットフォームとリリースによって決まります。 機能エクスプローラー を使用して、機能がプラットフォームでサポートされているかどうかを判断します。

解放
形容
19.1
Junos OS リリース 19.1 以降、ルーティング エンジンベースの静的 HTTP リダイレクト サービス フィルターを構成して、ルーティング エンジンが HTTP GET メッセージのパケット ヘッダーに挿入するタグを指定できます。