首页 > 其他分享 >网络地址转换（NAT）之报文跟踪

网络地址转换（NAT）之报文跟踪

时间：2023-12-28 16:13:19浏览次数：37  
标签：trace ip 报文 tcp 网络地址 NAT 规则 inet

网络地址转换（NAT）之报文跟踪

来源  https://fedoramagazine.org/network-address-translation-part-1-packet-tracing/

参考 https://linux.cn/article-13364-1.html

 

这是有关 网络地址转换(network address translation)（NAT）的系列文章中的第一篇。这一部分将展示如何使用 iptables/nftables 报文跟踪功能来定位 NAT 相关的连接问题。

引言

网络地址转换（NAT）是一种将容器或虚拟机暴露在互联网中的一种方式。传入的连接请求将其目标地址改写为另一个地址，随后被路由到容器或虚拟机。相同的技术也可用于负载均衡，即传入的连接被分散到不同的服务器上去。

当网络地址转换没有按预期工作时，连接请求将失败，会暴露错误的服务，连接最终出现在错误的容器中，或者请求超时，等等。调试此类问题的一种方法是检查传入请求是否与预期或已配置的转换相匹配。

连接跟踪

NAT 不仅仅是修改 IP 地址或端口号。例如，在将地址 X 映射到 Y 时，无需添加新规则来执行反向转换。一个被称为 “conntrack” 的 netfilter 系统可以识别已有连接的回复报文。每个连接都在 conntrack 系统中有自己的 NAT 状态。反向转换是自动完成的。

规则匹配跟踪

nftables 工具（以及在较小的程度上，iptables）允许针对某个报文检查其处理方式以及该报文匹配规则集合中的哪条规则。为了使用这项特殊的功能，可在合适的位置插入“跟踪规则”。这些规则会选择被跟踪的报文。假设一个来自 IP 地址 C 的主机正在访问一个 IP 地址是 S 以及端口是 P 的服务。我们想知道报文匹配了哪条 NAT 转换规则，系统检查了哪些规则，以及报文是否在哪里被丢弃了。

由于我们要处理的是传入连接，所以我们将规则添加到 prerouting 钩子上。prerouting 意味着内核尚未决定将报文发往何处。修改目标地址通常会使报文被系统转发，而不是由主机自身处理。

初始配置

# nft 'add table inet trace_debug'
# nft 'add chain inet trace_debug trace_pre { type filter hook prerouting priority -200000; }'
# nft "insert rule inet trace_debug trace_pre ip saddr $C ip daddr $S tcp dport $P tcp flags syn limit rate 1/second meta nftrace set 1"

第一条规则添加了一张新的规则表，这使得将来删除和调试规则可以更轻松。一句 nft delete table inet trace_debug 命令就可以删除调试期间临时加入表中的所有规则和链。

第二条规则在系统进行路由选择之前（prerouting 钩子）创建了一个基本钩子，并将其优先级设置为负数，以保证它在连接跟踪流程和 NAT 规则匹配之前被执行。

然而，唯一最重要的部分是第三条规则的最后一段：meta nftrace set 1。这条规则会使系统记录所有匹配这条规则的报文所关联的事件。为了尽可能高效地查看跟踪信息（提高信噪比），考虑对跟踪的事件增加一个速率限制，以保证其数量处于可管理的范围。一个好的选择是限制每秒钟最多一个报文或一分钟最多一个报文。上述案例记录了所有来自终端 $C 且去往终端 $S 的端口 $P 的所有 SYN 报文和 SYN/ACK 报文。限制速率的配置语句可以防范事件过多导致的洪泛风险。事实上，大多数情况下只记录一个报文就足够了。

对于 iptables 用户来讲，配置流程是类似的。等价的配置规则类似于：

# iptables -t raw -I PREROUTING -s $C -d $S -p tcp --tcp-flags SYN SYN  --dport $P  -m limit --limit 1/s -j TRACE

获取跟踪事件

原生 nft 工具的用户可以直接运行 nft 进入 nft 跟踪模式：

# nft monitor trace

这条命令会将收到的报文以及所有匹配该报文的规则打印出来（用 CTRL-C 来停止输出）：

trace id f0f627 ip raw prerouting  packet: iif "veth0" ether saddr ..

我们将在下一章详细分析该结果。如果你用的是 iptables，首先通过 iptables –version 命令检查一下已安装的版本。例如：

