回答:
確かにワイヤレス製品のベンダーによって異なりますが、私の経験では、通常は次のように機能します。
Location:され、ログイン/ポリシーページにリダイレクトするヘッダー（例：http : //hotelwireless.net/login）で応答されます。これは、インテリジェントアクセスポイントまたは中央管理ステーションに直接存在する場合があります。それを何と呼ぶかについては、「キャプティブポータル」または「ワイヤレスアクセスポータル」と呼ばれることが最も多いと聞きました。
Sign-in to Network基本的にそのポータルページを表示するだけのアプリ（デフォルトのブラウザーではない）を起動します。関連する新しいプロトコルはありますか？その仕様は何ですか？
最初にリダイレクトを実現するには、インライン認証システム（アクセスコントローラー）が必要です。トピックのコンテキストでは、APの集中管理を選択する場合は、ワイヤレスLANコントローラーが必要になります。または、ウォールガーデン機能を備えたキャプティブポータルタイプのネットワークアクセスコントローラーを配置することもできます。
NASは無差別モードのrawソケットを介してダウンリンク（クライアント側）に入るトラフィックを監視し、ブラウザーが開始した非認証クライアントのトラフィックが検出されると、HTTPリダイレクトが応答として送信されます。そのため、受信時にブラウザーはキャプティブポータルホームページにリダイレクトされます。これは、オーセンティケーターにインラインでホストすることも、外部Webサーバーですぐにホストすることもできます。
このページの唯一の作業は、ユーザーに資格情報を入力するためのUIを提供することです。入力された資格情報は、coovaチリの場合はチリのようにオーセンティケーターデーモンに転送されます。さらに、これらの資格情報は、RADIUSリクエストとしてRADIUSサーバーに渡されるか、ローカルでチェックされます。認証が成功すると、オーセンティケーターでのクライアントの状態は承認済みとしてマークされ、クライアントはアクセスを許可されます。
最も広く使用されているアプローチは、ユーザーが開始したHTTPリクエストとクライアントへの応答としての302コードをインターセプトすることです。唐辛子では、以下の関数を介して行われます
http_redirect2() {
cat < < EOF
HTTP/1.1 302 Redirect
Location: $1
Set-Cookie: PORTAL_SESSIONID=$PORTAL_SESSIONID
Set-Cookie: COOVA_USERURL=$COOVA_USERURL
Connection: close
EOF
exit
}
このリダイレクションは、クライアントトラフィックを傍受するクライアント側インターフェイスへの実用的に制御されたtun tapインターフェイスを簡単に実現できます。DNSポイズニングを使用してさらにリダイレクトを行うこともできますが、応答がクライアントブラウザでキャッシュされた場合に問題が発生することがあります。問題ドメインに応じて、さらに具体的に行うことができます。必要に応じてお手伝いします。
これについては、https：//www.arubanetworks.com/vrd/GuestAccessAppNote/wwhelp/wwhimpl/js/html/wwhelp.htmに詳しい説明があります。
これはその一部です：
キャプティブポータル認証プロセス
キャプティブポータルはレイヤ3認証であり、デバイスがネットワークに接続し、キャプティブポータルを介して認証する前にIPアドレスと関連するDNS情報を取得する必要があります。次の手順は、ネイティブArubaOSがキャプティブポータル認証に使用される場合のキャプティブポータルプロセス全体を説明しています。
1.ゲストSSIDに関連付けられているデバイスには、初期ロール（設定例ではゲストログオンロール）が割り当てられています。この初期の役割ではDHCPが許可されるため、ユーザーはIPアドレスを取得します。
2.ユーザーがブラウザーを開き、ある宛先（例えば、www.bbc.com）にHTTP（またはHTTPS）要求を出します。
3.デバイスのリゾルバーは、www.bbc.comを解決するためのDNS要求を送信します。最初の役割（guest-logon役割）はDNSサービスを許可するため、リゾルバーはDNSサーバーと通信できます。
4. DNSサーバーは、www.bbc.comに正しいアドレスで応答します。
5.リゾルバーは、DNS応答に基づいて、使用するIPアドレスをブラウザーに通知します。
6.ブラウザは、www.bbc.comアドレスのポート80へのTCP接続を開始します。
7.コントローラーは接続をインターセプトし、HTTPプロセスの初期TCPハンドシェイクをスプーフします。この時点で、クライアントブラウザーは、bbc.comサーバーと通信していると見なします。
8.ブラウザーがWebページのHTTP GET要求を送信すると、コントローラーはbbc.comがに「一時的に移動した」と応答します。
9.ブラウザが接続を閉じます。
10.ブラウザはとの接続を試みますが、最初にアドレスのDNS要求を送信する必要があります。
11.実際のDNSサーバーはhttps://securelogin.arubanetworks.comを解決できないと応答し ますが、コントローラーはその応答をインターセプトし、パケットを変更して、securelogin.arubanetworks.comがコントローラー自体のIPアドレスにあることを通知します。DNSサーバーがクエリへの返信を返すことが重要であることを忘れないでください。コントローラーがDNSサーバーからの応答を偽装できるのは、そのときだけです。応答がないとDNS要求を送信するだけでは十分ではありません。応答がないと、コントローラーはクライアントがsecurelogin.arubanetworks.comを解決するのを助けることができないからです。
12.ブラウザーはコントローラーのアドレスへのHTTPS接続を開始します。コントローラーのアドレスは、ゲストが認証するキャプティブポータルのログインページで応答します。
13.認証に成功すると、ユーザーには認証後の役割（設定例ではauth-guest役割）が割り当てられます。これは、キャプティブポータルプロファイルのデフォルトの役割です。
14.認証後、ブラウザはDNSによって最初に解決されたアドレスでbbc.comにリダイレクトされます。または、ウェルカムページが設定されている場合、ブラウザはウェルカムページにリダイレクトされます。
15.元のWebページに正常にリダイレクトするために、コントローラーはbbc.comからの応答をスプーフし、bbc.comがbbc.comに「完全に移動」したことをクライアントに通知します。この手順により、キャプティブポータルログインの一部として発生した「一時的な再配置」が修正されます。
16.これにより、クライアントはwww.bbc.comのアドレスをDNSに再クエリします。
17.ブラウザが実際のbbc.comサーバーとの通信を開始します。