スプラッシュページの通信の流れとトラブルシューティング
このドキュメントは原文を 2023 年 06 月 13 日付けで翻訳したものです。
最新の情報は原文をご確認ください。
導入
スプラッシュページとはウェブベースの認証方法の一つで、クライアントにネットワークへの完全なアクセスを許可するために、ボタンのクリック(Click-through Splash Page)または認証情報の提供(Sign-on Splash page)を要求する仕組みです。認証の前に、クライアントのネットワークアクセスは "Captive Portal" によって制限されます。スプラッシュ認証が完了すると、クライアントのキャプティブポータルは削除され、完全なネットワークアクセスが許可されます。
このドキュメントでは、さまざまなタイプのスプラッシュページの機能とトラフィックの流れ、および一般的な問題やトラブルシューティングの手順について詳しく説明しています。
注: スプラッシュ認証は、セキュリティのためにHTTPSを使用します。トラフィックは暗号化されているため、従来のパケットキャプチャ解析ではスプラッシュフローを解析することはできません。本ドキュメントでは、クライアント端末にインストールされたweb proxyを使用してフローを解析しています。このプロキシソフトウェアは HTTPS トラフィックを復号し、内部の HTTP トラフィックを確認できます。スプラッシュフローの解析には、どのWebプロキシソフトウェアも使用できますが、このドキュメントではBurpを使用して解析されています。
認証状況を確認する
スプラッシュページでクリックスルーやサインオンを終えていないクライアントは”認証されていない”状態です。そのようなクライアントはクライアントの詳細ページに "スプラッシュ : 未認証 (Not authorized)" と表示されます。

認証されていないクライアントの場合、ネットワークアクセスはSSID上のキャプティブポータルの強度とウォールドガーデンの設定により制限されます。
- キャプティブポータルの強度:クライアントが認証を行う前にアクセス可能なネットワークの範囲を定義します。
- ウォールドガーデン: キャプティブポータルの強度によらず、未認証のクライアントがアクセス可能な IP アドレス(範囲)、ホストを定義します。
未認証のクライアントは、ウォールドガーデンで指定されたIPアドレス(範囲)、ホストを除き、キャプティブポータルの外のネットワークリソースにアクセスできません。
認証に成功すると、クライアントの詳細ページに "認証済み(Authorized)" と表示され、現在の認証の有効期限が切れるまでの残り時間が表示されます:

認証の有効期限が切れたり、(取り消しオプションをクリックして)アクセスが取り消されたりすると、キャプティブポータルに戻されることになります。ネットワークへの完全なアクセスを再開するには、再度スプラッシュ認証が必要です。
クライアントがキャプティブポータルに入った後、インターネットへのアクセスをブロックするには、スプラッシュのキャプティブポータルの強度を SSID のアクセス制御ページで「サインオンが完了するまですべてのアクセスをブロック」に設定することが重要です(これは、クライアントを SSID から切り離さず、インターネットアクセスのみをブロックします)。これを怠ると、認証が切れた後でもクライアントはネットワークを使い続けることができます。現在最も多いトラフィックは HTTPS ですが、キャプティブポータルの強度が「サインオン前に非HTTPトラフィックを許可する」に設定されている場合でも許可されています。スプラッシュページがクライアントに再び表示されるのは、スプラッシュの認証が切れた後、クライアントがHTTP GETを送信したときのみです。
サインオンスプラッシュページが設定されている場合、ログイン試行はダッシュボードに連携され、ワイヤレス > Splashログイン および ログイン試行で確認できます。
ワイヤレス > Splashログインページ

ワイヤレス > ログイン試行

スプラッシュの通信の流れ
スプラッシュ認証時の通信の流れについてこのセクションで解説します。スプラッシュのプロセスは大きく分けて以下の 3 つのステップに別れます。
- 
    スプラッシュ URL の取得 
- 
    ダッシュボード上での認証 
- 
    continue_url の取得 
スプラッシュ URL の取得
スプラッシュ認証は常に同じ方法で始まります。未認証のクライアントが Web ページに対する HTTP GET リクエストを送信する必要があります。AP は認証されていないクライアントからのリクエストと判断し、クライアントをスプラッシュ URLにリダイレクトさせます。以下の図とHTML出力は、リダイレクトプロセスの詳細を示しています:

