Docker Compose 部署 FreeRADIUS：从 AAA 原理到 Windows 有线 802.1X 认证实战

一次完整的网络准入验证，需要回答四个问题：终端用什么身份认证，接入设备怎样转发认证，服务器根据什么做决定，以及接入设备是否把决定落实为正确的端口和业务权限。容器启动只是其中一个步骤。

本文以 RK3399 临时验证、FreeRADIUS Docker 配置导出、Windows 有线认证和 CPE 端口状态问题为线索，给出最小本地文件方案、证书配置、分层测试与现场排错。全文使用简体中文，面向了解基本 Linux 命令和网络地址的读者。

1. RADIUS 与 AAA：谁向谁请求认证

RADIUS（Remote Authentication Dial-In User Service，远程用户拨入认证服务）把接入身份和策略判断集中到服务器，适用于企业 Wi-Fi、有线准入、VPN、PPPoE 和网络设备管理等场景。FreeRADIUS 是可实施这些策略的开源服务器。统一服务器有利于管理多个接入点，但用户也可以暂存于服务器本地文件，不要求立即引入数据库。

AAA 分别是 Authentication（认证：你是谁）、Authorization（授权：你可做什么）和 Accounting（记账：何时接入、用了哪些资源）。Accounting 不必等同于收费。认证和授权通常通过同一轮 Access 请求/响应完成；记账是独立流程。RADIUS 标准 RFC 2865、记账标准 RFC 2866

RADIUS Client 通常是交换机、无线 AP、网关或 CPE 等 NAS（Network Access Server，网络接入服务器），不是输入密码的 Windows 电脑。 NAS 把用户信息和接入属性发给服务器，并执行返回的策略。NAS-IP-Address 属性也不一定等于服务器看到的 UDP 源 IP；clients.conf 主要按报文来源匹配 client。

图 0：服务器作出认证与授权决定，NAS 执行准入策略；记账由 NAS 另行报告。

报文	方向	用途
Access-Request	NAS → Server	提交身份、凭据或 EAP 内容
Access-Challenge	Server → NAS	要求继续挑战或下一轮 EAP
Access-Accept	Server → NAS	认证及策略允许，可能携带 VLAN、超时等属性
Access-Reject	Server → NAS	拒绝本次请求
Accounting-Request / Response	NAS → Server / 返回	Start、Stop、Interim-Update 等记账及确认
CoA-Request、Disconnect-Request 及 ACK/NAK	动态授权发起方 → NAS / 返回	可选地改变现有授权或断开会话

常见认证端口是 UDP 1812 ，记账端口是 UDP 1813 。CoA（Change of Authorization，授权变更）常用 UDP 3799 ，接收者通常是 NAS；不是让基础服务器再开放一个端口就自动获得控制所有设备的能力。双方需支持动态授权、客户端登记、身份匹配和授权规则。RFC 5176

Shared Secret（共享密钥）是 NAS 与服务器之间的秘密，用于报文校验及部分属性保护；用户密码是用户身份凭据，两者独立。传统 RADIUS/UDP 不是对整个报文进行现代 TLS 加密，网络属性及部分身份可能可见。PEAP 的 TLS 隧道保护终端与 EAP 服务器之间的内层交换，但不会给整个 NAS---服务器链路套上 TLS。跨不可信链路可考虑 RadSec（RADIUS over TLS），本基础方案不部署它。RFC 6614

2. 802.1X：EAPOL 与 RADIUS 的分工

IEEE 802.1X 是基于端口的网络接入控制机制。它和 RADIUS 是不同协议，RADIUS 也用于许多没有 802.1X 的场景。IEEE 802.1X-2020

角色	本文设备	职责
Supplicant，申请者	Windows 有线终端	发起/应答认证，提供用户或机器身份，验证服务器证书
Authenticator，认证者	支持该功能的交换机或 CPE	在接入链路交换 EAPOL，把 EAP 转发给认证服务器，维护端口/会话状态
Authentication Server，认证服务器	FreeRADIUS 容器	执行 EAP 方法、身份校验与授权策略

EAP（Extensible Authentication Protocol，可扩展认证协议）承载方法协商和认证内容。EAPOL（EAP over LAN）在终端与认证设备之间使用二层以太网帧，常见 EtherType 为 0x888e。认证设备把 EAP 内容放进 RADIUS 的 EAP-Message 属性发到服务器；EAPOL 本身不会被普通 IP 路由直接送到 FreeRADIUS。EAP RFC 3748、EAP over RADIUS RFC 3579

图 1：EAPOL 只画在终端与认证设备间；RADIUS 只画在认证设备与认证服务器间。

典型有线流程如下：

1. 网线 Link Up；认证设备允许必要的认证控制交换，普通数据流受端口策略限制。设备可能主动请求身份，不能要求所有终端一定先发 EAPOL-Start。
2. Windows 应答 EAP 身份，认证设备发 Access-Request。
3. FreeRADIUS 通过 Access-Challenge 往返多轮 EAP；PEAP 包含 TLS 建链、证书检查和内层密码认证。
4. 成功后，服务器最终返回 Access-Accept（含相应 EAP 成功信息）；认证设备向终端传递 EAP-Success，并按自身策略授权会话/端口。失败则拒绝或按配置进入受限网络。
5. 根据设备和策略，NAS 可发送记账、定时重新认证，并在断链或超时后清除会话。

EAP-Success 不保证 DHCP、VLAN、ACL（Access Control List，访问控制列表）、DNS 或目标业务全部成功。 端口配置状态、当前会话授权状态、终端网卡状态是三类证据，应分别检查。有线认证通常控制交换机逻辑端口；无线企业认证还涉及关联及链路密钥建立，不能直接复用有线端口诊断结论。

3. 选择认证方式

下面比较的是协议机制和部署条件，并非统一的安全评分。底层 RADIUS 方法与 EAP 方法不是同一层次。