# iptables --version
iptables v1.8.5 (legacy)

(legacy) 意味着被跟踪的事件会被记录到内核的环形缓冲区中。你可以用 dmesg 或 journalctl 命令来查看这些事件。这些调试输出缺少一些信息，但和新工具提供的输出从概念上来讲很类似。你将需要首先查看规则被记录下来的行号，并与活跃的 iptables 规则集合手动关联。如果输出显示 (nf_tables)，你可以使用 xtables-monitor 工具：

# xtables-monitor --trace

如果上述命令仅显示版本号，你仍然需要查看 dmesg/journalctl 的输出。xtables-monitor 工具和 nft 监控跟踪工具使用相同的内核接口。它们之间唯一的不同点就是，xtables-monitor 工具会用 iptables 的语法打印事件，且如果你同时使用了 iptables-nft 和 nft，它将不能打印那些使用了 maps/sets 或其他只有 nftables 才支持的功能的规则。

示例

我们假设需要调试一个到虚拟机/容器的端口不通的问题。ssh -p 1222 10.1.2.3 命令应该可以远程连接那台服务器上的某个容器，但连接请求超时了。

你拥有运行那台容器的主机的登录权限。现在登录该机器并增加一条跟踪规则。可通过前述案例查看如何增加一个临时的调试规则表。跟踪规则类似于这样：

nft "insert rule inet trace_debug trace_pre ip daddr 10.1.2.3 tcp dport 1222 tcp flags syn limit rate 6/minute meta nftrace set 1"

在添加完上述规则后，运行 nft monitor trace，在跟踪模式下启动 nft，然后重试刚才失败的 ssh 命令。如果规则集较大，会出现大量的输出。不用担心这些输出，下一节我们会做逐行分析。

trace id 9c01f8 inet trace_debug trace_pre packet: iif "enp0" ether saddr .. ip saddr 10.2.1.2 ip daddr 10.1.2.3 ip protocol tcp tcp dport 1222 tcp flags == syn
trace id 9c01f8 inet trace_debug trace_pre rule ip daddr 10.2.1.2 tcp dport 1222 tcp flags syn limit rate 6/minute meta nftrace set 1 (verdict continue)
trace id 9c01f8 inet trace_debug trace_pre verdict continue
trace id 9c01f8 inet trace_debug trace_pre policy accept
trace id 9c01f8 inet nat prerouting packet: iif "enp0" ether saddr .. ip saddr 10.2.1.2 ip daddr 10.1.2.3 ip protocol tcp  tcp dport 1222 tcp flags == syn
trace id 9c01f8 inet nat prerouting rule ip daddr 10.1.2.3  tcp dport 1222 dnat ip to 192.168.70.10:22 (verdict accept)
trace id 9c01f8 inet filter forward packet: iif "enp0" oif "veth21" ether saddr .. ip daddr 192.168.70.10 .. tcp dport 22 tcp flags == syn tcp window 29200
trace id 9c01f8 inet filter forward rule ct status dnat jump allowed_dnats (verdict jump allowed_dnats)
trace id 9c01f8 inet filter allowed_dnats rule drop (verdict drop)
trace id 20a4ef inet trace_debug trace_pre packet: iif "enp0" ether saddr .. ip saddr 10.2.1.2 ip daddr 10.1.2.3 ip protocol tcp tcp dport 1222 tcp flags == syn

对跟踪结果作逐行分析

输出结果的第一行是触发后续输出的报文编号。这一行的语法与 nft 规则语法相同，同时还包括了接收报文的首部字段信息。你也可以在这一行找到接收报文的接口名称（此处为 enp0）、报文的源和目的 MAC 地址、报文的源 IP 地址（可能很重要 - 报告问题的人可能选择了一个错误的或非预期的主机），以及 TCP 的源和目的端口。同时你也可以在这一行的开头看到一个“跟踪编号”。该编号标识了匹配跟踪规则的特定报文。第二行包括了该报文匹配的第一条跟踪规则：

trace id 9c01f8 inet trace_debug trace_pre rule ip daddr 10.2.1.2 tcp dport 1222 tcp flags syn limit rate 6/minute meta nftrace set 1 (verdict continue)

这就是刚添加的跟踪规则。这里显示的第一条规则总是激活报文跟踪的规则。如果在这之前还有其他规则，它们将不会在这里显示。如果没有任何跟踪输出结果，说明没有抵达这条跟踪规则，或者没有匹配成功。下面的两行表明没有后续的匹配规则，且 trace_pre 钩子允许报文继续传输（判定为接受）。

