简介:这份文档面向需要在 Ubuntu 环境下搭建 802.1X 认证实验的网络运维与安全学习者,聚焦 Freeradius 与 EAP-TLS 双向认证的完整落地流程。内容从环境准备讲起,涵盖 Freeradius 与 openssl 安装、users 与 client.conf 配置、TLS 模块证书生成(ca.pem、server.pem、server.key、client.p12)、eap 文件参数调整、路由器 WPA 与 Radius 对接,以及服务启动排错和终端证书导入测试,形成一条可复现的实验链路。资源包为单个 docx 文档,约 472KB,便于离线阅读与按步骤对照操作。目前已有 2922 人学习,适合希望理解证书签发、共享密钥匹配、端口占用与权限问题处理等关键细节的读者,可作为搭建无线认证测试环境的参考手册。
1. 为什么EAP-TLS双向认证总在证书环节翻车
很多团队第一次搭EAP-TLS测试环境,卡住的地方往往不是FreeRADIUS本身,而是证书链。服务端证书、客户端证书、CA根证书三者的签发关系一旦搞混,客户端就会在握手阶段直接断开,日志里只留下一句含糊的TLS alert。EAP-TLS的核心是双向认证:服务端验证客户端证书,客户端也验证服务端证书,任何一侧的证书链不完整或用途字段不对,认证就失败。这套环境适合无线网络准入测试、802.1X认证联调、IoT设备证书认证验证等场景。在Ubuntu上搭建的好处是软件包齐全、日志清晰、调试工具链完整。下面从零开始,把每一步的命令、配置和参数含义都拆开讲,让你能直接复现一套可用的EAP-TLS测试环境。
2. 环境准备与FreeRADIUS安装:从裸机到可启动服务
2.1 系统版本选择与网络前提
Ubuntu版本建议用22.04 LTS或24.04 LTS,这两个版本的软件源里FreeRADIUS版本较新,对EAP-TLS的支持更完整。安装前确认机器有两块网络接口或至少一个可用的回环地址用于测试,因为后续要用radtest和eapol_test做本地验证。如果是在虚拟机里做,网络模式选桥接或NAT都行,但要注意客户端测试机和服务端要能互相访问。先更新软件源并安装必要工具:
sudo apt update sudo apt install -y freeradius freeradius-utils openssl eapol_test这里装了四个包:freeradius是服务端主程序,freeradius-utils提供radtest等调试工具,openssl用来生成证书,eapol_test是wpa_supplicant自带的EAP测试客户端,专门用来模拟802.1X认证。装完后检查服务状态:
sudo systemctl status freeradius如果显示active (running),说明服务已启动。默认配置下FreeRADIUS监听1812(认证)和1813(计费)端口,配置文件在/etc/freeradius/3.0/目录下。先别急着改配置,下一步先解决证书问题,因为EAP-TLS没有证书根本跑不起来。
2.2 目录结构与配置文件定位
FreeRADIUS 3.0的配置目录结构比较清晰,关键文件有这几个:radiusd.conf是主配置,clients.conf定义客户端NAS,users是用户认证文件,mods-enabled/目录下是各模块配置,其中eap文件控制EAP认证方式,sites-enabled/default定义虚拟服务器。EAP-TLS的配置主要改三个地方:eap模块里指定证书路径,clients.conf里放行测试客户端,users里放测试账号。先备份原始配置:
sudo cp -r /etc/freeradius/3.0 /etc/freeradius/3.0.bak备份是个好习惯,改崩了能快速回滚。接下来生成证书,这是整个环境的地基。
3. 证书体系搭建:CA、服务端、客户端三套证书的生成与校验
3.1 用openssl生成CA根证书
EAP-TLS要求有一套完整的PKI。先建一个工作目录,把CA、服务端、客户端的证书分开存放:
mkdir -p ~/eap-tls-lab/{ca,server,client} cd ~/eap-tls-lab/ca生成CA私钥和自签名根证书:
openssl genrsa -out ca.key 4096 openssl req -new -x509 -days 3650 -key ca.key -out ca.crt \ -subj "/C=CN/ST=Test/L=Test/O=TestLab/CN=TestLab-CA"第一条命令生成4096位RSA私钥,第二条用私钥签发自签名根证书,有效期3650天。-subj参数里CN字段是证书的通用名,这里写TestLab-CA,后面签发服务端和客户端证书时要用CA的证书和私钥来签。CA根证书是信任链的起点,服务端和客户端都要信任它。
3.2 签发服务端证书并配置扩展字段
服务端证书需要包含serverAuth用途,并且CN要和服务端的标识匹配。先生成私钥和证书签名请求(CSR):
cd ~/eap-tls-lab/server openssl genrsa -out server.key 2048 openssl req -new -key server.key -out server.csr \ -subj "/C=CN/ST=Test/L=Test/O=TestLab/CN=radius-server"然后创建扩展配置文件,指定证书用途:
cat > server_ext.cnf <<EOF basicConstraints = CA:FALSE keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = serverAuth subjectAltName = DNS:radius-server, IP:127.0.0.1 EOF用CA签发服务端证书:
openssl x509 -req -in server.csr -CA ../ca/ca.crt -CAkey ../ca/ca.key \ -CAcreateserial -out server.crt -days 365 -extfile server_ext.cnf这里-CAcreateserial会生成一个序列号文件,-extfile指定扩展字段。服务端证书的extendedKeyUsage必须是serverAuth,否则FreeRADIUS加载证书时会报错。subjectAltName里加上IP和DNS,方便不同测试场景使用。
3.3 签发客户端证书并验证证书链
客户端证书的流程类似,但扩展字段要改成clientAuth:
cd ~/eap-tls-lab/client openssl genrsa -out client.key 2048 openssl req -new -key client.key -out client.csr \ -subj "/C=CN/ST=Test/L=Test/O=TestLab/CN=test-client" cat > client_ext.cnf <<EOF basicConstraints = CA:FALSE keyUsage = digitalSignature extendedKeyUsage = clientAuth EOF openssl x509 -req -in client.csr -CA ../ca/ca.crt -CAkey ../ca/ca.key \ -CAcreateserial -out client.crt -days 365 -extfile client_ext.cnf签发完成后,用openssl验证证书链是否正确:
openssl verify -CAfile ../ca/ca.crt server.crt openssl verify -CAfile ../ca/ca.crt client.crt两条命令都应返回OK。如果报错,检查CA证书路径和扩展字段。证书生成后,把服务端证书和私钥复制到FreeRADIUS的证书目录:
sudo cp server.crt server.key /etc/freeradius/3.0/certs/ sudo cp ../ca/ca.crt /etc/freeradius/3.0/certs/ sudo chown freerad:freerad /etc/freeradius/3.0/certs/server.* sudo chmod 640 /etc/freeradius/3.0/certs/server.key权限设置很关键,私钥不能让其他用户读取,否则FreeRADIUS启动时会拒绝加载。
4. FreeRADIUS配置EAP-TLS:模块、虚拟服务器与客户端放行
4.1 修改eap模块指向证书
编辑/etc/freeradius/3.0/mods-enabled/eap,找到tls-config段,修改以下参数:
sudo nano /etc/freeradius/3.0/mods-enabled/eap在tls-config tls-common段内设置:
private_key_file = /etc/freeradius/3.0/certs/server.key certificate_file = /etc/freeradius/3.0/certs/server.crt ca_file = /etc/freeradius/3.0/certs/ca.crt dh_file = /etc/freeradius/3.0/certs/dhdh_file是Diffie-Hellman参数文件,如果不存在需要生成:
openssl dhparam -out /etc/freeradius/3.0/certs/dh 2048生成2048位DH参数可能需要一两分钟。然后在eap模块的default_eap_type处确认是tls,并确保tls配置段被启用。FreeRADIUS 3.0默认已经启用了EAP-TLS,但证书路径要改成自己的。
4.2 配置clients.conf放行测试客户端
EAP-TLS认证时,NAS(网络接入服务器)会向RADIUS服务端发起请求。测试阶段可以用eapol_test模拟NAS,需要在clients.conf里添加客户端条目:
sudo nano /etc/freeradius/3.0/clients.conf在文件末尾添加:
client test-client { ipaddr = 127.0.0.1 secret = testing123 require_message_authenticator = no nas_type = other }ipaddr是客户端IP,secret是共享密钥,eapol_test配置里要填一样的值。require_message_authenticator设为no是为了兼容测试工具,生产环境建议开启。
4.3 配置users文件与虚拟服务器
在users文件里添加测试账号:
sudo nano /etc/freeradius/3.0/users添加一行:
testuser Cleartext-Password := "testpass" Reply-Message := "EAP-TLS Auth OK"EAP-TLS认证时,客户端证书的CN会作为用户名,但users文件里的条目仍然需要存在,否则授权阶段会失败。然后检查sites-enabled/default里的authorize、authenticate、post-auth段是否包含eap模块。默认配置已经包含,但确认一下:
sudo grep -n "eap" /etc/freeradius/3.0/sites-enabled/default应该能看到eap出现在authorize和authenticate段。配置完成后重启服务:
sudo systemctl restart freeradius sudo systemctl status freeradius如果启动失败,用freeradius -X以调试模式前台运行,能看到详细的错误信息。
5. 避坑与排查:EAP-TLS认证失败的五个典型场景
5.1 证书用途字段错误导致握手失败
现象:eapol_test连接后立即断开,FreeRADIUS日志显示TLS alert certificate unknown或unsupported certificate purpose。原因:服务端证书的extendedKeyUsage不是serverAuth,或者客户端证书不是clientAuth。解决:用openssl x509 -in server.crt -text -noout查看扩展字段,确认用途正确。重新签发时在扩展文件里明确写extendedKeyUsage。
5.2 私钥权限过宽导致服务拒绝加载
现象:FreeRADIUS启动时报Failed to load private key,但文件明明存在。原因:私钥文件权限是644或属主不是freerad。解决:chown freerad:freerad server.key,chmod 640 server.key。FreeRADIUS对私钥权限检查很严格,这是安全设计。
5.3 CA证书路径配置错误导致客户端不信任服务端
现象:客户端日志显示unable to get local issuer certificate。原因:eap模块里的ca_file指向了错误的路径,或者客户端没有加载CA证书。解决:确认ca_file指向/etc/freeradius/3.0/certs/ca.crt,客户端eapol_test配置里ca_cert参数也要指向同一个CA证书。
5.4 共享密钥不匹配导致认证请求被丢弃
现象:eapol_test发送请求后没有任何响应,FreeRADIUS日志里看不到认证记录。原因:clients.conf里的secret和eapol_test配置里的secret不一致。解决:两边都改成testing123,重启服务后再试。共享密钥是RADIUS协议的基础,不匹配时服务端直接丢弃包,不会有明显报错。
5.5 时间不同步导致证书有效期校验失败
现象:证书明明在有效期内,但认证时报certificate has expired。原因:服务端和客户端系统时间偏差过大,或者证书的notBefore时间晚于当前时间。解决:用date命令检查两边时间,用ntpdate或chrony同步。虚拟机挂起后恢复时间容易漂移,这是常见坑。
6. 用eapol_test验证双向认证并抓包分析握手过程
6.1 编写eapol_test配置文件
eapol_test需要一个配置文件,指定服务端地址、共享密钥、客户端证书等:
cat > ~/eap-tls-lab/eapol_test.conf <<EOF network={ ssid="test-ssid" key_mgmt=WPA-EAP eap=TLS identity="testuser" ca_cert="/home/user/eap-tls-lab/ca/ca.crt" client_cert="/home/user/eap-tls-lab/client/client.crt" private_key="/home/user/eap-tls-lab/client/client.key" private_key_passwd="" } EOF注意ca_cert、client_cert、private_key要用绝对路径。identity填users文件里的用户名。然后运行:
eapol_test -c ~/eap-tls-lab/eapol_test.conf -a 127.0.0.1 -s testing123 -p 1812-a指定RADIUS服务端地址,-s是共享密钥,-p是认证端口。如果认证成功,最后会输出SUCCESS。失败时看输出的TLS握手信息,能定位到具体哪一步出错。
6.2 用tcpdump抓包分析EAP-TLS握手
想深入理解握手过程,可以在另一个终端抓包:
sudo tcpdump -i lo -w ~/eap-tls-lab/eap-tls.pcap port 1812然后运行eapol_test,完成后用wireshark打开pcap文件。过滤eap协议,能看到EAP-Request/Identity、EAP-Response/Identity、TLS Client Hello、Server Hello、Certificate、Client Key Exchange等报文。重点看Certificate报文里服务端和客户端互相交换证书的过程,以及最后EAP-Success报文。抓包是排查认证问题最直接的手段,比看日志更直观。
6.3 验证双向认证是否真正生效
双向认证的关键是双方都验证对方证书。可以做两个反向测试:第一,把客户端证书换成用另一个CA签发的,认证应该失败,日志显示unknown CA;第二,把服务端证书换成客户端不信任的CA签发的,客户端应该拒绝连接。这两个测试都通过,说明双向认证配置正确。另外,在FreeRADIUS的post-auth段可以加日志记录证书CN:
post-auth { if (TLS-Client-Cert-Common-Name) { update reply { Reply-Message := "Client CN: %{TLS-Client-Cert-Common-Name}" } } }这样认证成功后能看到客户端证书的CN,确认服务端确实验证了客户端证书。
我一般会在证书生成脚本里加一个自检步骤,每次签发完自动跑openssl verify,避免手工操作漏掉扩展字段。这套环境搭好后,后续换证书、加用户、调EAP参数都有章可循,不用每次从头踩坑。希望帮到你。
本文还有配套的精品资源,点击获取