方法	常见用途	凭据与证书依赖	安全及适用边界
PAP，Password Authentication Protocol	radtest 基础验证；部分隧道内密码认证	服务器可获取密码并比较；普通 PAP 无证书	RADIUS User-Password 是传统隐藏机制，不等于完整链路加密；限定受保护网络
CHAP，Challenge Handshake Authentication Protocol	传统挑战响应场景	通常需明文等价的已知密码；无 TLS 证书	不传直接明文密码，但旧式摘要与离线猜测风险仍在
MSCHAPv2，Microsoft CHAP version 2	PEAP 内层常用密码机制	明文密码、NT 哈希或相应后端能力	不能裸用其挑战响应就宣称安全；密码质量与外层保护关键
EAP-MD5	遗留/受限实验	密码，无服务器证书	缺少可靠双向认证和适合无线的密钥机制，不用于本文正式准入方案
PEAP，Protected EAP	Windows 用户名密码认证	服务端证书；本方案内层 EAP-MSCHAPv2	客户端必须校验 CA、名称和有效期；不需要客户端证书不代表无需信任配置
EAP-TLS，EAP Transport Layer Security	受管终端证书认证	服务端和客户端证书、对应私钥、PKI	双向证书认证；需发证、撤销、更新、身份映射与授权管理
EAP-TTLS，EAP Tunneled TLS	TLS 隧道内 PAP/其他认证	服务端证书；客户端按选用内层方法提供凭据	支持更多内层方式；终端平台和配置需核查，本文不启用

本地文件使用 Cleartext-Password 可支持本文 PAP 与 PEAP/MSCHAPv2 实验；只存某种不可逆密码哈希，不一定能支持 CHAP/MSCHAPv2。AD（Active Directory，活动目录）/LDAP（Lightweight Directory Access Protocol，轻量目录访问协议）接入也须确认验证接口和认证方法兼容，不能认为所有目录的 bind 都能直接代替 MSCHAPv2。FreeRADIUS WPA 指南

PEAP 主线沿用历史账号实验方向。管理较完善的终端可规划 EAP-TLS，降低用户密码依赖，但证书签发与授权规则仍须维护。TLS 安全依赖证书检查及实现配置，不能用"绝对安全"描述任何方法。EAP-TLS RFC 5216、EAP-TTLS RFC 5281

4. 最小架构与环境准备

组件	示例地址/路径	基础方案是否必需
Linux/RK3399 主机	192.0.2.10	必需；RK3399 是历史测试平台，不是本次实测硬件
Docker Engine + Compose 插件	Linux 容器运行时	必需
FreeRADIUS	容器 radius-lab	必需
用户、NAS、EAP 配置	宿主机 raddb/	必需
实验 CA 证书、服务器证书及私钥	raddb/certs/lab-*	PEAP 必需
CPE/交换机	RADIUS 请求源 192.0.2.2	真实 802.1X 链路必需
Windows 终端	认证后业务地址由现场决定	真实客户端验证必需
Linux EAP 测试机	192.0.2.30	可选；本地 helper 不使用这个条目
数据库、Web 管理、AD、HA	未部署	后续独立扩展，不是前提

图 2：配置由 bind mount 提供，服务器日志与记账落在可写日志目录；CA 私钥不挂载给服务容器。

Linux 上先执行：

uname -m
getconf LONG_BIT
docker version
docker compose version
docker info --format '{{.OSType}}/{{.Architecture}}'
sudo ss -lunp
ip route get 192.0.2.2

uname -m 看内核架构，LONG_BIT 看用户空间位数；RK3399 CPU 能运行 ARM64，不代表装上的系统一定是 64 位。Docker 的服务端信息需可读取。Compose 应支持本文长语法 bind mount 的 create_host_path，先用 config -q 检查；不填写旧式顶层 version。

确认主机到 NAS 的管理网络双向可达、路由不会经受控终端端口形成认证依赖循环。不要把 RADIUS 主机唯一的管理通路放在待认证端口后面。NTP（Network Time Protocol，网络时间协议）与时钟正确关系到证书有效期判断。确认 UDP 1812/1813 没被现有进程占用。

host 模式由主机 INPUT 防火墙限制只允许 NAS 和必要测试来源；记账只在使用时开放给相应 NAS。bridge 发布端口涉及 Docker 的转发规则，不能只看 UFW 状态便认为已经限制访问。按目标主机实际 iptables/nftables 后端配置，验证允许来源可通信、未允许来源不能通信。本文不直接清空或重写读者现有规则。Docker 防火墙说明

5. 镜像、目录与符号链接

5.1 先探测目录

以下 Linux 变量用于本章以及后续初始化和备份；新终端需重新设置：

IMAGE='freeradius/freeradius-dev:v3.2.x@sha256:cd8b1977c472f4e57b3b6a9c5424a03bb762e86cf4ab5758f99d18729869c451'
docker buildx imagetools inspect "$IMAGE"
docker pull "$IMAGE"
docker image inspect "$IMAGE" --format '{{.Os}}/{{.Architecture}}'
docker run --rm --entrypoint /bin/sh "$IMAGE" -c \
  'ls -ld /etc/raddb /etc/freeradius; readlink -f /etc/raddb; id freerad; freeradius -v'

imagetools 看注册表所有平台；image inspect 看本地拉下的平台。--entrypoint 绕过镜像默认入口，--rm 退出即清理探测容器，-c 在容器内运行命令。

本次实际目录是 /etc/raddb -> /etc/freeradius。历史 /opt/etc/raddb 路径在当前固定 amd64 镜像中不存在，因此本文挂载真实 /etc/freeradius。以后换镜像必须重做目录、权限、模块、入口脚本核查。

5.2 正确导出完整配置

docker cp 可以复制停止的容器；直接复制一个符号链接路径，可能复制链接本身，而宿主机没有它指向的目标。-L 跟随源路径链接，/. 表示复制目录内容，避免得到多一层目录。内部 mods-enabled、sites-enabled 的相对链接仍应检查，不要只确认顶层不是链接。Docker cp 文档

推荐把独立示例目录复制到 新的 /userdata/docker/radius-lab，再执行：

cd /userdata/docker/radius-lab
sh init.sh
test -f raddb/radiusd.conf
test -f raddb/clients.conf
test -f raddb/mods-config/files/authorize
test -f raddb/sites-enabled/default
test -f raddb/sites-enabled/inner-tunnel
ls -l raddb/mods-enabled/eap

脚本先确认真实目录，再 docker create 得到临时容器，用 docker cp -L "$CID:$REAL_DIR/." ./raddb/ 导出，核查关键文件，覆盖这次新导出的 客户端、用户和 EAP 模板。临时容器用 trap 清理；已有 raddb（包括悬空符号链接）则拒绝执行，不删除或覆盖读者原目录。若自行导出，先检查目标是否存在、父目录权限以及所选目录内容。

输出结构：

/userdata/docker/radius-lab/
├── compose.yaml
├── init.sh
├── make-lab-certs.sh
├── config/                 # 发布模板；运行实际读取 raddb
│   ├── clients.conf
│   ├── authorize
│   └── eap
├── raddb/                  # 从固定镜像导出，含 radiusd.conf
│   ├── clients.conf
│   ├── mods-config/files/authorize
│   ├── mods-available/eap
│   ├── mods-enabled/eap    # 通常指向 ../mods-available/eap
│   ├── sites-enabled/default
│   ├── sites-enabled/inner-tunnel
│   └── certs/lab-*         # 自己生成的证书和服务器私钥
├── pki/                    # CA 私钥，只在实验发证时使用，不挂载
├── logs/                   # 文件日志和 radacct 记账
└── tests/                  # PEAP 配置、记账请求、可选工具 Dockerfile

