リダイレクト ページが読み込まれず、再接続しても問題が解決しない場合、次の最も簡単な手順はルーターに直接対処することです。
192.168.1.1 を試す .これが最も一般的なデフォルト アドレスであり、多くの場合変更されません。
ルーターのアドレスを指定すると、リダイレクト ページが表示されます。
あなたが説明するものは、キャプティブ ポータルと呼ばれます .通常、Wi-Fi ホットスポットでの認証に使用されますが、有線ネットワーク アクセスの制御にも使用できます。
キャプティブ ポータルを実装するには、いくつかの方法があります:
-
HTTP リダイレクト
この場合、認証されていないクライアントからの DNS クエリは通常どおり解決されます。ただし、ブラウザーが解決された IP アドレスに対して HTTP 要求を行うと、その要求は透過プロキシとして機能するファイアウォールによって傍受されます。クライアントの HTTP リクエストは、HTTP 302 Found でサーバー側のリダイレクトを発行するローカル ネットワーク内のサーバーに転送されます。 クライアントをキャプティブ ポータルにリダイレクトするステータス コード。
-
DNS リダイレクト
DNS ベースのリダイレクトでは、DHCP によって提供される DNS サーバーのみが認証されたクライアントによって使用されることが、ファイアウォールによって保証されます。ファイアウォールは、認証されていないクライアントからの DNS クエリをローカル DNS サーバーにリダイレクトすることもできます。この DNS サーバーは、認証されていないクライアントによって行われたすべての DNS ルックアップへの応答として、キャプティブ ポータルの IP アドレスを返します。
-
IP リダイレクト
IP層で動作するリダイレクトでは、ルーターがDestination Network Address Translationを実行します (DNAT) を使用して、キャプティブ ホストから送信されたパケットをキャプティブ ポータルに再ルーティングします。キャプティブ ポータル ソフトウェアがルーター自体で実行されている場合、パケットは代わりに内部インターフェイスに送信されます。キャプティブ ポータルからホストに向かうパケットは、ソース アドレスを取得します。 元の目的地から発信されたように見えるように書き直されました。
キャプティブ ポータルの問題をトラブルシューティングするときの最初のステップは、使用されているリダイレクトの種類と、リダイレクトが失敗した時点を特定することです。この作業に適したツールは、Wireshark などのパケット アナライザーです。ただし、学校の IT ポリシーでは、ローカル ネットワークでのパケット スニファーの使用が禁止されている場合があることに注意してください。このようなツールは、暗号化されていないネットワークで他のユーザーのプライバシーを侵害するために簡単に使用される可能性があるためです。
学校の技術サポートに相談することもできます。彼らはローカル Wi-Fi ネットワーク上のキャプティブ ポータル構成を認識しており、特に教職員が Linux を使用している場合は、問題の原因を特定するのに役立つ可能性があります。
私の場合、Chrome へのサインインが邪魔になりました。シークレット ウィンドウを開いてランダムな Web ページに移動すると、リダイレクトが機能しました。このアイデアは、Arch Linux スレッドの投稿から得ました。