HTTP GETを送信する前に、クライアントはまず URL の IP アドレスに TCP SYN を送信し、AP がそのサイトの代わりに TCP SYN ACK を返信し、その後、クライアントは HTTP GET を送信します。これはワイヤレス/モニターモードのキャプチャでのみ確認でき、APのイーサネットの macアドレスとなる送信元 mac アドレスを見ることで、AP が実際のサイトの代わりに応答していることを識別できます。他のパケットでは、ソースmac アドレスはデフォルトゲートウェイの mac アドレスになります。
| パラメーター | 値 | 機能 | 
| splash URL | クライアントがスプラッシュ認証を行うために誘導される URL | |
| continue_url | 認証完了後、クライアントが誘導される URL | 
AP は未認証クライアントから送信された HTTP GET リクエストを検出すると、それを傍受し、HTTP 307 Temporary Redirect を返し、クライアントにスプラッシュURL を取得するように通知します。スプラッシュURL には、continue_url パラメータも含まれています。このパラメータは、スプラッシュ認証セッション中に使用され、リダイレクトされる前にクライアントがもともと取得しようとしていたウェブサイトをクラウドに通知します:

APからリダイレクトレスポンスを受け取ったクライアントは、スプラッシュURLの HTTP GETをクラウドに送信します:

ダッシュボード上での認証
Splashの認証は2段階で行われます まず、クライアントがダッシュボードで認証用 URL を取得し、次にクラウドからネットワーク内の他のすべてのAPにクライアント認証が通知されます。このステップはスプラッシュページの種類によって異なるため、このセクションでは以下のページの認証プロセスについて説明します
- 
    クリックスルースプラッシュページ 
- 
    サインオンスプラッシュページ 
クリックスルースプラッシュページ
クリックスルーのスプラッシュページが設定されている場合、認証情報は認証に使用されません。代わりに、"Continue "ボタンをクリックすることで認証が行われます。以下の図とHTML出力は、このプロセスを詳細に示しています:

HTTP GETを送信する前に、クライアントはまず URL の IP アドレスに TCP SYN を送信し、AP がそのサイトの代わりに TCP SYN ACK を返信し、その後、クライアントは HTTP GET を送信します。これはワイヤレス/モニターモードのキャプチャでのみ確認でき、APのイーサネットの macアドレスとなる送信元 mac アドレスを見ることで、AP が実際のサイトの代わりに応答していることを識別できます。他のパケットでは、ソースmac アドレスはデフォルトゲートウェイの mac アドレスになります。
| パラメータ | 値 | 機能 | 
| splash URL | クライアントがスプラッシュ認証を行うために誘導される URL | |
| grant URL | https://nX.network-auth.com/<ssid name>/hi/1234567/grant? | クリックスルースプラッシュページの URL | 
| continue_url | 認証後にクライアントが誘導される URL | |
| cookie | p_splash_session | セッションの Cookie | 
| grant_user_access URL | nX.network-auth.com/splash/grant_user_access/?key | AP 側の認証のためにクライアントが誘導される URL | 
クラウドはスプラッシュ URL の GET リクエストを受け取ると、クリックスルーのスプラッシュページとセッションCookie とともにHTTP 200 OKを返します

クリックスルーのスプラッシュページの HTML を調べると、grant URLに continue_urlパラメータが付加されているのがわかります
ユーザーは Continue ボタンをクリックし、Cookie とともに continue_url が付加された grant URLの GET を送信します

クラウドが grant URL のリクエストを受信すると、クライアントは認証されます。クラウドは HTTP 302 Found メッセージで応答し、クライアントを grant_user_access URL へとリダイレクトします。
また、クラウドは、ネットワーク内のすべてのAPにクライアントの認証を通知します。この時点でAPはクライアントデバイスのキャプティブポータルを解除し、ネットワークへのフルアクセスが許可されます

最後に、クライアントはgrant_user_accessのURLに対してHTTP GETを送信します。
サインオンスプラッシュページ
サインオンスプラッシュページが使用されると、ユーザーはログイン認証情報の入力を要求されます。認証情報は、HTTP POST を使用してクラウドに送信されます。クラウドは ダッシュボード で設定されたサーバータイプ(Meraki 認証、RADIUS、Active Directory、LDAP)に基づいてユーザーアカウントを認証し、成功するとクライアントにネットワークへのフルアクセスを許可します。以下の図と HTML 出力は、このプロセスの詳細を示しています。

