我正在监控我的流量，发现有几个TCP（确认、PSH） 路由器输入链上的连接尝试被防火墙丢弃。
日志如下所示：
Dropping input: src-mac 9c:80:df:a0:8a:dd, proto TCP (ACK,PSH), 172.217.16.78:443 (google ip) ->192.168.1.2:40382 (my router IP), len 115
显然，这被丢弃了，因为我的输入链上的最后一条规则是丢弃数据包。
我对 TCP 协议了解不够多，所以如果这有点幼稚，请原谅，但是为什么请求被定向到我的路由器？
我有各种使用谷歌服务的设备，也可能有第三方软件，但我很困惑，为什么数据包实际上是被发送的到路由器而不是纳特到我的网络中的一个设备（这将是前向链，对吗？）。
我尚未注意到我的设备在使用 Google 产品时体验下降。软件更新、推送通知等似乎都运行正常。
答案1
这个现象有点复杂。我在相应的日志中做了一些研究，想在这里与所有同样想知道的人分享我的猜测。
相关日志条目显示输入链中带有 TCP 标志ACK和PSH(push) 的数据包丢失。这表明网络中的某些服务正在等待来自 google 服务器的消息（通过。push）。但是等一下 - 为什么包会记录在输入链中？这很容易解释 - 如果路由器（或者如 @chexum 已经提到的 - conntrack）没有关于NATed/ PATed 流量的连接信息，则包看起来像是路由器的流量，而不是路由器后面任何设备的流量。所以这解释了为什么“google 正在向路由器发送流量”。
但问题是路由器为什么没有这些包的连接信息。目前我只能推测：在大多数用户上网时，会出现掉线现象。我猜是因为谷歌的回复时间太长（可能是因为它之前推送的流量比其他的要低），导致连接超时。这个特定路由器的 TCP 包超时时间约为 10 秒，而 为 5 秒SYN。再过一段时间，conntrack 将删除有关旧的“无效”流量的记忆，从那时起，来自此连接的每个流量都看起来像输入流量。这也是无效规则未被触发的一个可能解释。
我认为@samuel 应该再多观察一下，看看是否有任何可识别的模式。但总体而言，我同意@chexum 的观点，认为这些下降是可以忽略的。
答案2
它清楚地显示了从 Google IP 接收的数据包，其源端口为 443。
当然，也有可能有人利用 Google 的 IP 地址进行中间人攻击，或者有人从 Google（或入侵 Google）向你发送数据包，是的，但这非常，非常不太可能。
更有可能的是，您的数据包过滤器和/或 conntrack 子系统（或路由器和/或 ISP 上的类似功能）已经看到来自 google:443 和 yourip:40382 之间的数据包流的数据包，显示连接已被关闭。
通常，您发起的连接不会被数据包过滤器记录，但这仅适用于已建立的连接。
FIN当连接被双方或任何一方关闭时RST，该连接将不再被视为ESTABLISHED。任何一方延迟或重新发送的数据包都将被视为新数据包，并被数据包过滤器记录下来，特别是如果删除的 conntrack 条目阻止将数据包发送到其正确的目的地。
这种情况很常见，可能根本没有理由担心，您通常可以安全地忽略那些记录的数据包。
如果您发现任何模式并想要进行调查，您可以继续tcpdump在系统上运行，记录来自类似 IP 地址的所有数据包，然后当您看到另一个类似的日志时，您可以停止 tcpdump，并过滤本地端口以查看您是否确实在事件发生前几秒钟打开了连接。
上述 tcpdump 的示例如下：
tcpdump -ieth0 -s0 -w /var/tmp/allssl.cap port 443