不要手工用六个小配置文件替代整棵默认目录。全目录 bind mount 会遮住镜像内部原文件，目录不完整会导致 include、dictionary 或模块失败。为便于公开分发，交付包包含模板和初始化脚本，不包含执行后产生的私钥及认证日志。

6. Compose 与网络模式

6.1 主方案：Linux host 网络

完整 compose.yaml 如下，与独立部署目录相同：

name: radius-lab
services:
  freeradius:
    image: freeradius/freeradius-dev:v3.2.x@sha256:cd8b1977c472f4e57b3b6a9c5424a03bb762e86cf4ab5758f99d18729869c451
    container_name: radius-lab
    restart: unless-stopped
    network_mode: host
    command: ["-f", "-l", "stdout"]
    volumes:
      - type: bind
        source: ./raddb
        target: /etc/freeradius
        read_only: true
        bind:
          create_host_path: false
      - type: bind
        source: ./logs
        target: /var/log/freeradius
        bind:
          create_host_path: false
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

入口脚本支持以参数启动 freeradius，-f 前台运行适合容器，-l stdout 将主日志交给 Docker 收集。restart: unless-stopped 处理进程异常退出，不代表认证健康。配置只读，日志可写；create_host_path: false 避免拼错 source 时悄悄生成空目录。未设置无用途的 environment 或 .env；也未用"进程活着"伪装端到端 healthcheck。json-file 限制 stdout 日志，不会自动轮转 logs/radacct 。Compose 服务字段

在 Linux host 模式中，服务共享宿主机网络，监听直接占用宿主机端口，无需 ports。这贴合历史实验，减少 Docker DNAT 带来的排查变量，但不绕过上游 NAT 或主机防火墙，也不能解决错误 NAS 源地址。它降低网络隔离并可能产生端口冲突。Docker host 网络

6.2 可选 bridge 网络

需要隔离或明确绑定发布地址时，可删除 network_mode: host 并加入：

    ports:
      - "192.0.2.10:1812:1812/udp"
      - "192.0.2.10:1813:1813/udp"

替换为主机真实可绑定 IP。两个模式不能同时使用。外部 NAS 请求经普通 Linux bridge DNAT 时常保留源 IP；本机回环、hairpin、代理、上游 SNAT 或 Docker Desktop 转发可能让源地址变化。用宿主机及容器网络命名空间抓包或 FreeRADIUS 调试确认，再填写 clients.conf。不要为方便把所有地址 0.0.0.0/0 登记成同一密钥 client。

容器内 127.0.0.1 表示自身，宿主机和外部测试机不一定匹配 localhost client。认证终端的 IP/MAC 属性与 NAS 请求源地址也不是同一件事。若 NAT 把多个 NAS 合并为同一源 IP，服务器很难仅按地址分配各自密钥，应调整管理链路或使用适当的代理/安全传输设计。

本次验证平台 是 Windows 上的 Docker Desktop Linux 引擎。容器共享 Linux 引擎 host 命名空间做本地测试，不能据此保证 Windows 主机 LAN 上暴露行为等同原生 Linux host；Docker Desktop 的 host 功能还受版本和设置限制。本教程现场目标仍是原生 Linux/RK3399。Docker Desktop host 限制

7. FreeRADIUS 核心配置

以下模板用于本次固定镜像。不同版本尤其 FreeRADIUS 4.x 文档可能出现不同的属性和配置语法，不能混抄。

7.1 clients.conf：登记报文来源

client localhost {
    ipaddr = 127.0.0.1
    secret = "LAB-ONLY-local-secret-change-me"
    require_message_authenticator = yes
}
client cpe_lab {
    ipaddr = 192.0.2.2
    secret = "LAB-ONLY-nas-secret-change-me"
    require_message_authenticator = yes
}
client eap_tester {
    ipaddr = 192.0.2.30
    secret = "LAB-ONLY-eap-secret-change-me"
    require_message_authenticator = yes
}

localhost 仅供容器/host 命名空间中的本地测试；CPE 的源地址和密钥与设备配置一致；EAP 测试机条目可在不用时删除。要求 Message-Authenticator 保护认证报文完整性；支持 EAP 的合法请求应包含该属性。旧版测试工具可能不发它，要更新工具或明确构造属性，不能为"跑通"全局关闭要求。未知 client 或无效完整性校验通常被丢弃，不保证返回 Access-Reject。3.2.10 clients.conf 的对应说明

7.2 用户文件

raddb/mods-config/files/authorize：

labuser Cleartext-Password := "LAB-ONLY-user-password-change-me"

:= 设置服务器用于校验的已知密码。它是控制属性，不是发给 NAS 的授权属性。公开口令仅为复制实验，正式用户密码不能写进文章。不要强行设置 Auth-Type := Accept，也不要给所有用户硬设 Auth-Type := EAP，否则会绕过正常判断或破坏其他方法。

7.3 最小 EAP 模块

默认导出配置中 mods-enabled/eap 通常是相对链接，编辑 mods-available/eap 即可；如果自己的导出工具把链接展开成普通文件，则启用文件也必须同步。本文 init.sh 在 Linux 导出并使用原有启用关系。

eap {
    default_eap_type = peap
    timer_expire = 60
    ignore_unknown_eap_types = no
    max_sessions = ${max_requests}
    tls-config tls-common {
        private_key_file = ${certdir}/lab-server.key
        certificate_file = ${certdir}/lab-server.crt
        ca_file = ${cadir}/lab-ca.crt
        auto_chain = no
        tls_min_version = "1.2"
    }
    peap {
        tls = tls-common
        default_eap_type = mschapv2
        virtual_server = "inner-tunnel"
    }
    mschapv2 {
    }
}

${certdir}、${cadir} 是 FreeRADIUS 配置变量，由主配置定义；不是 Compose 环境变量。外层首选 PEAP，TLS 最低 1.2，PEAP 内层 EAP-MSCHAPv2 转给 inner-tunnel。此精简模块不启用 MD5、TTLS 或 EAP-TLS。默认方法只决定首选提议；"真正只允许哪些方法"还要看模块启用范围和策略。3.x EAP 配置说明

7.4 主配置和虚拟服务器

