我有一台服务器，它正在汇总来自其他各个服务器的日志。它大部分时间都运行良好，但是有时（在重新启动后，但不是所有重新启动后）它会认为各种 UDP“连接”处于某种奇怪的状态，并拒绝传入的数据包。
问题是，这没有意义，因为处理 UDP 时没有“连接”！
以下是我的防火墙日志中显示的内容的示例：
Shorewall:loc2fw:REJECT:IN=eth0 OUT= MAC=/*snip*/ SRC=10.x.x.4 DST=10.y.y.14 LEN=159 TOS=0x00 PREC=0x00 TTL=254 ID=37407 PROTO=UDP SPT=514 DPT=514 LEN=139
运行命令sudo conntrack -D -p udp清除 conntrack 中的所有 UDP“连接”后，以下日志显示了来自同一主机的传入消息：
Shorewall:loc_dnat:REDIRECT:IN=eth0 OUT= MAC=/*snip*/ SRC=10.x.x.4 DST=10.y.y.14 LEN=201 TOS=0x00 PREC=0x00 TTL=254 ID=50542 PROTO=UDP SPT=514 DPT=514 LEN=181
在我运行该命令之前，下面是该主机的 conntrack 中显示的内容-D：
udp 17 29 src=10.x.x.4 dst=10.y.y.14 sport=514 dport=514 [UNREPLIED] src=10.y.y.14 dst=10.x.x.4 sport=514 dport=514 mark=0 use=1
以下是我的 Shorewall 配置中针对该端口的相关部分：
#ACTION SOURCE DEST PROTO DPT
SECTION NEW
REDIRECT:info loc 5000 tcp,udp 514
ACCEPT:info loc $FW tcp,udp 5000
为了完整起见，这里是 iptables 中的结果链（这是在conntrack -D -p udp运行命令并且防火墙已经正确接受数据包一段时间之后）：
Chain loc2fw (1 references)
pkts bytes target prot opt in out source destination
16328 1648K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
6428 386K ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8 /* Ping */
1 64 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 /* SSH */
18 1080 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 /* HTTP */
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5000 ctorigdstport 514
12M 6677M ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:5000 ctorigdstport 514
0 0 ~log0 tcp -- * * 0.0.0.0/0 0.0.0.0/0 [goto] tcp dpt:5000
0 0 ~log0 udp -- * * 0.0.0.0/0 0.0.0.0/0 [goto] udp dpt:5000
52 3088 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:9200
126M 32G Reject all -- * * 0.0.0.0/0 0.0.0.0/0
126M 32G LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix "Shorewall:loc2fw:REJECT:"
126M 32G reject all -- * * 0.0.0.0/0 0.0.0.0/0 [goto]
如您所见，我正在使用 REDIRECT 规则来接受从端口 514 传入的连接，并将它们发送到端口 5000，我的日志聚合器会在该端口进行监听（在防火墙中完成此操作比通过各种手段允许非特权用户打开特权端口更容易）。
我不明白为什么 UDP“连接”似乎会进入这种奇怪的状态，即它们被默认策略拒绝；我之所以这么说，是因为它们在 conntrack 中显示得很清楚，从那里删除它们似乎会“重置”所有内容，并让消息再次流入我的日志聚合器。目前，我看到的唯一替代方案是设置 cron 在conntrack重启后不久运行我的命令，但我更愿意理解为什么发生这种情况并解决原因而不是仅仅实施这种解决方法。