アクセスポイントとは別のデバイス上のキャプティブポータル
使用されているアクセスポイント/ルーターに依存しないホームWiFi用の認証システムをセットアップしようとしています。この認証システムはキャプティブポータルモデルに厳密に従いますが、（カスタム）キャプティブポータルの詳細は重要ではないと思います。
これを実現するために、キャプティブポータルと認証を安価なデバイス（Raspberry Piなど）でホストしたいと思います。ただし、ユーザーが自分自身を認証した後、ユーザーを別のアクセスポイントに再接続してほしい。つまり、Raspberry Piはのみ認証ステップを実行しますが、認証されたユーザーの通常の使用アクセスポイントとしては機能しません。繰り返しになりますが、これは通常のパスワードで保護されたWiFiネットワークを持つすべてのアクセスポイント/ルーターで最適に機能します。
このプロジェクトに必要なログインフローは次のとおりです。
- ユーザーがWiFi対応のRaspberryPiに接続する
- ユーザーは、Piでホストされているキャプティブポータルサイトに移動し、ログインします
- （認証が成功したと仮定）ユーザーはPiから切断され、メインアクセスポイントに接続されます
- ユーザーは通常どおりWebを閲覧できるようになりました
このようなことを達成する方法はありますか？ Raspberry Piをセットアップして両方アクセスポイントとキャプティブポータルとして機能するようにする方法を知っていますが、キャプティブポータルとしてだけではありません。
「ルーブゴールドバーグ」タイプの配置を使用して可能かもしれませんが、これを安全に行うことは実際には実行可能ではありません。
PIでDHCPルーターをカスタマイズし、リリースされるまでの短いリース時間を提供し、配布されたIPアドレスを変更する（ルーターでDHCPを有効にしない）ことで、大まかに行うことができると思いますが、そうすると、膨大な量になります。いくつかの単純な静的アドレス指定でこれを回避できないことを保証する戦い。
キャプティブポータル以外のデバイスからWAN）へのポートDNS（ポート53要求）を禁止するルーターの協力とほぼ同様のことを達成でき、配布することができる場合があります。 DHCPを使用したキャプティブポータルDNS、およびユーザーが解放されるまでキャプティブポータルが自身にDNS応答を提供するようにします。ただし、これは単純なVPNまたはトンネルで破壊される可能性があります。
見た目よりもずっと難しいですが（暇なときに遊んでいるものですが、それほど多くはありません！）、ルーターによっては、DD-WRTの最新バージョンに組み込まれている「WildDog」のようなものになります。 -あなたのために働きます-ルーターが基礎となるキャプチャを行い、ポータルの仕事を別のデバイスに引き渡すように見えます。
OpenBSDがRaspberryPiで実行されている場合、authpfを使用して、各ユーザーがpubkey/passwordを使用してセッションを認証し、そのような認証されたクライアントがファイアウォールを通過できるようにすることができます。ただし、フィルタリングを担当するルーターで直接機能するのが最適です。実装の例については、 https://www.openbsd.org/faq/pf/authpf.html 、およびgoogleを参照してください。
よりユーザーフレンドリーなオプションは次のようなものです https://coova.github.io/CoovaChilli/ 積極的に維持されているようで、RADIUSサポートがあります。
繰り返しますが、最適には、これはどのアクセスポイント/ルーターでも機能します
アクセスポイントはWi-Fi（リンク層）を処理し、ルーターはIP（ネットワーク層）を処理します。多くの場合、1つのプラスチックの箱にまとめられますが、それでも2つの異なる機能を実行します。
したがって、キャプティブポータルの考え方は、パケットの通常のパスに沿ったデバイスがパケットを傍受し、偽の「リダイレクト」応答を生成して、ユーザーにログインページにアクセスする必要があることを通知するというものです。リダイレクトは次の方法で実行できます。
- iptables（最も一般的な方法）を使用してTCP接続全体をインターセプトすることによるデフォルトゲートウェイ（ルーター））。
- dNSサーバー。「キャプティブ」サーバーを指す偽のDNSルックアップ応答を返します（信頼性が低く、バイパスが非常に簡単です）。
- パケットが別のゲートウェイに到達するようにパケットヘッダーを書き換えることによるアクセスポイントまたはスイッチ（非常にまれが技術的には可能）…
ただし、いずれの場合も、「キャプティブポータル」のラズベリーhasは通常のパスに挿入されます。 「偽のDNSサーバー」方式（トラフィックをほとんど処理しないが、バイパスも非常に簡単）を使用して構築した場合でも、少なくともラズベリーを提供するためにメインルーターを再構成する必要がありますDHCP経由のIPアドレス。
（そして、多くの安価なワイヤレスルーターでは、実際にはconfigure that –通常のDHCPサービスをオフにし、DHCPを完全にRaspberryから提供する必要があると思います。）
つまり、いいえ、「プラグアンドプレイ」のキャプティブポータルデバイスをこの方法で実装できるとは思いません。
実際、セキュリティの観点から大きな問題があります。 あった Raspberry Piが単純に接続し、ルーター構成なしですべてのトラフィックを何らかの方法で傍受する可能性がある場合...マルウェアを使用する不正なクライアントが単純に接続してすべてのトラフィックを傍受する可能性もあります。