radiusd.conf 包含路径、进程权限、日志、安全设置和加载入口，主线保留固定镜像导出的内容。实测当前 freerad UID/GID 为 101:101，换镜像重新确认。检查 certdir/cadir 确实指向 raddb/certs。

sites-enabled/default 处理外层 RADIUS。authorize 的 files、mschap、eap 与 pap 等按默认顺序工作；authenticate 调用对应认证模块。sites-enabled/inner-tunnel 处理 PEAP 的内层身份，须保留 files、mschap、eap 等调用。服务器本地有用户，不代表内层配置必然加载了该用户。 本文保留整套镜像默认虚拟服务器，避免重写复杂策略。default、inner-tunnel

默认记账使用 detail 等模块写文件，后续可接 SQL，但本文不启用数据库。示例不返回动态 VLAN，先完成身份认证再增加授权；需要 VLAN 时，可设置 Tunnel-Type、Tunnel-Medium-Type、Tunnel-Private-Group-Id，并核查 NAS 属性支持、VLAN 已建立及 trunk/ACL 策略。PEAP 内层 reply 不一定自动进入最终外层 Accept，必须检查最后发送给 NAS 的属性，不能只看 inner-tunnel 调试值。

8. 证书：先建立信任再连接

PKI（Public Key Infrastructure，公钥基础设施）包含 CA（Certificate Authority，证书颁发机构）、证书、私钥、签发与撤销流程。PEAP 中 Windows 验证 EAP 服务端；EAP-TLS 还要求服务端验证终端证书。CA 证书可按组织流程分发，CA 私钥不能分发给终端或挂载进认证容器。

图 3：两种方法都要验证服务器；EAP-TLS 增加客户端证书，证书合法性仍需结合授权策略。

8.1 生成独立实验 CA 与服务器证书

镜像带有便于安装的默认测试证书，不作为正式环境身份。脚本用新的 lab-* 文件名，避免误用镜像默认的 server.pem：

docker run --rm --entrypoint /bin/sh \
  --mount "type=bind,src=$PWD,dst=/work" \
  "$IMAGE" /work/make-lab-certs.sh

脚本在新的 pki/ 下生成 RSA 3072 位实验 CA，CA 有效期 365 天；服务器证书 90 天，SAN（Subject Alternative Name，主题备用名称）为 DNS:radius.lab.example，EKU（Extended Key Usage，扩展密钥用途）为 serverAuth。这些数值是本文实验选择，不是协议强制参数。OpenSSL req -new 创建请求，x509 -req 签发，-extfile 指定用途和 SAN；脚本包含完整命令。实验私钥未加口令，靠文件权限保护，方便无人值守读取；正式发证遵循组织 PKI 政策。

拷入服务配置的仅有 lab-ca.crt、lab-server.crt、lab-server.key。实验是直接 CA 签发，没有中间 CA；因此使用 auto_chain = no 的证书链只有叶证书。正式链须在 certificate_file 中放叶证书和所需中间证书，按实际 3.x TLS 配置检查构链；不要把"客户端信任根已安装"等同于服务端已发完整链。

Linux 上执行权限设置：

sudo chown -R root:101 raddb
sudo find raddb -type d -exec chmod 750 {} +
sudo find raddb -type f -exec chmod 640 {} +
sudo chown 101:101 logs
sudo chmod 750 logs
sudo chmod 700 pki

目录需要遍历权限，私钥必须可由实际服务 UID/GID 读取。不要用 chmod -R 777 修复错误。Windows bind mount 的权限语义不同，本次容器读取成功不证明目标 Linux 权限已经设置好。

证书检查可在辅助容器执行：

docker run --rm --entrypoint /bin/sh \
  --mount "type=bind,src=$PWD,dst=/work,readonly" -w /work "$IMAGE" -c \
  'openssl verify -CAfile pki/ca.crt -purpose sslserver pki/server.crt; openssl x509 -in pki/server.crt -noout -subject -dates -ext subjectAltName'

校验 CA、用途、有效期和 SAN；再检查证书公钥与私钥公钥匹配（各自 openssl ... -pubout 后取摘要，不输出私钥内容）。Windows 需信任本次 CA、限定服务器名称、拒绝未知服务器证书提示。只安装 CA 而不限定名称，仍可能信任同一 CA 签发的其他服务器。Microsoft 证书要求

8.2 可选 EAP-TLS：独立增强示例

PEAP 主线不需要这一步。本次未把 EAP-TLS 列为已运行通过。要实验 EAP-TLS，先在独立目录签发仅给实验终端使用的证书：

openssl req -new -newkey rsa:3072 -nodes -sha256 \
  -keyout pki/lab-client.key -out pki/lab-client.csr -subj '/CN=lab-client'
cat > pki/client.ext <<'EOF'
basicConstraints=critical,CA:FALSE
keyUsage=critical,digitalSignature
extendedKeyUsage=clientAuth
EOF
openssl x509 -req -in pki/lab-client.csr \
  -CA pki/ca.crt -CAkey pki/ca.key -CAserial pki/ca.srl \
  -days 90 -sha256 -extfile pki/client.ext -out pki/lab-client.crt
openssl verify -CAfile pki/ca.crt -purpose sslclient pki/lab-client.crt
openssl pkcs12 -export -inkey pki/lab-client.key -in pki/lab-client.crt \
  -certfile pki/ca.crt -out pki/lab-client.p12

在有 OpenSSL 的发证环境运行；pkcs12 -export 交互输入强导出口令，不把它写进命令行。PKCS#12 文件含客户端私钥，只通过受控渠道交给相应终端，不公开发布。用户认证装到"当前用户/个人"，机器认证装到"本地计算机/个人"，确保证书有私钥和客户端用途。

在 EAP 模块增加以下同级块，若仅采用证书主线将 default_eap_type 改为 tls：

    tls {
        tls = tls-common
    }

未加授权策略时，专用 CA 签发的合格证书可能足以在默认策略中通过 TLS，不等于某证书被允许进入特定业务网 。正式使用应建立专用客户端 CA/中间 CA，明确可接受的签发者、用途、身份字段（如 SAN）、资产/用户映射与授权，配置 CRL（Certificate Revocation List，证书撤销列表）或合适的在线撤销检查并测试不可用时策略。不把通用公网根 CA 作为所有客户端的授权依据。增加证书策略应依据当前版本 TLS 虚拟服务器/策略接口，再 -XC 和正反测试，不在未验证的示例里假装已经具备完整生产 PKI。

9. 启动与分层测试

9.1 检查、启动、挂载与监听

