我在 dmesg 日志¹中看到大量以下两行内容：
[602956.308844] [iptables] (10): IN=eno1 OUT=eno2 MAC=xx:yy:..:zz SRC=10.174.26.245 DST=192.168.22.59 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=53 DPT=47150 WINDOW=28960 RES=0x00 ACK SYN URGP=0
[602956.652575] [iptables] (10): IN=eno1 OUT=eno2 MAC=xx:yy:..:zz SRC=10.172.0.22 DST=192.168.22.59 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=53 DPT=44204 WINDOW=28960 RES=0x00 ACK SYN URGP=0
我的防火墙阻止了这些，因为它无法识别 10.172.0.22 和 10.174.26.245 IP 地址。
实际上，查看 eno1 和 eno2 的 IP 地址列表，这两个 IP 地址并不包含在内。我使用两个 10.xxx 的 IP 地址，但不包括上面列出的两个（因此防火墙屏蔽了这两个 IP 地址）。
我的网络看起来是这样的：
+----------+ +--------+ +--------+ +--------+
| Internet |<--->| Router |<--->| Server |<--->| Laptop |
+----------+ +--------+ +--------+ +--------+
服务器和笔记本电脑都安装了防火墙。笔记本电脑的IP地址是192.168.22.59。它没有收到任何UDP TCP数据包。
eno1 和 eno2 位于服务器上。eno1 连接到路由器，路由器再连接到互联网。路由器连接使用本地网络地址（IPv4 和 IPv6）。eno2 是我的本地网络（LAN）。服务器设置为转发笔记本电脑和互联网之间的流量。
笔记本电脑使用了VPN，我怀疑它可能来自VPN，但笔记本电脑本身也装有防火墙，因此也会忽略此类流量。我想知道这些数据包来自哪里？是本地系统，还是来自黑客？或者VPN可能是罪魁祸首？无论如何，我不明白UDP TCP数据包怎么会使用网络接口上不存在的IP地址；如果是本地的，我也不明白它怎么会从外部传入。假设是本地进程发送了这些数据包，有什么办法可以找出它吗？
附注：我安装了 libvirt，但我尝试停止正在运行的一个 VPN，结果没有任何效果。而且，它创建的两个网桥不使用 10.17[24].xx 这两个 IP 地址。另外，我实在想不出 VPN 会把UDP TCP 数据包发送到错误的机器的原因。
更新
于是，我打开笔记本电脑，重新连接了 VPN。之后，上面两行代码就不再出现了。
这让我看到了另一行：
[608974.298853] [iptables] (192): IN=eno1np0 OUT=eno2np1 MAC=xx:yy:...:zz SRC=192.168.19.2 DST=192.168.22.189 LEN=151 TOS=0x00 PREC=0x00 TTL=63 ID=8281 DF PROTO=UDP SPT=53 DPT=47512 LEN=131
这个是UDP协议，但关键在于，就像笔记本电脑一样，它需要来自路由器（也就是互联网）的本地IP地址的数据。设备189是我的惠普打印机，所以它可能也有一个类似VPN的系统，并且偶尔会以这种方式导致DNS请求失败。
解决
我实际上可以在路由表中看到这两个 IP，您可以这样做：
$ ip route
这意味着我的图表会更像这样：
+----------+ +-----+ +--------+ +--------+ +--------+
| Internet |<--->| VPN |<--->| Router |<--->| Server |<--->| Laptop |
+----------+ +-----+ +--------+ +--------+ +--------+
当然，正如telcoM所说，路由器和VPN之间也存在ISP，但这不是罪魁祸首。我现在直接丢弃了这些数据包，而没有先记录它们：
-A bad_tcp_packets -i eno1 -s 10.172.0.0/16 -j DROP
-A bad_tcp_packets -i eno1 -s 10.174.0.0/16 -j DROP
需要注意的是：这意味着使用 VPN 可能会打开另一端的一组本地IP 地址。因此，您必须注意这一点，因为这可能会影响您的 LAN 设置。
¹我设置了防火墙来记录此类访问，以确保能够发现此类问题。目前，我并非试图回避日志，而是试图理解它。
您列出的两个日志消息都有
PROTO=TCP SPT=53和ACK SYN URGP=0。所以协议是TCP，而不是UDP。不过，如果每次都是在笔记本电脑和其中一个神秘IP地址之间交换两个UDP数据包之后发生的，我也不会太惊讶。
SYN+ACK 表示这些数据包是 TCP 初始三次握手的第二步：客户端发送 SYN，服务器以 SYN+ACK 进行响应，客户端以 ACK 进行确认，从而建立 TCP 连接。
由于SYN+ACK数据包是服务器响应，所以它的源端口与原始SYN数据包的目的端口相同，并
SPT=53标明端口号为53。端口 53（UDP 和 TCP）上众所周知的服务是……DNS。因此，10.174.0.22 和 10.174.26.245 很可能是您的互联网服务提供商 (ISP) 的 DNS 解析服务器。由于可公开路由的 IPv4 地址越来越宝贵，ISP 似乎已将其客户端使用的 DNS 解析服务器移至 10.xxx IP 段，因为 DNS 解析服务器不必是公开的：只有 ISP 自己的客户才需要能够访问它们。这与权威DNS 服务器不同，权威 DNS 服务器必须是公开的，以便全球其他 DNS 解析服务器能够访问它们。
所以你的网络实际上更像是：
这两个神秘的 IP 地址应该位于“ISP 基础设施”框内的某个位置。
一个简单的 DNS 客户端最初会将 DNS 查询作为 UDP 数据包发送。DNS 服务器会以 UDP 数据包进行响应，但如果完整的响应无法包含在单个 UDP 数据包中（例如，由于客户端正在尝试解析属于拥有大量 IP 地址的云服务的名称），DNS 解析服务器的单数据包 UDP 响应将包含一个标志，该标志大致表示“这只是完整答案的开头；如果需要其余部分，请通过 TCP 再次请求”。解析服务器会缓存答案，因此，如果客户端通过 TCP 重新连接，它可以轻松地重新发送答案，并使用尽可能多的 TCP 数据包来获取完整的查询结果。
但是，如果这些神秘 IP与您的 ISP 的 DNS 解析服务器不匹配，那么可能是您的 ISP（或者您正在使用的 VPN）在隔离其客户的专用网络方面做得不好，并且您会听到“互联网背景噪音”（来自您的 ISP 的其他客户的专用网络的泄漏、端口扫描，甚至可能是试图假装来自您的专用网络的攻击尝试，以便您的防火墙可能不会阻止它们）。
如果是这种情况，您应该仔细设置服务器，使其仅转发必要的流量，仅此而已。您还应该看看是否可以在路由器中配置流量过滤器：如果可以，您应该过滤掉所有使用内部网络地址作为源 IP，但来自路由器左侧的流量。您还可以在路由器上从左到右方向阻止任何其他私有 IP 范围，只允许那些您的 ISP 合法使用的 IP 范围（如果有）。
假设您在网络中使用的网络掩码为 /24：
您还应该使用连接跟踪，让服务器自动接受从右到左发起的连接的合法回复。这样，您就可以更严格地选择服务器从左到右方向转发的内容。
当您在笔记本电脑上启动 VPN 隧道时，它通常会阻止来自/到 VPN 隧道服务器之外的所有地方的未加密连接（除非为您的本地网络配置了例外）并通过 VPN 隧道路由所有内容，因此笔记本电脑将看到的不是 ISP 的“互联网背景噪音”，而是 VPN 出口点的互联网背景噪音。
如果您已在笔记本电脑上配置 VPN，允许在 VPN 激活期间连接到本地网络，而 VPN 连接的防火墙设置不够严格，则您可能会通过 VPN 将未经请求的流量发送到您的本地网络。攻击者可能会发现您服务器的转发功能（如果限制不够），并利用该功能通过 VPN 进入本地网络，然后再通过您的常规互联网连接返回，从而有效地利用您的 VPN 连接来隐藏他们的活动。为了您的利益，请务必确保这种情况不会发生。