HTTP GETを送信する前に、クライアントはまず URL の IP アドレスに TCP SYN を送信し、AP がそのサイトの代わりに TCP SYN ACK を返信し、その後、クライアントは HTTP GET を送信します。これはワイヤレス/モニターモードのキャプチャでのみ確認でき、APのイーサネットの macアドレスとなる送信元 mac アドレスを見ることで、AP が実際のサイトの代わりに応答していることを識別できます。他のパケットでは、ソースmac アドレスはデフォルトゲートウェイの mac アドレスになります。
| パラメータ | 値 | 機能 | 
| splash URL | クライアントがスプラッシュ認証プロセスを始めるために誘導される URL | |
| login URL | https://nX.network-auth.com/<ssid name>/hi/1234567/login? | サインオンスプラッシュページの URL | 
| continue_url | http:www.google.com | 認証後にクライアントが誘導される URL | 
| cookie | p_splash_session=<string value> | セッションの Cookie | 
| grant_user_access URL | nX.network-auth.com/splash/grant_user_access/?key | AP 側の認証のためにクライアントが誘導される URL | 
クラウドはスプラッシュURLの GET リクエストを受け取ると、サインオンスプラッシュページとセッション Cookie とともに HTTP 200 OK を返します

サインオンスプラッシュページの HTML コードを見ると、ユーザー情報を入力するためのウェブフォームと、continue_urlパラメータで付加されたログインURL が含まれていることがわかります

ユーザーはユーザー名とパスワードを入力し、サインインボタンをクリックします。このアクションにより、クッキーとともにcontinue_urlパラメータが付加されたログインURL(Cloud)への認証情報のHTTP POSTが生成されます。
 クラウドは認証情報を受け取り、設定されたサーバータイプに対してユーザーを認証します。認証に成功すると、クラウドはクライアントを grant_user_access URL にリダイレクトする HTTP 302 Found を返します。さらに、クラウドはネットワーク内のすべての AP にクライアントの認証を通知し、キャプティブポータルが解除され、クライアント端末はネットワークにフルアクセスできるようになります
クラウドは認証情報を受け取り、設定されたサーバータイプに対してユーザーを認証します。認証に成功すると、クラウドはクライアントを grant_user_access URL にリダイレクトする HTTP 302 Found を返します。さらに、クラウドはネットワーク内のすべての AP にクライアントの認証を通知し、キャプティブポータルが解除され、クライアント端末はネットワークにフルアクセスできるようになります

外部のキャプティブポータル(EXCAP)を使用したスプラッシュ認証
外部キャプティブポータル(以後、"EXCAP")を使用したクリックスルー型スプラッシュページとEXCAP サーバーを使用したサインオン型スプラッシュページは、プライベートサーバーでスプラッシュページを外部ホストする場合にのみ使用するようにしてください。ここでは、以下のページでの認証処理について説明します:
EXCAP を使用したクリックスルースプラッシュ
注:カスタムホスト型スプラッシュページの詳細については、「Configuring a Custom-Hosted Splash Page」や「Captive Portal Solution Guide」を参照してください。
EXCAP でクリックスルーのスプラッシュページを設定した場合、外部でホストされたカスタムスプラッシュページの「Continue」ボタンをクリックすることで認証が行われます。下図は、この処理中のトラフィックフローを説明するものです:

| パラメータ | 値 | 機能 | 
| splash URL | クライアントがスプラッシュ認証を開始するために誘導される URL | |
| base_grant_url | EXCAP が grant URL に使用する値 | |
| user_continue_url | EXCAP が continue_url に使用する値 | |
| cookie | p_splash_session=<string> | 認証行うセッションの Cookie | 
| grant URL | クリックスルースプラッシュ認証の URL | |
| continue_url | クライアントが認証後に誘導される URL | |
| grant_user_access URL | nX.network-auth.com/splash/grant_user_access/?key | AP側で認証を行うためにクライアントが誘導される URL | 
クラウドはスプラッシュ URL の GET リクエストを受け取ると、セッション Cookie とともに、クライアントをカスタムスプラッシュ URL にリダイレクトする HTTP 302 Found を返します:
クライアントはレスポンスを受信し、EXCAP サーバーにホストされているカスタムスプラッシュ URL に対して GET リクエストを送信します。EXCAP サーバーは、リクエストの base_grant_url と user_continue_url パラメータを使用して、スプラッシュページの 認証URL を生成します。
 EXCAP サーバーは、カスタムスプラッシュ URL の GET リクエストを受信すると、カスタムクリックスルースプラッシュページとともに HTTP 200 OKを返します。このページには、continue_url パラメータで指定されたgrant URL を指す認証 URL が含まれている必要があります。
