Freeradius配置疑问：仅允许EAP-TTLS隧道内使用EAP-MD5是否正确？

配置规范性及后续风险评估 #

你当前的配置逻辑是FreeRADIUS中实现仅允许隧道内使用特定EAP方法的标准方案，不存在核心功能层面的隐患：

• 独立启用inner-eap模块并仅开启MD5，同时禁用主eap模块的MD5，从配置层面彻底阻断了外部直接发起EAP-MD5请求的可能
• 替换inner-tunnel中的eap模块为inner-eap，确保只有通过TTLS隧道的内部认证请求才能使用MD5

需要留意的细节：

• 确认inner-eap配置文件中仅保留MD5方法，避免误启用其他EAP类型
• 后续修改主配置时，注意不要重新开启主eap模块的MD5选项，定期测试外部EAP-MD5请求的拦截效果

"Outer User-Name is not anonymized"警告处理 #

这个警告需要重视，常见原因及解决方式：

1. 客户端匿名身份未生效：你认为使用了匿名身份，但实际客户端发送的外层User-Name字段并非匿名值（比如为空或真实用户名）。可以通过调试模式（radiusd -X）查看外层请求数据包，确认User-Name的实际内容
2. 未配置外层用户名匿名化：即使客户端发送了匿名身份，若未在站点配置中开启匿名化处理，也会触发警告。可在外层认证的站点配置（如sites-enabled/default）中添加以下规则，强制匿名化外层User-Name：

post-auth {
    update outer.request {
        User-Name := "anonymous"
    }
}

该警告涉及用户隐私，外层用户名明文传输且未匿名化可能被中间人捕获，建议尽快排查修复。

内容的提问来源于stack exchange，提问作者rad