半泽和莉娜前阵子帮一个园区排查终端无法访问共享打印机的故障，折腾了快两小时，最后发现根因出在 802.1X 配置里一个很不起眼的参数上。类似的坑我在好几个项目里都见过：命令背得很熟，display dot1x session 也能看到用户在线，但端口策略一换，或者说“放行”和“开锁”之间的边界没理清，整个准入体系就形同虚设。所以今天干脆把 802.1X 从原理到报文再到配置完整过一遍，不空谈协议，适合刚接手园区网准入的运维、准备 HCIE/H3CTE 类认证的工程师，以及想搞懂认证服务端到底从哪来、报文长什么样的人。
下面的内容我会按自己平时排障的习惯来写：先讲清楚 802.1X 是“靠什么思想”去控制端口的，再拿抓包结果把 EAPOL/EAP/RADIUS 的字节结构拆开，最后给华为、H3C、思科三个厂商最常见的配置骨架，并整理几条真正上线时容易翻车的排错链路。
1. 从“物理能通”到“逻辑放行”：802.1X 为什么要把端口拆成两个
1.1 二层接入网最尴尬的地方：插上就能通
普通交换机的以太网端口天生是“物理通就转发”的，只要网线一插，终端就能发 DHCP 请求、能访问网关、能扫内网。想做准入控制，最朴素的办法是配 MAC 地址静态绑定或者端口安全，但 MAC 绑定在终端量稍大的环境里维护成本极高，而且攻克门槛低——一个抓包工具就能把合法终端的 MAC 抄走。DHCP 层面做过滤也只能挡一下不会配置的普通用户，拦不住故意改静态 IP 的终端。
所以接入层需要一个比 MAC 过滤“更靠近身份”的机制：在数据帧正常桥接之前，先让端口走一遍身份认证。认证通过了，数据帧才被交换；认证没通过，除了认证协议自身的报文，其它用户流量一概不转发。这就是 802.1X 的核心思想——把以太网物理端口抽象成一个“门”，门锁内部还有一把独立的“钥匙孔”，钥匙孔的报文路径不做拦截，但主数据通路的桥接动作完全由认证结果控制。
1.2 三个角色和那对“受控/非受控端口”
802.1X 体系里有三个角色：请求方、认证方、认证服务器。
- 请求方（Supplicant）：一般就是终端上运行的 802.1X 客户端，Windows 自带的“有线自动配置”服务、wpa_supplicant、各厂商准入插件都算。
- 认证方（Authenticator）：通常是接入交换机或无线 AP，它负责在物理端口上执行“授权前阻断”的动作。
- 认证服务器（Authentication Server）：后台做真正身份校验的设备，绝大多数场景是 RADIUS Server。
认证方和认证服务器之间通常不是直连，交换机只是把用户提交的认证信息“转交”给 RADIUS。换句话说，交换机同时扮演了 RADIUS Client 的角色。
理解 802.1X 最容易卡住的地方，是它把一个物理端口抽象成了两个“逻辑端口”。其中一个叫受控端口，另一个叫非受控端口。这两个逻辑端口都在同一个物理口上，但作用完全相反。
非受控端口只允许 EAPOL（EAP over LAN）这类认证控制报文通过。这类报文的作用是让认证方和终端之间能“说上话”，比如用户主动发起认证、交换机主动询问身份、证书交互过程等。在认证完成之前，非受控端口一直是打开的。
受控端口则控制真正的用户数据帧。默认情况下受控端口处于 unauthorized 状态，此时任何业务数据都不允许桥接。只有认证服务器返回成功，受控端口才切换到 authorized 状态，用户数据才开始转发。
你可以把它类比成高档小区的地下车库：入口栏杆和门禁读卡器是两套系统，读卡器一直通电，但栏杆只有在刷卡成功后才抬起。802.1X 的受控端口就是那个栏杆，非受控端口就是那个始终在工作的读卡器。
1.3 认证方法不可控的烦恼：为什么还要套一层 EAP
另一个关键点在于：接入设备只负责“放不放行”，至于用户用什么方式证明