docker compose config -q
docker compose run --rm --no-deps freeradius -XC
docker compose up -d
docker compose ps
docker compose logs --tail=100 freeradius
docker inspect radius-lab --format '{{json .Mounts}}'
docker compose exec -T freeradius sh -c \
  'readlink -f /etc/raddb; test -s /etc/freeradius/clients.conf; test -r /etc/freeradius/certs/lab-server.key'
sudo ss -lunp

config -q 只检查 Compose 模型；run --rm --no-deps ... -XC 创建一次性配置检查进程，-X 调试、-C 检查后退出。这不检验占用端口，因为该模式跳过实际监听。up -d 创建/启动后台容器，exec -T 不分配终端，适合脚本。查看 Mounts 的 source、destination、RW，核对服务确实读取所编辑的宿主机目录。

Linux host 模式用 ss 查 1812/1813；bridge 映射不保证出现普通监听进程，可用 docker port radius-lab、容器命名空间和抓包检查。UDP 没有 TCP 式建立连接，ping 通或 nc -uz 成功不是认证可达证据，Windows Test-NetConnection -Port 也不是 UDP RADIUS 测试。

9.2 PAP 基础认证

docker compose exec -T freeradius radtest \
  labuser LAB-ONLY-user-password-change-me 127.0.0.1 0 LAB-ONLY-local-secret-change-me
docker compose exec -T freeradius radtest \
  labuser wrong-password 127.0.0.1 0 LAB-ONLY-local-secret-change-me

参数依次为用户名、用户密码、服务器地址、NAS-Port 值 0、本地测试共享密钥。第一条预期 Access-Accept，第二条预期 Access-Reject（工具通常因不是 Accept 返回非零）。固定镜像中的 radtest 自动加入 Message-Authenticator。外部旧工具若缺该属性会超时，与用户名正确与否是不同问题。官方 radtest 源码

radtest 成功只说明基础请求、用户与密码处理可用，不证明 PEAP、证书、Windows EAPOL 或 CPE 端口授权成功。 命令行和调试输出会显示实验密码，正式账号不要沿用这种公开演示方式。

9.3 PEAP 测试

eapol_test 将 EAP peer 与 RADIUS client 组合，能测试 EAP 方法，无需真实网卡和交换机；它不能验证物理认证设备转发和授权行为。固定服务镜像不带该工具，提供独立辅助 Dockerfile 安装，服务容器不安装额外依赖。工具官方说明

tests/peap.conf：

network={
    key_mgmt=WPA-EAP
    eap=PEAP
    identity="labuser"
    anonymous_identity="anonymous"
    password="LAB-ONLY-user-password-change-me"
    ca_cert="./raddb/certs/lab-ca.crt"
    domain_match="radius.lab.example"
    phase2="auth=MSCHAPV2"
}

anonymous_identity 是外层身份，真正密码身份在 PEAP 隧道内；外层抓包看到 anonymous 不代表没有使用 labuser。domain_match 限定服务器身份；证书名称不是 NAS IP，也不要求终端通过 DNS 直连 FreeRADIUS。

docker build -f tests/Dockerfile.eapoltest -t radius-lab-eapoltest:local .
docker run --rm --network container:radius-lab \
  --mount "type=bind,src=$PWD,dst=/work,readonly" -w /work \
  radius-lab-eapoltest:local \
  -c tests/peap.conf -a 127.0.0.1 -p 1812 \
  -s LAB-ONLY-local-secret-change-me -t 20

此处共享服务容器网络命名空间，所以服务器看到 localhost，使用本地 secret。-c 指配置、-a 服务器、-p UDP 端口、-s NAS secret、-t 超时秒数。Linux 外部测试机直接执行工具时，服务器地址改实际 192.0.2.10，secret 改测试机对应值，clients.conf 登记实际测试源 IP，证书文件也复制到其本地受控目录。

至少做正确密码、错误密码、不信任 CA、服务端名称不匹配四项测试。预期正确配置完成 EAP 成功及密钥协商；其余应失败，失败发生阶段不同。不能仅搜一行 SUCCESS，还应检查最终状态、返回码和服务器相关请求；快重连/会话恢复可能跳过完整检查，负向测试宜用新工具进程并按策略清理会话。

9.4 调试与抓包

docker compose stop freeradius
docker compose run --rm --service-ports freeradius -X

先停止普通服务避免端口冲突。调试在前台，认证一次后 Ctrl+C，再 docker compose up -d 恢复。不在生产长期运行 -X：它可能显示身份、密码和策略。普通日志未出现 Access-Request，不证明服务器没收包；详细包处理要用短时调试或抓包。

sudo tcpdump -ni any -s 0 -w radius-lab.pcap \
  'udp port 1812 or udp port 1813'

-n 不做名称解析、-i any 看主机接口、-s 0 捕获完整包、-w 保存文件。服务器抓包通常看不到终端---NAS 的 EAPOL，需要交换机镜像接入口或在终端捕获 ether proto 0x888e。TLS 内层不能靠普通抓包直接读明文；用服务器授权的短时调试关联。控制抓包访问权限和保存时间。

9.5 可选记账验证

docker compose exec -T freeradius radclient -x \
  127.0.0.1:1813 acct LAB-ONLY-local-secret-change-me \
  < tests/accounting-start.txt
find logs/radacct -type f

测试文件包含实验用户名、NAS-Port、Acct-Status-Type=Start、Acct-Session-Id。预期收到 Accounting-Response，并写入默认 detail 路径；还要核查真实 NAS 的 Start/Interim/Stop 与同一会话关联。单个 Start 成功不证明整套计费或记账完整。

10. 交换机和 CPE 对接

项目	本文实验值/检查点
RADIUS Server	实际替换 192.0.2.10，在 NAS 管理侧可达
认证端口	UDP 1812
记账端口	UDP 1813，仅在启用记账时配置
Shared Secret	与 cpe_lab 条目一致，替换公开占位值
请求源接口/IP	服务器实际看到的源地址匹配 192.0.2.2 条目
全局 802.1X	启用，绑定正确的 AAA/RADIUS 方法组
LAN 口模式	按厂商定义选择自动认证控制；核查 force-authorized/force-unauthorized 含义
多终端模式	single-host、multi-host、multi-auth 等按实际需要；不能假定单个成功用户只放行自己
超时与重试	依据链路 RTT 和厂商默认值验证，避免过短重试造成请求风暴
重认证	配置周期、触发方式、已有会话刷新，现场验证
失败/服务器不可达	明确拒绝、受限 VLAN、访客或临时放行策略，实验先避免隐性 fallback
记账与 CoA	两项独立启用；CoA 是可选扩展，核查 UDP 3799 方向和会话标识

