公共の場所でのキャプティブポータルの分散とAppleの問題

地下鉄について読んだ後、コメントしたかったのですが、別に書くことにしました。



分散キャプティブポータルを使用したパブリックネットワークの作成に参加し、ほぼすべての熊手を踏んだので、経験を共有したいと思います。



まず、これがどのように機能し、分散ポータルが中央集中型ポータルとどのように異なるかについての少しの理論です。 イデオロギー的に、キャプティブポータルと呼ばれていたものは、実際には3つのコンポーネントで構成されています。



Webフロントエンド -ユーザーと対話し、フォームに入力して広告を表示することで情報を収集するように設計されています。 ユーザーに個人情報とパスワードの入力を求める場合は、それぞれhttpsを使用する必要があります。サーバーには通常の証明書が必要です。 ユーザーの同意の下にチェックマークを付けるように依頼する場合は、httpで十分です。



実際、 キャプティブポータルは、Webフロントエンドを使用して収集された情報を受信、分析し、独自のリクエスト（RADIUSなど）で明確化リクエストを作成し、その結果に基づいて、ユーザーまたはWebを通じてユーザーに決定を報告するように設計された特定のエージェントですフロントエンド。 決定が肯定的な場合、captvieポータルは、このユーザーに必要なファイアウォールの穴を開きます。 指定された時間が経過すると、穴が閉じられ、ユーザーがWebフロントエンドに戻ります。 ユーザーが非アクティブであるため、ポータルは時期尚早に閉じられます。 多くの場合、セッション時間を制限する唯一の理由は、ユーザーに広告を再度表示することです（地下鉄のように行動したくない場合、他のサイトのデザインを損なう）



ファイアウォール -個々のユーザーのネットワークへのアクセスを認識しています。 イデオロギー上の理由でアクセスがない場合、ユーザーをWebフロントエンドにリダイレクトします。 技術的な理由でアクセスがない（ゲートウェイが応答しない）場合、「サービスはありませんが、すべてを修正しています」という特別なページにユーザーをリダイレクトするようにファイアウォールに指示できます。



集中型のキャプティブポータルの場合、3つのコンポーネントはすべて同じマシン（デバイス）に配置されるため、タスクが大幅に簡素化されます。 この場合のファイアウォールは多くの場合NATも実行し、キャプティブポータルはローカルのiptablesをひねる一連のスクリプトとして実装できます。 イーサネット上のすべてのユーザーをダンプするか、せいぜい別のVLANにダンプする安価なアクセスポイントのネットワークにプッシュすることは非常に魅力的です。 ここでの問題は何ですか：

• セキュリティの問題。 外部チャネルへのアクセスを制限していますが、ローカルネットワークではすべてが悪いです。 ネットワークが開いているため、すべてのユーザーがデフォルトゲートウェイに代わってarpに応答し、ユーザートラフィックを受信して​​フィッシングに従事できます。 「ブラウザは絶望的に古くなっている」などの文言でユーザーをプッシュするために、独自のDHCPサーバーを特定のデルタエリアに配置することは禁止されていません。 キャプティブポータルとユーザーがルータで分離されている場合、すべての結果でmacとipを一致させるキャプティブポータルを制御することができません。 無線クライアント間の通信が可能になります。 ワイヤレスクライアントが安価なポイントで通信するのを防ぐことができますが、他のポイントのクライアントは既にイーサネット経由で表示されています。
• 交通問題。 ローカルネットワークには多くの過剰なトラフィックがあります。 キャプティブポータルクライアントを開くよりもアクセスポイントを先に進まないことをお勧めします。
• スケーラビリティの問題。 多数の顧客の場合、3つのポータルコンポーネントのいずれかが問題になる可能性があります。

すでに推測されているように、分散キャプティブポータルはこれらの問題をすべて解決するように設計されています。 「分散」と言えば、コンポーネントを異なるデバイスに配置できると想定しています。 これにより、優れたスケーラビリティを備えながら、必要なレベルのセキュリティとサービスを提供する信頼性の高いシステムを作成できます。 解決しなければならない問題は、キャプティブポータルコンポーネント間の相互作用を保証することです。 ソリューションコンポーネントはどこに配置する必要がありますか？



ファイアウォールは、可能な限りクライアントの近くに配置する必要があります。 間違いなくアクセスポイントで。 複数のアクセスポイントがあり、それぞれに独自のファイアウォールがあるため、クライアントのローミングが想定される特定のスペースまたは領域内で作業を同期する必要があります。 そうしないと、ローミング時に通信の問題が発生します。 現代のネットワークでは、特定のドメイン（RFドメイン）内の何かの作業を同期するタスクは、任命されたアービトレーター（RFドメインマネージャー）を使用して実行され、分散キャプティブポータルを実装するタスクに関係なく、古代に解決されました。 このシステムでは、ファイアウォールの同期は、トラフィックの切り替え、ポイント構成の同期、統計情報の収集など、ドメイン内で調整された方法で実行する必要がある別のプロセスにすぎません。



