Mat*_*rlé 9 linux wifi authentication arch-linux
我在上网本上运行 Arch Linux。我的学校有一个开放的接入点，如果我们没有连接，我们必须通过一个页面登录网络，当我们尝试打开任何网站时，我们会被重定向到该页面。
它适用于我的 Android 智能手机。它适用于 Windows。它也应该适用于 Linux，因为我的老师能够连接到它（他正在运行 Ubuntu）。
我使用 wifi-menu 连接到接入点以生成 netctl 配置文件。我已连接但我没有重定向到登录页面，当我输入地址（从我的手机中获取）时，它没有找到服务器......我尝试禁用 IPv6，但没有任何变化......
小智 15
如果重定向页面未加载，并且重新连接不能解决问题，那么最简单的下一步是直接寻址路由器。
试试192.168.1.1。这是最常见的默认地址，通常不会更改。
对路由器进行寻址应该会将您发送到重定向页面。
Geo*_*off 11
就我而言，登录 Chrome 是一种阻碍。当我打开隐身窗口并转到随机网页时，重定向起作用了。我从Arch Linux 线程上的一篇帖子中得到了这个想法。
在上述答案都没有让我在德国火车上进入“ICE上的Wifi”之后，我遇到了https://gist.github.com/martinvirtel/5d35ff7a82fd4c26d502e37682a6d101。键入route -n以查看网关的 IP 地址，例如
0.0.0.0 172.18.0.1 0.0.0.0 UG 600 0 0 wlp0s20f3
然后寻找br-具有相同前缀的桥（ ），例如
172.18.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-50e6082d8b75
删除桥：
sudo ifconfig br-50e6082d8b75 down
sudo brctl delbr br-50e6082d8b75
在 Ubuntu 上这需要该bridge-utils软件包。
您所描述的称为强制门户。它们通常用于 Wi-Fi 热点的身份验证，但也可用于控制有线网络访问。
有几种方法可以实现强制门户：
HTTP 重定向
在这种情况下，来自未经身份验证的客户端的 DNS 查询将正常解析。但是，当浏览器向解析后的 IP 地址发出 HTTP 请求时，该请求会被充当透明代理的防火墙拦截。客户端 HTTP 请求被转发到本地网络中的服务器，该服务器发出带有 HTTP 302 Found 状态代码的服务器端重定向，这会将客户端重定向到强制门户。
DNS 重定向
在基于 DNS 的重定向中，防火墙确保经过身份验证的客户端只能使用 DHCP 提供的 DNS 服务器。防火墙还可以将来自未经身份验证的客户端的任何 DNS 查询重定向到本地 DNS 服务器。该 DNS 服务器将反过来返回强制门户的 IP 地址，作为对未经身份验证的客户端进行的所有 DNS 查找的响应。
IP重定向
在 IP 层的重定向工作中，路由器执行目标网络地址转换(DNAT) 以将来自俘虏主机的数据包重新路由到俘虏门户。如果强制门户软件在路由器本身上运行，则会将数据包定向到内部接口。从强制门户到主机的数据包依次被重写其源地址以便它们看起来来自原始目的地。
在对强制门户问题进行故障排除时，第一步是确定正在使用的重定向类型以及重定向失败的时间点。适合这项工作的工具是数据包分析器，例如Wireshark。但请记住，您学校的 IT 政策可能会禁止在本地网络上使用数据包嗅探器，因为此类工具很容易被用来在未加密的网络上侵犯他人的隐私。
您也可以咨询您学校的技术支持。他们会知道本地 Wi-Fi 网络上的强制门户配置，特别是如果教职员工使用 Linux，他们可能会帮助查明问题的根源。
小智 6
酒店使用 172.17.xx 网络，我安装的 docker 也是如此——因为目前没有客户端要求我使用 docker 实例，所以我卸载了它，用于登录的登录重定向不再出现问题。
如果需要保持安装冲突的 docker，网络设备应该可以使用类似ip link delete docker0. 如果没有安装所需的工具，可以docker network prune释放桥接网络。如果容器主动使用该网络，它可能不起作用，但至少不需要完全卸载 Docker。