保存前确认管理通路不依赖受控端口。依次配置服务器、AAA、全局开关和目标端口，然后触发一次新的认证，记录设备运行状态、服务器请求与 Windows 事件。接受策略后继续核对设备 VLAN/ACL、终端 DHCP 和真实业务。

11. Windows 有线客户端配置

不同 Windows 版本、语言、驱动及组策略使 UI 名称和编辑能力有差异。Windows 11 可从"设置 → 网络和 Internet → 以太网 → 身份验证设置"编辑；传统路径是 ncpa.cpl → 对应以太网适配器属性 → 身份验证。组策略锁定时先找管理员核查下发的配置，不用删除组织策略来抢回本地设置。Microsoft EAP 配置入口

11.1 启动 Wired AutoConfig

管理员 PowerShell：

Get-Service dot3svc
Set-Service -Name dot3svc -StartupType Automatic
Start-Service dot3svc
netsh lan show interfaces
netsh lan show profiles

dot3svc 是 Wired AutoConfig（有线自动配置）服务。确认操作正确网卡，USB 网卡和扩展坞可能是另外一个接口。服务运行只证明终端具备处理配置的条件，不证明 NAS 已授权。

11.2 PEAP 用户认证

1. 通过可信方式获得本次 lab-ca.crt，核对指纹与管理员发布值后，安装到所需"受信任的根证书颁发机构"存储。受管部署由组织策略统一发放。
2. 在对应有线适配器启用 IEEE 802.1X，选择 Microsoft: 受保护的 EAP（PEAP）。
3. PEAP 设置中启用通过证书验证服务器身份，选择本次实验 CA，服务器名称限定 radius.lab.example。配置为无法验证时失败，避免由用户点击接受未知服务器。
4. 选择"安全密码（EAP-MSCHAP v2）"；本地 labuser 实验取消自动使用 Windows 登录名和密码。域环境单点登录需单独规划，不与实验账号混用。
5. "其他设置"明确"用户身份验证"。若使用计算机认证，发送的是机器身份，需要机器账户/证书及相应后端；不会自动变成本地 labuser。
6. 使用系统提供的输入或保存凭据入口填写本次 labuser 与新测试密码；域留空（本地用户实验）。入口名称和是否弹出通知依版本、策略和已缓存凭据而异，不能保证每次插线都有密码框。
7. 保存配置，监控事件和服务器调试，在允许中断该测试终端时重新连接/重认证。没有按预期发起时查看失败阻塞时间、设备重认证设置与会话状态。

核对 CA 文件后，可用管理员 PowerShell 安装到本地计算机根存储（路径替换实际文件）：

certutil -hashfile C:\RadiusLab\lab-ca.crt SHA256
# 与受信渠道给出的文件摘要一致后，再导入：
certutil -addstore -f Root C:\RadiusLab\lab-ca.crt

这只导入 CA 证书，不含 CA 私钥；共享/受管电脑按管理员发证和分发政策执行。文件 SHA256 用于核对下载文件，不能与证书指纹的不同算法输出混用。

PEAP 服务端验证、内层方法、凭据来源都需一致。管理员应下发限定 CA/服务器名的策略，不能把关闭证书验证作为正式修复方法。Windows EAP 方法与凭据设置

11.3 EAP-TLS 证书认证

选择"Microsoft: 智能卡或其他证书"等 EAP-TLS 对应方法，而非继续用 PEAP/MSCHAPv2。按用户或机器认证模式把带私钥的客户端证书装入相应个人存储，核查有效期、clientAuth、证书链和私钥访问。依然开启服务端证书校验及名称限制。自动证书选择可能导致无用户名密码框，这通常符合证书认证方式，而非服务异常。组织发证可加入适合 Windows 的 SAN/UPN（User Principal Name，用户主体名称）或机器身份字段，并与服务器授权规则配套。

11.4 事件与配置导出

管理员 PowerShell：

wevtutil sl Microsoft-Windows-Wired-AutoConfig/Operational /e:true
wevtutil qe Microsoft-Windows-Wired-AutoConfig/Operational /c:20 /rd:true /f:text
netsh lan show interfaces
netsh lan show profiles
New-Item -ItemType Directory -Path C:\RadiusLabProfiles -Force
netsh lan export profile interface="以太网" folder="C:\RadiusLabProfiles"

接口名替换实际值。/e:true 开启操作日志，/c:20 取最近 20 条，/rd:true 从最新倒序，/f:text 文本输出。配置导出文件可能包含身份或敏感策略，不公开原件。必要时同时查看 EapHost、CAPI2 证书链日志和设备日志，按时间对齐。

11.5 不弹凭据窗口的检查顺序

顺序	检查对象	判断依据和下一步
1	服务、网卡、有效配置	dot3svc、正确接口的 profile；组策略锁定或驱动问题先处理
2	认证模式	用户/计算机/用户或计算机；查看实际身份来源，机器认证不期待用户密码框
3	EAP 方法	EAP-TLS 不要求密码；PEAP 内层必须是计划的 MSCHAPv2
4	凭据来源与缓存	自动使用登录凭据、保存的账号、SSO；按系统允许的方式更新实验凭据
5	服务端证书	CA、名称、有效期、链、时钟；证书失败可能发生在询问密码之前
6	认证链路	抓终端 EAPOL、看设备转发、看服务器 RADIUS；无弹窗不是服务器未工作证据
7	失败阻塞/重认证及系统限制	事件时间、Windows 版本、策略和 Credential Guard，避免无证据关闭安全功能

Credential Guard（凭据保护）可能影响 MS-CHAP 的登录凭据 SSO（Single Sign-On，单点登录）。Microsoft 当前说明区分 SSO 被阻止与显式提供凭据，不能写成"Windows 11 一定不能 PEAP"。核查事件和凭据路径，可考虑显式实验凭据或 EAP-TLS 迁移。Credential Guard 官方限制

12. 完整验收矩阵

认证成功至少要有四层证据：服务器 final Accept、Windows EAP 成功、NAS 会话授权正确，以及终端所需业务连通。证书负向场景还要确认客户端拒绝并且端口没有误放行。

