在一台托管面向互联网的 Web 应用程序的 Ubuntu 16.04 机器上，我/var/log/syslog被类似的消息淹没了：
Jan 9 17:41:50 ip-172-31-11-100 kernel: [483324.699896] [UFW BLOCK] IN=ens5 OUT= MAC=0a:16:21:97:4e:74:0a:af:bd:31:30:da:08:00 SRC=88.201.58.59 DST=172.31.11.100 LEN=52 TOS=0x10 PREC=0x20 TTL=40 ID=63099 DF PROTO=TCP SPT=6450 DPT=443 WINDOW=343 RES=0x00 ACK URGP=0
Jan 9 17:41:50 ip-172-31-11-100 kernel: [483324.719775] [UFW BLOCK] IN=ens5 OUT= MAC=0a:16:21:97:4e:74:0a:af:bd:31:30:da:08:00 SRC=88.201.58.59 DST=172.31.11.100 LEN=569 TOS=0x10 PREC=0x20 TTL=40 ID=63098 DF PROTO=TCP SPT=6450 DPT=443 WINDOW=343 RES=0x00 ACK PSH URGP=0
Jan 9 17:43:13 ip-172-31-11-100 kernel: [483408.133979] [UFW BLOCK] IN=ens5 OUT= MAC=0a:16:21:97:4e:74:0a:af:bd:31:30:da:08:00 SRC=103.255.6.65 DST=172.31.11.100 LEN=40 TOS=0x00 PREC=0x00 TTL=38 ID=0 DF PROTO=TCP SPT=3277 DPT=443 WINDOW=0 RES=0x00 RST URGP=0
似乎用户流量被阻止访问，443最长 TTL 为 200040秒。我无法解释这个问题。专家能指出发生了什么吗？我该如何扭转这种情况？
请注意，我和众多用户都可以访问此 Web 应用程序 - 也就是说，阻止并不普遍。但有合法用户对此表示抱怨。也许这是某种速率限制问题？
sudo ufw status verbose产量：
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
22 ALLOW IN Anywhere
80 ALLOW IN Anywhere
443 ALLOW IN Anywhere
22 (v6) ALLOW IN Anywhere (v6)
80 (v6) ALLOW IN Anywhere (v6)
443 (v6) ALLOW IN Anywhere (v6)
sudo iptables -S | grep ACCEPT产量：
-P OUTPUT ACCEPT
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-input -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A ufw-before-input -d 224.0.0.251/32 -p udp -m udp --dport 5353 -j ACCEPT
-A ufw-before-input -d 239.255.255.250/32 -p udp -m udp --dport 1900 -j ACCEPT
-A ufw-before-output -o lo -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-skip-to-policy-output -j ACCEPT
-A ufw-track-output -p tcp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-track-output -p udp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 22 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 22 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 80 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 80 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 443 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 443 -j ACCEPT
-A ufw-user-limit-accept -j ACCEPT
sudo iptables -S | grep ufw-user-limit得出以下结果（如果速率限制正在进行中)：
-N ufw-user-limit
-N ufw-user-limit-accept
-A ufw-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw-user-limit -j REJECT --reject-with icmp-port-unreachable
-A ufw-user-limit-accept -j ACCEPT
最后sudo iptables -S | grep "UFW BLOCK"得到：
-A ufw-after-logging-forward -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-after-logging-input -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
答案1
我以前见过这个问题并在网上读过一些有关这个问题的主题。
UFW 正在阻止 RST 数据包。
https://frankfu.click/linux/basic/ufw-blocking-fin-rst-and-ack-packets-when-rules-should-allow-it/
答案2
很可能这些是无效数据包的 BLOCK。使用类似下面的方法执行 tcpdump 来捕获数据包并观察是否发生阻塞，例如：
sudo tcpdump port 443 -w /tmp/ufw.log -i eno1 -G 200
中断该操作以停止写入输出文件。接下来查看其中一个 BLOCKS 上的源端口（例如 SPT=6450）并执行筛选以仅将该会话的数据包放入另一个文件中：
tcpdump -r /tmp/ufw.log -w /tmp/ufw.port6450 port 6450
然后用 wireshark 查看该输出文件。这些 ACK 数据包很可能显示为红色，作为虚假重传，而这些 RST 数据包是在 FIN-ACK 之后发送的，这使其无效。