我在尝试使用 RHEL 6 作为服务器来让 tftp 工作时遇到了障碍。来自客户端的错误只是“传输超时”。在服务器上，我可以看到来自客户端的 udp 69 流量，但我没有看到任何数据包返回到客户端。在日志中我可以看到 xinetd 正在处理请求。在服务器上，我运行的是 tftp 版本：
tftp-server-0.49-8.el6.x86_64
这是我从客户端运行的命令。
tftp -v 192.168.100.10 -c get file
Tcpdump 服务器端：
13:54:02.136438 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 49)
192.168.100.11.37126 > 192.168.100.10.tftp: [udp sum ok] 21 RRQ "file" netascii
这个过程不断重复，直到传输超时。这是我的日志文件：
Jul 26 13:54:22 server in.tftpd[7068]: RRQ from 192.168.100.11 filename file
这个过程也会不断重复，直到传输超时。我的配置：
service tftp
{
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -v -v -v -s /var/lib/tftpboot
per_source = 11
cps = 100 2
flags = IPv4
}
Iptables 规则位于顶部：
[root@server tftpboot]# iptables -L --line-numbers | grep tftp
1 ACCEPT udp -- anywhere anywhere state NEW udp dpt:tftp
内核模块加载：
[root@server tftpboot]# lsmod | grep tftp
nf_conntrack_tftp 4814 0
nf_conntrack 79537 4 nf_conntrack_tftp,nf_conntrack_ipv4,nf_conntrack_ipv6,xt_state
SELinux 是宽容的：
[root@server tftpboot]# getenforce
Permissive
我已在 hosts.allow 中允许所有内容：
xinetd : ALL
并且我知道服务正在监听：
[root@server tftpboot]# lsof -i :69
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
in.tftpd 7023 root 0u IPv4 11763412 0t0 UDP *:tftp
xinetd 32761 root 5u IPv4 11763412 0t0 UDP *:tftp
[root@server tftpboot]# netstat -anp | grep ":69"
udp 0 0 0.0.0.0:69 0.0.0.0:* 7023/in.tftpd
世界在 tftpboot 目录中有 RX：
[root@server lib]# ll | grep tftp*
drwxr-xr-x. 2 root root 4096 Jul 26 12:17 tftpboot
全世界都已经读过里面的文件了。其他的事情我都试过了。
1）使用 tcp 代替 udp = 失败
2）移动 tftp 根目录 = 失败
3）如你所见，我已经为 tftp 打开了详细日志记录
4）更改配置中的用户=失败
我现在很困惑。有人遇到过这个问题吗？
更新：这是我的完整 iptables 配置：
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [1:136]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m udp --dport 69 -m state --state NEW,ESTABLISHED - j ACCEPT
-A INPUT -j DROP
COMMIT
另外，我已经禁用了 iptables 但仍然收到相同的传输超时消息。
更新＃2- 我还将以下内容添加到 iptables 中，但 iptables 不满意。
-A INPUT --sport 1024: --dport 1024: -m state --state ESTABLISHED -j ACCEPT
-A OUTPUT --sport 1024: --dport 1024: -m state --state ESTABLISHED,RELATED -j ACCEPT
错误：
iptables: Applying firewall rules: iptables-restore v1.4.7: unknown option `--sport'
更新 #3
这也许没什么用，但我很好奇我是否真的看到了相关数据包进出防火墙。下面是我插入的两条规则的快照，以允许 69 进出客户端以及数据传输所需的端口。
传输开始前：
5 245 ACCEPT udp -- * * 192.168.10.11 0.0.0.0/0 udp dpt:69 state NEW,ESTABLISHED
0 0 ACCEPT udp -- * * 192.168.10.11 0.0.0.0/0 udp spts:1024:65535 dpts:1024:65535 state ESTABLISHED
--
0 0 ACCEPT udp -- * * 0.0.0.0/0 192.168.10.11 udp spt:69 state ESTABLISHED
30 960 ACCEPT udp -- * * 0.0.0.0/0 192.168.10.11 udp spts:1024:65535 dpts:1024:65535 state RELATED,ESTABLISHED
传输尝试后：
10 490 ACCEPT udp -- * * 192.168.10.11 0.0.0.0/0 udp dpt:69 state NEW,ESTABLISHED
0 0 ACCEPT udp -- * * 192.168.10.11 0.0.0.0/0 udp spts:1024:65535 dpts:1024:65535 state ESTABLISHED
--
0 0 ACCEPT udp -- * * 0.0.0.0/0 192.168.10.11 udp spt:69 state ESTABLISHED
58 1856 ACCEPT udp -- * * 0.0.0.0/0 192.168.10.11 udp spts:1024:65535 dpts:1024:65535 state RELATED,ESTABLISHED
所以这告诉我它不是防火墙，如果我没有看到使用 tcpdump 的返回数据包，那么它就是介于两者之间的某个东西，也许是应用程序本身。
答案1
由于您在 iptables 配置中使用state模块仅允许 tftp 端口上的新连接，并且您只发布了防火墙配置的摘录：
1 ACCEPT udp -- anywhere anywherestate NEWudp dpt:tftp
该规则是否在 INPUT 链中？是否也存在通用-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT规则？（如果是，则该规则可能应该是 INPUT 链中的第一个规则。）
因为尽管 UDP 协议本身是无状态的，但 conntrack 模块似乎仍然为 UDP 维护一些状态信息，并且您可能会遇到第一个 UDP 数据包被接受并且每个后续数据包被视为“已建立”或“相关”的一部分的情况会议而不是“新的”并且被拒绝。