场景	预期验证重点	证据与实现差异
正确用户与 PEAP 配置	完整 EAP 成功、NAS 授权、业务访问	最终 Accept/EAP、设备状态、DHCP/VLAN/ACL；每一层独立检查
错误密码	内层认证失败，未授权或受限策略	final Reject、Windows 失败、设备运行状态；访客策略可能另有访问
未授权 RADIUS Client	不被服务器接受处理	调试 unknown client 或丢弃；不保证回应 Reject
Shared Secret 不一致	完整性校验/响应验证异常	超时或无效认证器；并非每种方法都显示同一错误
不信任服务器 CA	客户端拒绝 TLS 建链	Windows/EAP 证书事件；服务器可能先有 Challenge 后超时
服务端名称不匹配	即使链可信也拒绝	客户端名称检查日志及失败结果
RADIUS 服务不可达	NAS 超时与既定失败策略	重试/备服务器/受限或拒绝；既有会话可能继续
端口断开重连	按设备策略触发新认证	会话 ID、EAPOL 和 NAS 日志；多主机模式需额外测
端口禁用 802.1X	配置、运行开关和实际业务一致	是否再发 EAP、端口是否 transparent/authorized，不能仅看认证工具
容器重启	新认证恢复，既有会话符合设备策略	不保证断开所有老会话；观测重新认证周期
服务端更新用户/策略	新请求使用新配置	对同一测试账号正反验证；旧会话可能不受即时影响
服务器证书更新	新链/名称被客户端验证	新进程/完整握手；旧 TLS 会话恢复不能代表新证书验证
记账 Start/Interim/Stop	会话信息完整	请求及 Response 与持久记录关联；NAS 能力可能有差别

本地工具通过后，再做真实 Windows → 目标 LAN 口 → NAS → 服务端测试。记录设备型号、固件、Windows build、网卡/驱动、镜像摘要、网络模式、认证方法和测试时间，使问题可重复定位。本文不宣称设备行为一致。

13. 故障排查与 CPE 状态案例

现场默认顺序：终端 → 接入设备 → 网络传输 → FreeRADIUS → 用户配置 → EAP/TLS → 授权与会话。哪个层次已有确凿证据，就从相邻断点继续，避免不断改密码、证书和网络三个变量。

图 4：先寻找认证消息停止的位置；最终 Accept 后转向设备授权和业务链路。

13.1 现场速查表

现象	可能原因	检查方式	修复方向	再验证
容器启动退出	配置语法、权限、缺文件、端口冲突	compose logs、-XC、Linux ss	按首个实质错误修复；检查模式不查监听冲突	容器稳定并有实际认证
include/path 错误	镜像路径变更或错误挂载	探测 readlink、inspect Mounts	真实目录与 Compose target 同步	容器内 test 与 -XC
只导出 raddb 链接	复制了符号链接	宿主机 ls -ld、readlink	新目录从真实路径导出，必要时 -L	主文件及 enabled 链接均有效
挂载后配置缺失	空 source 遮住镜像、额外一层目录	source 内容、目标目录清单	完整导出；禁止自动创建错误 source	-XC 加载所需模块
1812/1813 不通	UDP 协议写错、防火墙、路由、NAS 源接口	两端抓包、NAS 配置、实际请求	修正 UDP 发布、路由或允许来源	基础请求 + 真实 NAS 请求
unknown client	源地址与条目不同、NAT	服务器抓包和调试源 IP	登记准确来源或调整 NAT 管理链路	不再 unknown；不要扩大到全网
Secret/Message-Authenticator 错	两端密钥不一致、旧工具缺属性、篡改	配置逐字核对、抓包属性、调试	换强密钥或更新 NAS/工具	新请求和响应校验通过
用户不存在/密码错	编辑错文件、内层身份不同	files 加载、inner-tunnel User-Name	正确用户文件、凭据/身份规范	正确 Accept、错误 Reject
EAP 方法失败	外层/内层不匹配、模块未启用	Windows 方法、-X 方法协商	两端 PEAP/MSCHAPv2 对齐	完整 PEAP，不能仅 PAP
TLS 不信任	CA/名称/链/期限/用途/时间错误	Windows/CAPI2、openssl verify	正确发证和分发信任，保留验证	合法成功，非法证书失败
Windows 不弹框	机器/证书认证、缓存、SSO、链路/证书失败	第 12.5 节顺序	修正凭据路径或失败层次	用实际身份及事件判定
Windows 认证失败	EAP/TLS/密码或 NAS 处理异常	三端同时日志	修复最早失败环节	Windows 成功且 NAS 已授权
普通服务日志没请求	普通日志不记录包或转发未到	短时 -X + tcpdump	有包查服务策略；无包查 NAS/网络	同次请求时间和地址可关联
Accept 仍不能联网	VLAN、ACL、DHCP、NAS 未执行/响应未收到	NAS session、抓响应、IP/DNS/业务	修正最终授权和业务链路	目标业务实际访问
CPE 端口状态不刷新	配置提交/运行状态/会话状态/实现差异	config + runtime + session + 抓包	厂商支持的 apply/重认证/会话清除	新连接及其他在线用户影响
重启/更新后异常	镜像目录/UID/模块/证书/策略改变	摘要与备份 diff、-XC、全链路	回滚对应镜像与配置；补迁移	PAP + EAP + 真实网卡回归

13.2 分辨"无请求"和"有请求但不答"

NAS 出口没有 RADIUS：查全局/端口 802.1X、AAA 绑定、EAPOL 与设备运行配置。NAS 有发、服务器主机无收：查路由、防火墙和目的 IP/UDP 端口。主机有收、服务无处理：查容器网络、监听、client 地址及 Message-Authenticator。服务器有答、NAS 未收或拒绝：查反向路径、NAT 与 secret/响应校验。这四种情况不能统一叫"服务器故障"。

外层 PEAP 最终 Accept 与内层成功有区别。调试显示 inner-tunnel 用户通过，但 TLS 流程没完成时不能提前宣布认证成功。TLS 大报文反复重传还需核查 MTU（Maximum Transmission Unit，最大传输单元）、IP 分片与链路丢包，而非盲目更改认证方法。

13.3 CPE 关闭认证未即时生效：保持证据边界

历史用户描述：关闭某 LAN 口 802.1X 后，仍能进行用户及准入认证；拔插网线未改变现象，重启后行为变化。用户希望临时透明接入更新病毒库，但整机重启会影响其他在线用户。未提供固件、状态表和抓包，因此无法确认缓存、状态机、提交路径或固件问题。

尤其要分清 "802.1X 工具不再认证"与"普通业务已透明放行"。透明端口可能不再发 EAP，但业务应按设备的关闭认证策略放行；历史"重启后认证不通过"不能被扩写成业务恢复或终端被正确拒绝的完整结论。还可能存在独立 NAC（Network Access Control，网络准入控制）代理/姿态检查，不能把它们全部归入 802.1X 开关。

可执行的取证步骤：