下一条匹配规则是：

trace id 9c01f8 inet nat prerouting rule ip daddr 10.1.2.3  tcp dport 1222 dnat ip to 192.168.70.10:22 (verdict accept)

这条 DNAT 规则设置了一个到其他地址和端口的映射。规则中的参数 192.168.70.10 是需要收包的虚拟机的地址，目前为止没有问题。如果它不是正确的虚拟机地址，说明地址输入错误，或者匹配了错误的 NAT 规则。

IP 转发

通过下面的输出我们可以看到，IP 路由引擎告诉 IP 协议栈，该报文需要被转发到另一个主机：

trace id 9c01f8 inet filter forward packet: iif "enp0" oif "veth21" ether saddr .. ip daddr 192.168.70.10 .. tcp dport 22 tcp flags == syn tcp window 29200

这是接收到的报文的另一种呈现形式，但和之前相比有一些有趣的不同。现在的结果有了一个输出接口集合。这在之前不存在的，因为之前的规则是在路由决策之前（prerouting 钩子）。跟踪编号和之前一样，因此仍然是相同的报文，但目标地址和端口已经被修改。假设现在还有匹配 tcp dport 1222 的规则，它们将不会对现阶段的报文产生任何影响了。

如果该行不包含输出接口（oif），说明路由决策将报文路由到了本机。对路由过程的调试属于另外一个主题，本文不再涉及。

trace id 9c01f8 inet filter forward rule ct status dnat jump allowed_dnats (verdict jump allowed_dnats)

这条输出表明，报文匹配到了一个跳转到 allowed_dnats 链的规则。下一行则说明了连接失败的根本原因：

trace id 9c01f8 inet filter allowed_dnats rule drop (verdict drop)

这条规则无条件地将报文丢弃，因此后续没有关于该报文的日志输出。下一行则是另一个报文的输出结果了：

trace id 20a4ef inet trace_debug trace_pre packet: iif "enp0" ether saddr .. ip saddr 10.2.1.2 ip daddr 10.1.2.3 ip protocol tcp tcp dport 1222 tcp flags == syn

跟踪编号已经和之前不一样，然后报文的内容却和之前是一样的。这是一个重传尝试：第一个报文被丢弃了，因此 TCP 尝试了重传。可以忽略掉剩余的输出结果了，因为它并没有提供新的信息。现在是时候检查那条链了。

规则集合分析

上一节我们发现报文在 inet filter 表中的一个名叫 allowed_dnats 的链中被丢弃。现在我们来查看它：

# nft list chain inet filter allowed_dnats
table inet filter {
 chain allowed_dnats {
  meta nfproto ipv4 ip daddr . tcp dport @allow_in accept
  drop
   }
}

接受 @allow_in 集的数据包的规则没有显示在跟踪日志中。我们通过列出元素的方式，再次检查上述报文的目标地址是否在 @allow_in 集中：

# nft "get element inet filter allow_in { 192.168.70.10 . 22 }"
Error: Could not process rule: No such file or directory

不出所料，地址-服务对并没有出现在集合中。我们将其添加到集合中。

# nft "add element inet filter allow_in { 192.168.70.10 . 22 }"

现在运行查询命令，它将返回新添加的元素。

# nft "get element inet filter allow_in { 192.168.70.10 . 22 }"
table inet filter {
   set allow_in {
      type ipv4_addr . inet_service
      elements = { 192.168.70.10 . 22 }
   }
}

ssh 命令现在应该可以工作，且跟踪结果可以反映出该变化：

trace id 497abf58 inet filter forward rule ct status dnat jump allowed_dnats (verdict jump allowed_dnats)

trace id 497abf58 inet filter allowed_dnats rule meta nfproto ipv4 ip daddr . tcp dport @allow_in accept (verdict accept)

trace id 497abf58 ip postrouting packet: iif "enp0" oif "veth21" ether .. trace id 497abf58 ip postrouting policy accept

这表明报文通过了转发路径中的最后一个钩子 - postrouting。

如果现在仍然无法连接，问题可能处在报文流程的后续阶段，有可能并不在 nftables 的规则集合范围之内。

总结