EXCAP サーバーは、カスタムスプラッシュ URL の GET リクエストを受信すると、カスタムクリックスルースプラッシュページとともに HTTP 200 OKを返します。このページには、continue_url パラメータで指定されたgrant URL を指す認証 URL が含まれている必要があります。

ユーザーが Continue ボタンをクリックすると、Cookieとともにcontinue_urlが付加されたグラントURLのGETが送信されます クラウドが grant URL のリクエストを受信すると、クライアントは認証されます。クラウドは、クライアントを grant_user_access URL にリダイレクトする HTTP 302 Found で応答します。また、クラウドはネットワーク内のすべてのAPに、クライアントの認証を通知します。この時点で、APはクライアントデバイスのキャプティブポータルを解除し、ネットワークへのフルアクセスが許可されます。
クラウドが grant URL のリクエストを受信すると、クライアントは認証されます。クラウドは、クライアントを grant_user_access URL にリダイレクトする HTTP 302 Found で応答します。また、クラウドはネットワーク内のすべてのAPに、クライアントの認証を通知します。この時点で、APはクライアントデバイスのキャプティブポータルを解除し、ネットワークへのフルアクセスが許可されます。
 最後に、クライアントはgrant_user_accessのURLに対してHTTP GETを送信します。
最後に、クライアントはgrant_user_accessのURLに対してHTTP GETを送信します。

EXCAP を使用したサインオンスプラッシュ
EXCAPによるサインオンスプラッシュページは、外部でホストされたカスタムスプラッシュページを使用し、ユーザーにログイン認証情報を要求するように構成されています。認証情報は、HTTP POST を使用してクラウドに送信されます。その後、クラウドは ダッシュボードで設定されたサーバータイプ(Meraki 認証、RADIUS、Active Directory、LDAP)に基づき、ユーザーアカウントを認証します。
下の図とHTML出力は、その詳細を示しています:

| パラメータ | 値 | 機能 | 
| splash URL | クライアントがスプラッシュ認証を開始するために誘導される URL | |
| login_url | nX.network-auth.com/splash/login?mauth | EXCAP が使用する ログイン URL | 
| continue_url | EXCAP が使用する continue_url | |
| cookie | p_splash_session=<string> | 認証セッションの Cookie | 
| login URL | nX.network-auth.com/splash/login?mauth | サインオンスプラッシュ認証ページの URL | 
| grant_user_access URL | nX.network-auth.com/splash/grant_user_access/?key | AP側の認証のためにクライアントが誘導される URL | 
クラウドはスプラッシュURLのGETリクエストを受け取ると、セッションCookieとともに、クライアントをカスタムスプラッシュURLにリダイレクトするHTTP 302 Foundを返します。

クライアントはレスポンスを受信し、EXCAP サーバーにホストされているカスタムスプラッシュ URL に対して GET リクエストを送信します。EXCAPサーバーは、スプラッシュページの認証 URL を構築するために、リクエスト内の login_urlとcontinue_url パラメータを使用する必要があります。

EXCAP サーバーは、カスタムスプラッシュ URL の GET リクエストを受信すると、カスタムサインオンスプラッシュページと一緒に HTTP 200 OK を返します。これは、ユーザー認証情報を入力できる Web フォームである必要があります。リクエストには、ログイン URL を指す認証 URL が含まれていなければならず、continue_url パラメータが付加されています:

ユーザーがユーザー名とパスワードを入力してサインインボタンをクリックすると、認証情報とクッキーがHTTP POSTでログインURL(Cloud)にcontinue_urlを付加して送信されます。



continue_URL の取得
grant_user_access URL のリクエストを受信すると、クラウドは continue_url パラメータで指定した URL(この例では、www.google.com)に対して HTTP 302 Found で応答します。クライアントは Captive Portal の対象から外れるため、以下のように Web サイトにアクセスできるようになります。