1. 用同一固件、同一端口、单个测试终端记录基线：端口配置、全局开关、AAA 绑定、运行控制模式、会话状态、VLAN、业务访问与三端时间。
2. 关闭端口认证，记录保存/apply 的返回结果，并重新读取持久配置和运行配置。确认作用对象是同一个 LAN 口，且没有全局/继承/多主机策略覆盖。
3. 在终端/端口镜像观察是否仍有 EAPOL，在 NAS/服务器观察是否产生新的 RADIUS 会话，结合 Acct-Session-Id、请求时间和端口属性，不只看旧的"成功"图标。
4. 按厂商支持方式尝试仅目标端口重认证、清除目标会话或端口 disable/enable。先评估该端口影响，不虚构设备 CLI；这些操作也不一定适用于"关闭认证"情形。
5. 记录当前配置与运行状态是否一致，再检查终端能否访问批准的病毒库更新资源。透明访问本身需经过组织安全策略授权，不自动绕过独立姿态检查。
6. 若只能整机重启改变行为，在维护窗口复现并保留前后证据，交厂商核查配置下发、运行状态机、会话清理及已知固件问题。重启是临时恢复手段，不是根因证明。

FreeRADIUS 的用户变更只作用于新请求/重新认证；它不能自行刷新所有 NAS 会话。CoA/Disconnect 可在设备支持且策略适当时帮助动态授权，但不能替代修复 NAS 本地配置不生效的问题。

14. 安全和长期运维

14.1 实验走向生产的检查点

替换全部公开占位口令；为每个 NAS 分配独立随机 secret，使用 openssl rand -base64 24 等安全随机来源，核查厂商长度与字符支持。只允许明确来源连接，放在管理网络，避免公网暴露。启用当前版本的 Message-Authenticator 保护，并核查 NAS 同时验证响应；shared secret 强度不能取代协议补丁或传输安全。

运行时配置只读，私钥只允许所需 UID/GID 读取，CA 私钥离线/受控保存。镜像内进程降权不等于应该给容器 --privileged；主线不需要这个参数。定期审查认证日志访问者、保存期限和异常拒绝率，对导出的日志脱敏。实验服务器拥有明文测试密码，正式身份后端按方法兼容性和组织策略规划。官方安全公告与更新要求

14.2 备份

在部署目录设置 IMAGE 变量后执行，下例用容器 tar 保留 Linux 链接与权限；业务日志备份前需暂停写入或使用一致性快照：

mkdir -p backup
chmod 700 backup
STAMP=$(date +%Y%m%d-%H%M%S)
docker compose stop freeradius
docker run --rm --entrypoint /bin/sh \
  --mount "type=bind,src=$PWD,dst=/work" -w /work "$IMAGE" -c \
  "umask 077; tar -czf backup/radius-$STAMP.tar.gz compose.yaml raddb pki logs"
docker compose up -d

备份含秘密，存储加密、限制权限并测试恢复。另记录当前镜像摘要与源模板；不把含私钥的备份打包给文章读者。正式 CA 私钥应独立于服务备份体系，例中包含 pki 是仅供私有实验恢复。

14.3 更新和回滚

docker compose restart freeradius 重启现有容器并重新读取挂载配置，不拉镜像。固定摘要时 docker compose pull 仍然取相同镜像；更新需主动修改摘要。不要自动追随 dev 分支标签进行生产升级。

更新步骤：保存旧 Compose、配置、证书和镜像摘要；在独立 staging 目录拉取新构建，核查架构、目录、模块、UID/GID 与安全公告；比较新默认配置和本地策略，运行 -XC 及本地正反测试；做 Windows/NAS 回归；维护窗口切换 up -d --force-recreate；观察新认证、重认证、记账及证书。

回滚必须同时匹配旧镜像与旧配置，不能仅改 image 后保留已迁移的新语法。先将备份恢复到新的目录检查，示例：

mkdir restore-stage
tar -xzf backup/radius-REPLACE_WITH_TIMESTAMP.tar.gz -C restore-stage
cd restore-stage
docker compose config -q
docker compose run --rm --no-deps freeradius -XC

这里还没启动服务，避免与原目录同名容器/端口冲突。确认后停止当前实例，在维护窗口从恢复目录启动。记录下现有会话不会因服务重启自动消失的事实，测试 NAS 重新认证后的行为。

14.4 证书更新和日志维护

到期前预留充足时间，在 staging 签发、检查私钥匹配、用途、SAN、证书链；CA 更新先分发信任再切换服务器。若证书来源为 ACME，也要确认用途、名称、链、格式、权限及 EAP 客户端信任，HTTPS/MQTT 的证书脚本和 HUP 行为不能直接移植。

把完整的新证书集合安全切换到配置目录后，运行 -XC 并安排服务重启，再用新的完整 EAP 握手验证。只替换磁盘文件不保证进程读取新内容；本文不宣称 FreeRADIUS 已接入自动续期。客户端撤销策略与 CA 信任迁移须独立验证。

Docker stdout 已做大小轮转。logs/radacct 等文件使用目标主机的 logrotate/保留策略并验证写入行为，不能套用未经检查的其他服务 reload 命令。监控容器重启次数、磁盘、证书到期、请求延迟/超时/拒绝异常及 NAS 备服务器切换；周期性合成认证应使用专用测试身份，不能只监控进程。

正式扩展可按规模加入 SQL、AD/LDAP、集中日志、冗余 RADIUS、备份链路及证书自动发放。高可用还要核查 NAS 的 failover、不同服务器证书信任、状态化 EAP 多轮路由及会话恢复策略；复制两个容器不等于已经实现高可用。

15. FAQ、总结与参考资料

Q：Windows 是 RADIUS client 吗？ 在真实 802.1X 场景中，它通常是 supplicant，NAS 才是 RADIUS client；测试工具可兼任角色。

Q：PAP 成功，PEAP 为什么失败？ PAP 不验证 TLS、内层 EAP、客户端证书信任或物理接入设备。按层检查，先完成 PEAP 工具正反测试，再联调真实端口。

Q：改用户文件或重启容器能立刻踢掉用户吗？ 已授权会话主要由 NAS 管理，需重新认证、会话超时或受支持的动态授权机制。

Q：不弹密码框，是否要重装服务器？ 先看服务、认证方法和身份模式、凭据来源、证书事件及认证链路。无窗口本身不证明服务器故障。

Q：host 网络一定最好吗？ 它便于这个 Linux 实验观察来源，但需要主机防火墙和端口管理；bridge 更易隔离，需核查 NAT、来源和 Docker 规则。

Q：关闭 802.1X 后"认证不通过"就是成功关闭吗？ 需要确认不再执行该端口认证，以及普通业务按预期透明/受限策略运行。单个状态文本不能代替设备运行证据。