本文介绍了如何通过 nftables 的跟踪机制检查丢包或其他类型的连接问题。本系列的下一篇文章将展示如何检查连接跟踪系统和可能与连接跟踪流相关的 NAT 信息。

 

============= End

 

这是有关 网络地址转换(network address translation)（NAT）的系列文章中的第一篇。这一部分将展示如何使用 iptables/nftables 报文跟踪功能来定位 NAT 相关的连接问题。

引言

网络地址转换（NAT）是一种将容器或虚拟机暴露在互联网中的一种方式。传入的连接请求将其目标地址改写为另一个地址，随后被路由到容器或虚拟机。相同的技术也可用于负载均衡，即传入的连接被分散到不同的服务器上去。

当网络地址转换没有按预期工作时，连接请求将失败，会暴露错误的服务，连接最终出现在错误的容器中，或者请求超时，等等。调试此类问题的一种方法是检查传入请求是否与预期或已配置的转换相匹配。

连接跟踪

NAT 不仅仅是修改 IP 地址或端口号。例如，在将地址 X 映射到 Y 时，无需添加新规则来执行反向转换。一个被称为 “conntrack” 的 netfilter 系统可以识别已有连接的回复报文。每个连接都在 conntrack 系统中有自己的 NAT 状态。反向转换是自动完成的。

规则匹配跟踪

nftables 工具（以及在较小的程度上，iptables）允许针对某个报文检查其处理方式以及该报文匹配规则集合中的哪条规则。为了使用这项特殊的功能，可在合适的位置插入“跟踪规则”。这些规则会选择被跟踪的报文。假设一个来自 IP 地址 C 的主机正在访问一个 IP 地址是 S 以及端口是 P 的服务。我们想知道报文匹配了哪条 NAT 转换规则，系统检查了哪些规则，以及报文是否在哪里被丢弃了。

由于我们要处理的是传入连接，所以我们将规则添加到 prerouting 钩子上。prerouting 意味着内核尚未决定将报文发往何处。修改目标地址通常会使报文被系统转发，而不是由主机自身处理。

初始配置

# nft 'add table inet trace_debug'
# nft 'add chain inet trace_debug trace_pre { type filter hook prerouting priority -200000; }'
# nft "insert rule inet trace_debug trace_pre ip saddr $C ip daddr $S tcp dport $P tcp flags syn limit rate 1/second meta nftrace set 1"

第一条规则添加了一张新的规则表，这使得将来删除和调试规则可以更轻松。一句 nft delete table inet trace_debug 命令就可以删除调试期间临时加入表中的所有规则和链。

第二条规则在系统进行路由选择之前（prerouting 钩子）创建了一个基本钩子，并将其优先级设置为负数，以保证它在连接跟踪流程和 NAT 规则匹配之前被执行。

然而，唯一最重要的部分是第三条规则的最后一段：meta nftrace set 1。这条规则会使系统记录所有匹配这条规则的报文所关联的事件。为了尽可能高效地查看跟踪信息（提高信噪比），考虑对跟踪的事件增加一个速率限制，以保证其数量处于可管理的范围。一个好的选择是限制每秒钟最多一个报文或一分钟最多一个报文。上述案例记录了所有来自终端 $C 且去往终端 $S 的端口 $P 的所有 SYN 报文和 SYN/ACK 报文。限制速率的配置语句可以防范事件过多导致的洪泛风险。事实上，大多数情况下只记录一个报文就足够了。

对于 iptables 用户来讲，配置流程是类似的。等价的配置规则类似于：

# iptables -t raw -I PREROUTING -s $C -d $S -p tcp --tcp-flags SYN SYN  --dport $P  -m limit --limit 1/s -j TRACE

获取跟踪事件

原生 nft 工具的用户可以直接运行 nft 进入 nft 跟踪模式：

# nft monitor trace

这条命令会将收到的报文以及所有匹配该报文的规则打印出来（用 CTRL-C 来停止输出）：

trace id f0f627 ip raw prerouting  packet: iif "veth0" ether saddr ..

我们将在下一章详细分析该结果。如果你用的是 iptables，首先通过 iptables –version 命令检查一下已安装的版本。例如：

# iptables --version
iptables v1.8.5 (legacy)

(legacy) 意味着被跟踪的事件会被记录到内核的环形缓冲区中。你可以用 dmesg 或 journalctl 命令来查看这些事件。这些调试输出缺少一些信息，但和新工具提供的输出从概念上来讲很类似。你将需要首先查看规则被记录下来的行号，并与活跃的 iptables 规则集合手动关联。如果输出显示 (nf_tables)，你可以使用 xtables-monitor 工具：

