キャプティブポータルネットワーク接続はどのように機能しますか？
ホテル、空港のカフェでのインターネットアクセスは、多くの場合、キャプティブポータルによってゲートされ、最初の使用時に特定のWebページ（たとえば、支払いページや利用規約や認証/承認ページに同意するためのページ）に強制的にアクセスします。これは、無線接続と有線接続の両方で見られます。
これはどのように作動しますか？
確かにワイヤレス製品のベンダーによって異なりますが、私の経験では、通常は次のように機能します。
- ラップトップは、集中管理ステーションに接続されているインテリジェントアクセスポイントにワイヤレス接続します。
- 最初のWebリクエストが傍受され、ログイン/ポリシーページにリダイレクトする
Location:ヘッダー（例 http://hotelwireless.net/login ）で応答されます。これは、インテリジェントアクセスポイントまたは中央管理ステーションに直接存在する場合があります。 - 認証が完了すると、MACアドレスが許可されたクライアントのリストに追加され、今後の要求がインターネットまたはアクセス可能なイントラネットリソースに正しくルーティングされるようになります。
それを何と呼ぶかについては、「キャプティブポータル」または「ワイヤレスアクセスポータル」と呼ばれることが最も多いと聞きました。
最初にリダイレクトを実現するには、インライン認証システム（アクセスコントローラー）が必要です。トピックのコンテキストでは、APの集中管理を選択する場合、ワイヤレスLANコントローラーが必要になります。 ORウォールガーデン機能を備えたキャプティブポータルタイプのネットワークアクセスコントローラーを配置することもできます。
NASは無差別モードのrawソケットを介してダウンリンク（クライアント側）に入るトラフィックを監視し、ブラウザーが開始した未認証クライアントのトラフィックが検出されると、HTTPリダイレクトが応答として送信されます。そのため、受信時にブラウザーはキャプティブポータルホームページにリダイレクトされます。
このページの唯一の作業は、ユーザーに資格情報を入力するための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サーバーとの通信を開始します。