Webフロントエンドの場所は、解決しなければならないタスクの複雑さに大きく依存します。 サーバー側の処理やSMSの送信などの問題を伴わないページを表示する必要がある場合は、アクセスポイントのサーバーで十分に対応できます。 ここでも、彼は可能な限りクライアントの近くにいて、最も効果的な対話を提供します。 異なるアクセスポイントでのWebサーバーのコンテンツの同期は、RFドメインのマネージャー（サプライズ）によって処理されます。



キャプティブポータルの場所は、Webフロントエンドの位置とポイントの可用性によって異なります。 キャプティブポータルの目的はファイアウォールをねじることであるため、各ポイントに独自の代表者（エージェント）が必要です。 ただし、Webフロントエンドはこれらのエージェントのコピーのいずれかと通信できます。これは、エージェントのステータス（推測）がドメイン内でも同期されるためです。



したがって、承認に成功したクライアントについては、キャプティブポータルがドメイン全体ですぐに開き、その後、いつでもドメインのすべてのアクセスポイントでこのクライアントのファイアウォールが同一に設定されるという状況を達成しています。

微妙

キャプティブポータルと対話する方法。 ユーザーインタラクションの結果をポータルに伝えることができるメカニズムが必要です。 この場合、このようなメカニズムとしてHTTP GETが選択されました。 必要に応じて、ポータルを開き、HTTP GETをその代表オフィスのいずれかに送信します。 GETに渡されるパラメーターの構成は、ポータルが動作するモードによって異なります。 以下にいくつかのオプションを示します。

• ポータルは常に開きます。 これをログに記録することができます。
• GETは、条件との合意を反映する変数があるときにポータルを開きます。
• ユーザー名とパスワードがGETに転送され、ポータル自体がこれらの属性を使用してRADIUSにクロールして開き、そこからACCEPTを受け取ります。
• 1つの（ユニバーサル）属性がGETに渡され、RADIUSにアクセスしてACCEPTを受信すると、ポータルはそれをユーザー名とパスワードの両方として示して開きます。 そのようなユーザーがRADIUSに存在する必要があることは明らかです。

このロジックを超えるものはすべて、Webフロントエンドでの実装が必要です。 たとえば、ユーザーに電話を求め、SMSを送信し、コードを確認できます。 結果に応じて-ユーザー名= phone_numberおよびパスワード= ip_IPでユーザーの半径（たとえば）に課金し、これらの値を使用してGETをポータルに送信します。



GETを受信したポータルは、どのユーザーが関与しているかをどのように判断しますか？ ユーザーをWebフロントエンドにリダイレクトすると、ポータルはかなり長い変数を呼び出しにアタッチします。これは、ポータルを開くためのリクエストのパラメーター間でそのまま戻す必要があります。



理想的には、ポイントはSSIDとワイヤ内の特定のVLANとの間のブリッジング（転送レベル2）を実行します。 つまり、ファイアウォールは第2（MAC）レベルで動作します。 ファイアウォールは、ネットワークの腸からクライアントに届くDHCPオファーを確認するため、IPを正確に認識し、クライアントではなくARPに応答し、ワイヤレスセグメント上のすべてのARPおよびDHCPを厳密にフィルタリングします。



ポイントのユーザーVLANにIPアドレスがないという事実により、ユーザーはポイントと直接通信する可能性がなくなります。 ただし、Webやポータルの場所をポイントに直接配置するなど、このような機会が必要な場合があります。 この場合、ダミーアドレス1.1.1.1が使用されます。

Appleはそれと何の関係があるのか

そして、地下鉄のように、どこにでもポータルがないことをiPhoneに説得するのはなぜですか。



ワイヤレスネットワークでのiPhoneの動作については、このメガプロダクトの作成者が1つのシナリオ、つまり1つのアクセスポイントのみを提案したという強い信念を開発しました。 つまり、自宅でも、流行に敏感なカフェでも。 2番目のケースでは、キャプティブポータルと会う偽のチャンスはありません。



1つのSSIDとキャプティブポータルで複数のポイントに遭遇した場合、iPhoneは何をしますか？ 彼は利用可能なすべてを試します。 それぞれで、彼は接続し、アドレスを要求し、長いリストからランダムなURLをチェックし（以前は一人でした）、捕虜があることを認識し、アドレスを提供し（dhcpリリース）、切断します。 この場合、2.4 GHzと5 GHzの両方で各ポイントから1つのSSIDが輝いているため、すべてが2倍になります。 「はい、どこにでも待ち伏せがあります！」という論理的な結論に達した後、iPhoneはポイントの1つに再び接続し、独自のミニブラウザーを描画します。 顧客とクライアントの用語では、このプロセスは「私の最後のiPhoneが非常に長い間ネットワークに接続している」と呼ばれ、「すべてが私の場所で私のルーブルで1000ルーブル飛ぶ」と呼ばれます。ドメイン「私たちは新しい乗客を持っています」、そしてMESHの場合-そこに並行して。 プロセス全体には最大20秒かかります。