# xtables-monitor --trace

如果上述命令仅显示版本号，你仍然需要查看 dmesg/journalctl 的输出。xtables-monitor 工具和 nft 监控跟踪工具使用相同的内核接口。它们之间唯一的不同点就是，xtables-monitor 工具会用 iptables 的语法打印事件，且如果你同时使用了 iptables-nft 和 nft，它将不能打印那些使用了 maps/sets 或其他只有 nftables 才支持的功能的规则。

示例

我们假设需要调试一个到虚拟机/容器的端口不通的问题。ssh -p 1222 10.1.2.3 命令应该可以远程连接那台服务器上的某个容器，但连接请求超时了。

你拥有运行那台容器的主机的登录权限。现在登录该机器并增加一条跟踪规则。可通过前述案例查看如何增加一个临时的调试规则表。跟踪规则类似于这样：

nft "insert rule inet trace_debug trace_pre ip daddr 10.1.2.3 tcp dport 1222 tcp flags syn limit rate 6/minute meta nftrace set 1"

在添加完上述规则后，运行 nft monitor trace，在跟踪模式下启动 nft，然后重试刚才失败的 ssh 命令。如果规则集较大，会出现大量的输出。不用担心这些输出，下一节我们会做逐行分析。

trace id 9c01f8 inet trace_debug trace_pre packet: iif "enp0" ether saddr .. ip saddr 10.2.1.2 ip daddr 10.1.2.3 ip protocol tcp tcp dport 1222 tcp flags == syn
trace id 9c01f8 inet trace_debug trace_pre rule ip daddr 10.2.1.2 tcp dport 1222 tcp flags syn limit rate 6/minute meta nftrace set 1 (verdict continue)
trace id 9c01f8 inet trace_debug trace_pre verdict continue
trace id 9c01f8 inet trace_debug trace_pre policy accept
trace id 9c01f8 inet nat prerouting packet: iif "enp0" ether saddr .. ip saddr 10.2.1.2 ip daddr 10.1.2.3 ip protocol tcp  tcp dport 1222 tcp flags == syn
trace id 9c01f8 inet nat prerouting rule ip daddr 10.1.2.3  tcp dport 1222 dnat ip to 192.168.70.10:22 (verdict accept)
trace id 9c01f8 inet filter forward packet: iif "enp0" oif "veth21" ether saddr .. ip daddr 192.168.70.10 .. tcp dport 22 tcp flags == syn tcp window 29200
trace id 9c01f8 inet filter forward rule ct status dnat jump allowed_dnats (verdict jump allowed_dnats)
trace id 9c01f8 inet filter allowed_dnats rule drop (verdict drop)
trace id 20a4ef inet trace_debug trace_pre packet: iif "enp0" ether saddr .. ip saddr 10.2.1.2 ip daddr 10.1.2.3 ip protocol tcp tcp dport 1222 tcp flags == syn

对跟踪结果作逐行分析

输出结果的第一行是触发后续输出的报文编号。这一行的语法与 nft 规则语法相同，同时还包括了接收报文的首部字段信息。你也可以在这一行找到接收报文的接口名称（此处为 enp0）、报文的源和目的 MAC 地址、报文的源 IP 地址（可能很重要 - 报告问题的人可能选择了一个错误的或非预期的主机），以及 TCP 的源和目的端口。同时你也可以在这一行的开头看到一个“跟踪编号”。该编号标识了匹配跟踪规则的特定报文。第二行包括了该报文匹配的第一条跟踪规则：

trace id 9c01f8 inet trace_debug trace_pre rule ip daddr 10.2.1.2 tcp dport 1222 tcp flags syn limit rate 6/minute meta nftrace set 1 (verdict continue)

这就是刚添加的跟踪规则。这里显示的第一条规则总是激活报文跟踪的规则。如果在这之前还有其他规则，它们将不会在这里显示。如果没有任何跟踪输出结果，说明没有抵达这条跟踪规则，或者没有匹配成功。下面的两行表明没有后续的匹配规则，且 trace_pre 钩子允许报文继续传输（判定为接受）。

下一条匹配规则是：

