gtxyzz

网络地址转换(NAT)之报文跟踪

gtxyzz 运维技术 2022-11-11 357浏览 0

网络地址转换(NAT)之报文跟踪

这是有关网络地址转换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命令。如果规则集较大,会出现大量的输出。不用担心这些输出,

继续浏览有关 系统运维 的文章
发表评论