クラウドは、continue_urlを含む HTTP 302メッセージを送信します。

その後、クライアントはcontinue_urlに対してHTTP GETを送信します。

発生しやすい問題の特定と抑制
スプラッシュページ使用時にクライアントが経験する一般的な問題を特定し、それを抑制する方法について説明します。
未認証のクライアントがネットワークにフルアクセス可能
未認証のクライアントがネットワークに完全にアクセスでき、ホワイトリストに登録されていない場合は、以下を確認してください。
- 
    ワイヤレス > アクセス制御 > キャプティブポータルの強度 で、「サインオン前に非HTTPトラフィックを許可する」設定が有効になっていますか?この設定は、認証前にHTTP(TCPポート80)を除く完全なネットワークアクセスを許可します。クライアントが認証またはホワイトリストに登録されることなく、ウォールドガーデン外のネットワークリソースにアクセスすることを望まない場合は、キャプティブポータルの強度設定を「サインオン前のすべてのアクセスをブロック」に設定する必要があります。 
- 
    コントローラー切断時の挙動が「オープン」に設定されていて、スプラッシュ URLや Cloud コントローラーが到達不可能な場合、スプラッシュ URLが利用可能になるまで、クライアントはフルアクセスを許可されます。これを「制限付き」に設定すると、URL が利用可能になるまでネットワークアクセスがブロックされます。 
接続がタイムアウトする
未認証のクライアントが Web サイトへアクセスしようとしたときにスプラッシュページに誘導されずブラウザで接続タイムアウトエラーを報告した場合、キャプティブポータルの強度が「サインオン前のすべてのアクセスをブロック」に設定されており、Webサイトへアクセスするときにクライアントが HTTPS を使用している可能性があります。
未認証のクライアントのウェブブラウザが TCP ポート80でHTTP GETを送信すると、Meraki デバイスはそのリクエストを確認し、インターセプトして、スプラッシュサーバへのリダイレクトで応答することができます。未認証のクライアントがウォールドガーデン外のウェブページに HTTPS を使ってアクセスする場合、トラフィックは暗号化されています。そのため、AP はクライアントをうまくリダイレクトすることができず、トラフィックがブロックされることになります。このような場合、クライアントが HTTP を使用してウェブページにアクセスしていることを確認し、適切にリダイレクトできるようにしてください。
カスタム URL に到達できない
EXCAP を実装している環境でクライアントがカスタム URLにアクセスできない場合以下を確認してください。
- 
    EXCAP ウェブサーバーがウォールドガーデンに追加されているか 
- 
    ダッシュボード上に設定されているカスタム URL のフォーマットが正しいか 
- 
    EXCAP サーバー上にダッシュボードで設定した URL が存在しているか 
- 
    EXCAP サーバー上でウェブサービスが稼働していて、カスタム URL に直接アクセスができるか 
リダイレクトが多すぎます
未認証 クライアントが、EXCAP がホストするスプラッシュページではなく、ブラウザで「リダイレクトが多すぎます(too many redirects)」エラーを受け取った場合、EXCAP サーバーの IP アドレスまたはホスト名がウォールドガーデンに追加されていない可能性があります。「リダイレクトが多すぎる」エラーは、クライアントがスプラッシュサーバーから EXCAP のスプラッシュページにリダイレクトされても、そのスプラッシュページへのアクセスが許可されていないために発生します。そのため、AP は EXCAP リクエストをスプラッシュサーバーにリダイレクトし、ブラウザがタイムアウトするまでループし続けます。
そのため、認証前に EXCAP にリダイレクトされるため、ウォールドガーデンを有効にし、EXCAP サーバーの正しい IP アドレスまたはホスト名を指定する必要があります。
認証後空白ページが表示される
スプラッシュページで認証した後、空白のページが表示される場合は、ブラウザがCookieを許可していない可能性があります。また、クライアントの詳細ページでは、認証後に「未認証(Unauthorized」と表示されることもあります。
Cookie は、スプラッシュページが個々のお客様のセッションを追跡するために使用されます。ユーザーがスプラッシュページへアクセスする際にCookie が存在しない場合、スプラッシュサーバーはセッションを識別できず、クライアントを認証することができません。このような場合、Webブラウザがセッションクッキーを受け入れ、削除していないことを確認してください。