trace id 9c01f8 inet nat prerouting rule ip daddr 10.1.2.3  tcp dport 1222 dnat ip to 192.168.70.10:22 (verdict accept)

这条 DNAT 规则设置了一个到其他地址和端口的映射。规则中的参数 192.168.70.10 是需要收包的虚拟机的地址，目前为止没有问题。如果它不是正确的虚拟机地址，说明地址输入错误，或者匹配了错误的 NAT 规则。

IP 转发

通过下面的输出我们可以看到，IP 路由引擎告诉 IP 协议栈，该报文需要被转发到另一个主机：

trace id 9c01f8 inet filter forward packet: iif "enp0" oif "veth21" ether saddr .. ip daddr 192.168.70.10 .. tcp dport 22 tcp flags == syn tcp window 29200

这是接收到的报文的另一种呈现形式，但和之前相比有一些有趣的不同。现在的结果有了一个输出接口集合。这在之前不存在的，因为之前的规则是在路由决策之前（prerouting 钩子）。跟踪编号和之前一样，因此仍然是相同的报文，但目标地址和端口已经被修改。假设现在还有匹配 tcp dport 1222 的规则，它们将不会对现阶段的报文产生任何影响了。

如果该行不包含输出接口（oif），说明路由决策将报文路由到了本机。对路由过程的调试属于另外一个主题，本文不再涉及。

trace id 9c01f8 inet filter forward rule ct status dnat jump allowed_dnats (verdict jump allowed_dnats)

这条输出表明，报文匹配到了一个跳转到 allowed_dnats 链的规则。下一行则说明了连接失败的根本原因：

trace id 9c01f8 inet filter allowed_dnats rule drop (verdict drop)

这条规则无条件地将报文丢弃，因此后续没有关于该报文的日志输出。下一行则是另一个报文的输出结果了：

trace id 20a4ef inet trace_debug trace_pre packet: iif "enp0" ether saddr .. ip saddr 10.2.1.2 ip daddr 10.1.2.3 ip protocol tcp tcp dport 1222 tcp flags == syn

跟踪编号已经和之前不一样，然后报文的内容却和之前是一样的。这是一个重传尝试：第一个报文被丢弃了，因此 TCP 尝试了重传。可以忽略掉剩余的输出结果了，因为它并没有提供新的信息。现在是时候检查那条链了。

规则集合分析

上一节我们发现报文在 inet filter 表中的一个名叫 allowed_dnats 的链中被丢弃。现在我们来查看它：

# nft list chain inet filter allowed_dnats
table inet filter {
 chain allowed_dnats {
  meta nfproto ipv4 ip daddr . tcp dport @allow_in accept
  drop
   }
}

接受 @allow_in 集的数据包的规则没有显示在跟踪日志中。我们通过列出元素的方式，再次检查上述报文的目标地址是否在 @allow_in 集中：

# nft "get element inet filter allow_in { 192.168.70.10 . 22 }"
Error: Could not process rule: No such file or directory

不出所料，地址-服务对并没有出现在集合中。我们将其添加到集合中。

# nft "add element inet filter allow_in { 192.168.70.10 . 22 }"

现在运行查询命令，它将返回新添加的元素。

# nft "get element inet filter allow_in { 192.168.70.10 . 22 }"
table inet filter {
   set allow_in {
      type ipv4_addr . inet_service
      elements = { 192.168.70.10 . 22 }
   }
}

ssh 命令现在应该可以工作，且跟踪结果可以反映出该变化：

trace id 497abf58 inet filter forward rule ct status dnat jump allowed_dnats (verdict jump allowed_dnats)

trace id 497abf58 inet filter allowed_dnats rule meta nfproto ipv4 ip daddr . tcp dport @allow_in accept (verdict accept)

trace id 497abf58 ip postrouting packet: iif "enp0" oif "veth21" ether .. trace id 497abf58 ip postrouting policy accept

这表明报文通过了转发路径中的最后一个钩子 - postrouting。

如果现在仍然无法连接，问题可能处在报文流程的后续阶段，有可能并不在 nftables 的规则集合范围之内。

总结

本文介绍了如何通过 nftables 的跟踪机制检查丢包或其他类型的连接问题。本系列的下一篇文章将展示如何检查连接跟踪系统和可能与连接跟踪流相关的 NAT 信息。

标签：trace,ip,报文,tcp,网络地址,NAT,规则,inet
From： https://www.cnblogs.com/lsgxeva/p/17932910.html

