Linux 主机无法完成校园网认证排查记录：从 DHCP、ARP 到 Portal 认证流程分析
1.1 背景
在校园网环境中，Linux 主机接入网络后，通常需要经过校园网认证系统（Portal）认证才能访问互联网，但出现主机无法进入校园网认证登录界面
1.2 正常主机进行校园网认证的完整流程
正常主机认证流程：接入->DHCP->ARP网关->访问网页->重定向认证->提交凭据->放行上网
第一步：物理链路建立
主机连接校园网交换机后：主机–网线–交换机端口
网卡状态变为： ip link show 网络名称
正常：state UP
说明网卡启动、网线连接正常、二层链路建立
第二步：DHCP获取网络参数
Linux 主机发送 DHCP 请求
DHCP 获取网络参数这一步的最终结果就是：Linux 主机获得并配置自己的网络参数。更准确地说，DHCP 服务器不是“修改主机网络”，而是向主机提供网络配置信息，由 Linux 网络栈接收后自动应用
第三步：ARP获取默认网关MAC
IP通信之前，需要知道下一跳网关的 MAC 地址
ipneigh10.23.127.254 lladdr 8c:96:a5:3f:90:02 REACHABLE
说明：主机已经和校园网网关建立二层通信
目的：让 Linux 主机知道 “要把发往其他网段的数据帧交给哪块网卡（MAC 地址）”
最终结果：建立默认网关 IP → 默认网关 MAC 的邻居映射，并缓存到本机
第四步：用户访问互联网资源
用户打开：http://www.baidu.com
数据流：主机–10.23.127.254–校园核心网络–互联网
但是此时校园网认证系统检查：MAC:D8:43:AE:8E:69:08、IP:10.23.68.216
认证状态:未认证，因此不会直接放行
第五步：Portal重定向认证
校园网网关检测到：当前用户未认证
返回：HTTP 302 Redirect
跳转：http://10.254.241.66
用户看到校园网登录页面
第六步：用户提交认证信息
浏览器向认证服务器提交：账号、密码、IP地址、MAC地址
认证服务器验证用户信息
第七步：认证成功，放行网络权限
1.3 问题排查
第一步的物理接入没有问题
第二步DHCP获取本机网络参数
我先查看了一下DHCP服务地址
sudodhclient-venp4s0我发现校园网 DHCP 服务器实际上就是 10.23.127.254，也就是默认网关设备本身（至少 DHCP 服务运行在该地址上），也就是说校园网网关同时承担 DHCP Server 和认证控制功能，只有通过 DHCP 完成 IP/MAC 租约建立后，主机才能进入正常的认证流程。
proto static无法执行完整的DHCP租约过程
iproutedefault via10.23.127.254 dev enp4s0 proto static metric2010010.23.64.0/18 dev enp4s0 proto kernel scopelinksrc10.23.71.63 metric100169.254.0.0/16 dev enp4s0 scopelinkmetric1000将proto static 更改为dhcp，使其执行完整DHCP租约过程，让校园网侧更新本机MAC-IP-Port绑定状态
1.4 问题解决
通过NetworkManager 改 DHCP
先查看连接名称：
nmcli connection show例如：
NAME DEVICE Wired connection1enp4s0然后修改：
假设连接名是：
Wired connection1执行：
sudonmcli connection modify"Wired connection 1"ipv4.method auto重新连接：
sudonmcli connection down"Wired connection 1"sudonmcli connection up"Wired connection 1"故障表面表现为默认路由的 proto static 与正常主机的 proto dhcp 不同，但 proto 字段本身只是 Linux 路由表中的路由来源标记，并不会被发送给校园网设备。
真正产生影响的是从静态网络配置切换到 DHCP 后，主机重新完成了 DHCP Discover、Offer、Request 和 ACK 流程。该过程不仅使 Linux 获得正式的 IP、网关和租约配置，还可能使校园网的 DHCP Snooping、IP/MAC 绑定或准入控制系统建立合法终端状态。完成这一状态后，主机才被允许访问 10.254.241.66 Portal 认证服务器，并进一步完成账号认证。
