我来帮你梳理下这个RADIUS断开请求的IP异常问题，抓包显示源IP是12.0.0.100但接收端打印成100.0.0.12，这种情况大概率是网络NAT转换、配置错误或者接收端解析逻辑出了问题，咱们一步步排查：

1. 优先排查中间网络的NAT转换 #

抓包已经确认真实源IP是12.0.0.100，但接收端拿到的是100.0.0.12，最常见的原因是服务器到接收端之间的网络设备（路由器、防火墙）做了源NAT转换，把RADIUS流量的源IP替换成了100.0.0.12。

• 检查服务器12.0.0.100出口的网络设备，看有没有针对RADIUS Disconnect端口（3799）的NAT规则；
• 也可以在接收端12.0.0.1上用tcpdump port 3799抓包，直接查看数据包的源IP字段，确认是不是真的被修改了。

2. 检查接收端的RADIUS客户端配置 #

接收端（运行radclient的12.0.0.1）的RADIUS配置可能存在IP映射错误：

• 查看接收端的RADIUS信任列表，有没有错误地把100.0.0.12当成了服务器IP，或者遗漏了12.0.0.100；
• 检查接收端的hosts文件，看有没有把12.0.0.100的域名错误解析成100.0.0.12；
• 在接收端执行ping 12.0.0.100，确认返回的IP和响应是否正常。

3. 验证radclient命令的参数合理性 #

你提到的服务器发送请求的命令是：

cat packet.txt | radclient -c 10 -i 40 -x 12.0.0.1:3799 disconnect "Secret"

这里要确认：服务器12.0.0.100是向客户端12.0.0.1的3799端口发送Disconnect请求吗？如果是，那要确保接收端的3799端口确实在监听RADIUS Disconnect请求，并且配置了正确的共享密钥Secret。

4. 排查接收端程序的IP解析逻辑 #

如果抓包明确显示源IP是12.0.0.100，但接收端程序打印的是100.0.0.12，那可能是接收端程序自身的问题：

• 检查程序获取源IP的逻辑，是不是误读了其他字段（比如反向代理的X-Forwarded-For头，而不是直接读取数据包的IP头）；
• 换用一个简单的测试工具（比如nc -l 3799）监听端口，然后从服务器发送数据包，看nc显示的源IP是否正确，以此判断是程序问题还是网络问题。

可能的解决办法 #

• 如果是NAT问题：要么调整网络设备的NAT规则，让RADIUS Disconnect请求的源IP保持12.0.0.100；要么在接收端的RADIUS配置里添加100.0.0.12为信任服务器IP，允许接收来自该IP的请求。
• 如果是配置/解析错误：修正接收端的hosts文件或RADIUS信任列表，确保12.0.0.100被正确识别。
• 如果是程序逻辑问题：修复接收端程序的源IP获取代码，确保直接读取数据包的原始源IP。

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