相关文章

  • PyTorch for Natural Language Processing: A Complete Overview
    1.背景介绍自然语言处理（NaturalLanguageProcessing,NLP）是计算机科学与人工智能的一个分支，旨在让计算机理解、解析和生成人类语言。自然语言处理的主要任务包括文本分类、情感分析、命名实体识别、语义角色标注、语义解析、机器翻译、语音识别、语音合成、问答系统、对话系统等。......
  • 【教程】React Native 应用中的代码混淆与安全性管理
    ​混淆是指对源代码进行加密、重命名等操作，以增加代码的复杂度，使其难以理解和反编译。在ReactNative中，混淆可以通过以下步骤实现：1.将JavaScript源代码转换为基于本机平台的二进制代码，可以使用工具如MetroBundler或babel进行转换。2.使用混淆工具，例如ipaguard（iOS平台），来对生......
  • 【代码混淆】react-native 代码混淆
    ​ 【代码混淆】react-native代码混淆 使用reactnative开发app，实现代码混淆的操作。无论是加密还是运行时虚拟机，最后都可以通过执行时调试把代码反向生成出来原来的代码，虽然能抵御低端的黑客攻击，但是对高端黑客却形同虚设。代码混淆是通过修改源代码结构和变量名，使得代码......
  • vmware vmnat1和vmnat8在真机网络适配器中消失
    在真机的网络适配器中，发现只有两张网卡。缺少vmnat1和vmnat8一，查看虚拟网络编辑器是否连接二，如果没有连接，勾选连接就好了。三，如果连接了，真机网络适配器仍然只有两张网络适配器。1.右键此电脑，管理2.在左侧导航栏选择系统工具，设备管理器。在中间选择展开网络适配器。3.查......
  • 关于SAP-DB-服务器组-创建SAPHanaTopology-资源报错-Unable to find agent SAPHanaTop
    SAPHanaTopology资源收集每个节点上的SAPHANA系统复制的状态和配置。为配置以下属性SAPHanaTopology。运行以下命令来创建SAPHANATopology资源：笔者在SAP-DB-服务器组-pacemaker集群中，创建SAPHanaTopology资源时，使用如下命令：[root@db01qq-5201351]#pcsresourcecreate......
  • 干货分享 | TSMaster报文发送的信号生成器操作说明
    信号生成器功能是TSMaster分析中的报文发送模块。信号生成器用于发送和配置每个CAN/LIN信号的值变化行为，简而言之，这是一个可以控制和调整CAN/LIN信号值的功能。我们可选择的信号生成器类型有8种，今天重点和大家分享一下关于TSMaster信号生成器的8种类型的使用方式。本文关键字：信号......
  • 自定义消息转换器对请求报文的统一解密处理
    1.自定义拦截器Interceptorpackagecom.example.springbootdemo.config;importlombok.extern.slf4j.Slf4j;importorg.springframework.web.servlet.HandlerInterceptor;importjavax.servlet.http.HttpServletRequest;importjavax.servlet.http.HttpServletResponse;......
  • linux-firewalld 和iptable的策略配置(nat 以及端口开放)
    一、配置防火墙开发端口1、sudoyuminstallfirewalldsudosystemctlstartfirewalldsudosystemctlenablefirewalld2、配置防火墙规则firewall-cmd--permanent--add-service=sshfirewall-cmd--permanent--add-service=httpfirewall-cmd--permanent......
  • 当 ChatGPT 有了身体会怎样？《Nature》预测 2024 科技大事丨 RTE 开发者日报 Vol.112
       开发者朋友们大家好： 这里是「RTE开发者日报」，每天和大家一起看新闻、聊八卦。我们的社区编辑团队会整理分享RTE（RealTimeEngagement）领域内「有话题的新闻」、「有态度的观点」、「有意思的数据」、「有思考的文章」、「有看点的会议」，但内容仅代表......
  • SAP-DB-服务器组-003-pacemaker集群-在AWS平台里-创建及配置-SAPHanaTopology资源及SA
    关于基础环境的安装，还是可以参考笔者另一篇文章，APP的部分《SAP-APP-服务器组-001-pacemaker集群的基础环境的安装部署》https://www.cnblogs.com/5201351/p/17899446.html 1、DB需要多安装  resource-agents-sap-hana[root@db01qq-5201351]#yuminstall-yresource-ag......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99