2.4と5GHzで同じSSIDをすぐに検出した場合、iPhoneは何をしますか？ クライアントの機能とネットワーク帯域幅を最大限に活用して、チャネル、ポイント、範囲間でクライアントのバランスを取ることができると考えましたか？ Apple製品ではありません！ ネットワーク側から、両方の帯域のクライアントからのリクエストを聞いて、私たちはクライアントを必要な場所に接続させ、接続したくないポイントにリクエストをバイパスできると想定する権利があります。 通常、顧客はヒントを理解し、たとえば5Ghzに接続します。 iPhoneは2.4で最後まで壊れます。 永続的な場合は、個別のカウンターがあります（デフォルトでは20行のリクエスト）。 また、時間がかかります。



説明されている2つのプロセスは、ネットワークに接続されているときだけでなく、移動したときにも発生します。 ああ、新しいポイントがあります。 さて、確認しましょう...



iPhoneがミニブラウザーを起動し、（突然）SMSをクライアントに送信する必要がある場合、iPhoneはどうなりますか？ 上から小さなウィンドウにSMSが表示され、露出時間は約3秒です。 ブロンドはこの間6（6！）桁を覚えることができません。 ウィンドウが離れ、ユーザーがSMSで指を突くと、ミニブラウザーが閉じ、dhcpリリース、切断、3Gへようこそ。 悲しみの半分を抱えるユーザーは、コードを覚えて、設定にクロールし、ネットワークに接続し、電話番号を入力し、新しいSMSを取得します。 さらに、さらに...顧客とユーザーの用語では、これは「あなたのキャプティブポータルが私の最後のiPhoneで機能しない」および「地下鉄で既に修理済みです」と呼ばれています。

この状況は、ユーザーのMACをWebフロントエンドに送信することで修正できます（できます）。SMSを既に送信しており、2回目の呼び出しでコードを要求することを忘れないでください クッキーのため、このミニブラウザはサポートしていません。



このような不適切な動作の理由は何ですか？ 簡単です。デバイスの作成者は、コミュニケーションなしであなたを離れないという目標を設定しました。



あなたが訪問するようになったとしましょう。 閉じられたネットワークがありますが、良いホストはパスワードとボイルをあなたに言った-ここにそれはインターネットです。 スマートフォンはネットワークを記憶しており、次回のアクセス時に自動的に接続しました。 しかし、所有者はプロバイダーへの支払いを忘れており、今回はルーターより先に進まないようにしました。 つまり、あなたは何もせず、電話さえも取りませんでしたが、気づかないうちに外の世界とのコミュニケーションができなくなりました。 これは非常に悪いです。 これを回避するために、最新のモバイルデバイスは接続時にマルチステッププロセスを実行します。その目的は、コミュニケーションなしであなたを離れないことです。

1. IPを取得できません-切断します
2. デフォルトゲートウェイでARPが表示されない-切断されている
3. リストの単一のDNSではない-切断する
4. ドメインの1つに特定のURLをリクエストします。

   <HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

最後のステップが成功した場合、インターネットがあると想定し、3Gで降ります。 そのため、wifiへのすべての接続を行います。 自宅でも。

「成功」の代わりに何か間違ったことを観察した場合、ここにキャプティブポータルがあります。 ミニブラウザを起動します。 ユーザーは、ウィンドウ内のポータルに一度に同意できませんでした-切断します。 iPhoneの問題は、彼が最後まで最善を尽くすことを望んでいることです。 ネットワークへの接続を要求し、それが複数のポイントで表示される場合、すべてのオプションが試行されます。 時間は殺されます。 ポータルを見ているほとんどのデバイスは、おそらくどこにでもあることを示唆しています。



スローを停止する唯一の方法は、ポータル検出をバイパスすることです。 「User-Agent：CaptiveNetworkSupport」をフィルタリングするか、ドメインのリストを介してトラフィックをバイパスするという2つの方法で実装できます。 たとえば、地下鉄では、iMessageは閉じたポータルで動作します。



ポータルをバイパスした結果、ネットワークは何らかの形で表示されるか、すべてではありません。 いずれにせよ、これは非常に悪いことです。なぜなら、実際にはユーザーに見えない方法でユーザーにコミュニケーションをとらせないからです。



私たちの機器では、1つのコマンドで検出がオフになります：

 ap7131-ABCDEF(config-captive-portal-XXXXX)#bypass ? captive-portal-detection Captive portal detection requests(eg, Apple Captive Network Assistant ap7131-ABCDEF(config-captive-portal-XXXXX)#bypass captive-portal-detection