[[397610]]

這是有關(guān)網(wǎng)絡(luò)地址轉(zhuǎn)換network address translation（NAT）的系列文章中的第一篇。這一部分將展示如何使用 iptables/nftables 報(bào)文跟蹤功能來定位 NAT 相關(guān)的連接問題。

引言

網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）是一種將容器或虛擬機(jī)暴露在互聯(lián)網(wǎng)中的一種方式。傳入的連接請(qǐng)求將其目標(biāo)地址改寫為另一個(gè)地址，隨后被路由到容器或虛擬機(jī)。相同的技術(shù)也可用于負(fù)載均衡，即傳入的連接被分散到不同的服務(wù)器上去。

當(dāng)網(wǎng)絡(luò)地址轉(zhuǎn)換沒有按預(yù)期工作時(shí)，連接請(qǐng)求將失敗，會(huì)暴露錯(cuò)誤的服務(wù)，連接最終出現(xiàn)在錯(cuò)誤的容器中，或者請(qǐng)求超時(shí)，等等。調(diào)試此類問題的一種方法是檢查傳入請(qǐng)求是否與預(yù)期或已配置的轉(zhuǎn)換相匹配。

連接跟蹤

NAT 不僅僅是修改 IP 地址或端口號(hào)。例如，在將地址 X 映射到 Y 時(shí)，無需添加新規(guī)則來執(zhí)行反向轉(zhuǎn)換。一個(gè)被稱為 “conntrack” 的 netfilter 系統(tǒng)可以識(shí)別已有連接的回復(fù)報(bào)文。每個(gè)連接都在 conntrack 系統(tǒng)中有自己的 NAT 狀態(tài)。反向轉(zhuǎn)換是自動(dòng)完成的。

規(guī)則匹配跟蹤

nftables 工具（以及在較小的程度上，iptables）允許針對(duì)某個(gè)報(bào)文檢查其處理方式以及該報(bào)文匹配規(guī)則集合中的哪條規(guī)則。為了使用這項(xiàng)特殊的功能，可在合適的位置插入“跟蹤規(guī)則”。這些規(guī)則會(huì)選擇被跟蹤的報(bào)文。假設(shè)一個(gè)來自 IP 地址 C 的主機(jī)正在訪問一個(gè) IP 地址是 S 以及端口是 P 的服務(wù)。我們想知道報(bào)文匹配了哪條 NAT 轉(zhuǎn)換規(guī)則，系統(tǒng)檢查了哪些規(guī)則，以及報(bào)文是否在哪里被丟棄了。

由于我們要處理的是傳入連接，所以我們將規(guī)則添加到 prerouting 鉤子上。prerouting 意味著內(nèi)核尚未決定將報(bào)文發(fā)往何處。修改目標(biāo)地址通常會(huì)使報(bào)文被系統(tǒng)轉(zhuǎn)發(fā)，而不是由主機(jī)自身處理。

初始配置

# 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"

第一條規(guī)則添加了一張新的規(guī)則表，這使得將來刪除和調(diào)試規(guī)則可以更輕松。一句 nft delete table inet trace_debug 命令就可以刪除調(diào)試期間臨時(shí)加入表中的所有規(guī)則和鏈。

第二條規(guī)則在系統(tǒng)進(jìn)行路由選擇之前（prerouting 鉤子）創(chuàng)建了一個(gè)基本鉤子，并將其優(yōu)先級(jí)設(shè)置為負(fù)數(shù)，以保證它在連接跟蹤流程和 NAT 規(guī)則匹配之前被執(zhí)行。

然而，唯一最重要的部分是第三條規(guī)則的最后一段：meta nftrace set 1。這條規(guī)則會(huì)使系統(tǒng)記錄所有匹配這條規(guī)則的報(bào)文所關(guān)聯(lián)的事件。為了盡可能高效地查看跟蹤信息（提高信噪比），考慮對(duì)跟蹤的事件增加一個(gè)速率限制，以保證其數(shù)量處于可管理的范圍。一個(gè)好的選擇是限制每秒鐘最多一個(gè)報(bào)文或一分鐘最多一個(gè)報(bào)文。上述案例記錄了所有來自終端 $C 且去往終端 $S 的端口 $P 的所有 SYN 報(bào)文和 SYN/ACK 報(bào)文。限制速率的配置語句可以防范事件過多導(dǎo)致的洪泛風(fēng)險(xiǎn)。事實(shí)上，大多數(shù)情況下只記錄一個(gè)報(bào)文就足夠了。

對(duì)于 iptables 用戶來講，配置流程是類似的。等價(jià)的配置規(guī)則類似于：

# 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 工具的用戶可以直接運(yùn)行 nft 進(jìn)入 nft 跟蹤模式：

# nft monitor trace

這條命令會(huì)將收到的報(bào)文以及所有匹配該報(bào)文的規(guī)則打印出來（用 CTRL-C 來停止輸出）：

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

我們將在下一章詳細(xì)分析該結(jié)果。如果你用的是 iptables，首先通過 iptables –version 命令檢查一下已安裝的版本。例如：

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

(legacy) 意味著被跟蹤的事件會(huì)被記錄到內(nèi)核的環(huán)形緩沖區(qū)中。你可以用 dmesg 或 journalctl 命令來查看這些事件。這些調(diào)試輸出缺少一些信息，但和新工具提供的輸出從概念上來講很類似。你將需要首先查看規(guī)則被記錄下來的行號(hào)，并與活躍的 iptables 規(guī)則集合手動(dòng)關(guān)聯(lián)。如果輸出顯示 (nf_tables)，你可以使用 xtables-monitor 工具：

# xtables-monitor --trace

如果上述命令僅顯示版本號(hào)，你仍然需要查看 dmesg/journalctl 的輸出。xtables-monitor 工具和 nft 監(jiān)控跟蹤工具使用相同的內(nèi)核接口。它們之間唯一的不同點(diǎn)就是，xtables-monitor 工具會(huì)用 iptables 的語法打印事件，且如果你同時(shí)使用了 iptables-nft 和 nft，它將不能打印那些使用了 maps/sets 或其他只有 nftables 才支持的功能的規(guī)則。

示例

我們假設(shè)需要調(diào)試一個(gè)到虛擬機(jī)/容器的端口不通的問題。ssh -p 1222 10.1.2.3 命令應(yīng)該可以遠(yuǎn)程連接那臺(tái)服務(wù)器上的某個(gè)容器，但連接請(qǐng)求超時(shí)了。

你擁有運(yùn)行那臺(tái)容器的主機(jī)的登錄權(quán)限?，F(xiàn)在登錄該機(jī)器并增加一條跟蹤規(guī)則?？赏ㄟ^前述案例查看如何增加一個(gè)臨時(shí)的調(diào)試規(guī)則表。跟蹤規(guī)則類似于這樣：

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"

在添加完上述規(guī)則后，運(yùn)行 nft monitor trace，在跟蹤模式下啟動(dòng) nft，然后重試剛才失敗的 ssh 命令。如果規(guī)則集較大，會(huì)出現(xiàn)大量的輸出。不用擔(dān)心這些輸出，下一節(jié)我們會(huì)做逐行分析。

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

對(duì)跟蹤結(jié)果作逐行分析

輸出結(jié)果的第一行是觸發(fā)后續(xù)輸出的報(bào)文編號(hào)。這一行的語法與 nft 規(guī)則語法相同，同時(shí)還包括了接收?qǐng)?bào)文的首部字段信息。你也可以在這一行找到接收?qǐng)?bào)文的接口名稱（此處為 enp0）、報(bào)文的源和目的 MAC 地址、報(bào)文的源 IP 地址（可能很重要 - 報(bào)告問題的人可能選擇了一個(gè)錯(cuò)誤的或非預(yù)期的主機(jī)），以及 TCP 的源和目的端口。同時(shí)你也可以在這一行的開頭看到一個(gè)“跟蹤編號(hào)”。該編號(hào)標(biāo)識(shí)了匹配跟蹤規(guī)則的特定報(bào)文。第二行包括了該報(bào)文匹配的第一條跟蹤規(guī)則：

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)

這就是剛添加的跟蹤規(guī)則。這里顯示的第一條規(guī)則總是激活報(bào)文跟蹤的規(guī)則。如果在這之前還有其他規(guī)則，它們將不會(huì)在這里顯示。如果沒有任何跟蹤輸出結(jié)果，說明沒有抵達(dá)這條跟蹤規(guī)則，或者沒有匹配成功。下面的兩行表明沒有后續(xù)的匹配規(guī)則，且 trace_pre 鉤子允許報(bào)文繼續(xù)傳輸（判定為接受）。

下一條匹配規(guī)則是：

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 規(guī)則設(shè)置了一個(gè)到其他地址和端口的映射。規(guī)則中的參數(shù) 192.168.70.10 是需要收包的虛擬機(jī)的地址，目前為止沒有問題。如果它不是正確的虛擬機(jī)地址，說明地址輸入錯(cuò)誤，或者匹配了錯(cuò)誤的 NAT 規(guī)則。

IP 轉(zhuǎn)發(fā)

通過下面的輸出我們可以看到，IP 路由引擎告訴 IP 協(xié)議棧，該報(bào)文需要被轉(zhuǎn)發(fā)到另一個(gè)主機(jī)：

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

這是接收到的報(bào)文的另一種呈現(xiàn)形式，但和之前相比有一些有趣的不同?，F(xiàn)在的結(jié)果有了一個(gè)輸出接口集合。這在之前不存在的，因?yàn)橹暗囊?guī)則是在路由決策之前（prerouting 鉤子）。跟蹤編號(hào)和之前一樣，因此仍然是相同的報(bào)文，但目標(biāo)地址和端口已經(jīng)被修改。假設(shè)現(xiàn)在還有匹配 tcp dport 1222 的規(guī)則，它們將不會(huì)對(duì)現(xiàn)階段的報(bào)文產(chǎn)生任何影響了。

如果該行不包含輸出接口（oif），說明路由決策將報(bào)文路由到了本機(jī)。對(duì)路由過程的調(diào)試屬于另外一個(gè)主題，本文不再涉及。

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

這條輸出表明，報(bào)文匹配到了一個(gè)跳轉(zhuǎn)到 allowed_dnats 鏈的規(guī)則。下一行則說明了連接失敗的根本原因：

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

這條規(guī)則無條件地將報(bào)文丟棄，因此后續(xù)沒有關(guān)于該報(bào)文的日志輸出。下一行則是另一個(gè)報(bào)文的輸出結(jié)果了：

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

跟蹤編號(hào)已經(jīng)和之前不一樣，然后報(bào)文的內(nèi)容卻和之前是一樣的。這是一個(gè)重傳嘗試：第一個(gè)報(bào)文被丟棄了，因此 TCP 嘗試了重傳。可以忽略掉剩余的輸出結(jié)果了，因?yàn)樗]有提供新的信息?，F(xiàn)在是時(shí)候檢查那條鏈了。

規(guī)則集合分析

上一節(jié)我們發(fā)現(xiàn)報(bào)文在 inet 過濾表中的一個(gè)名叫 allowed_dnats 的鏈中被丟棄。現(xiàn)在我們來查看它：

# 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 集的數(shù)據(jù)包的規(guī)則沒有顯示在跟蹤日志中。我們通過列出元素的方式，再次檢查上述報(bào)文的目標(biāo)地址是否在 @allow_in 集中：

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

不出所料，地址-服務(wù)對(duì)并沒有出現(xiàn)在集合中。我們將其添加到集合中。

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

現(xiàn)在運(yùn)行查詢命令，它將返回新添加的元素。

# 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 命令現(xiàn)在應(yīng)該可以工作，且跟蹤結(jié)果可以反映出該變化：

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

這表明報(bào)文通過了轉(zhuǎn)發(fā)路徑中的最后一個(gè)鉤子 - postrouting。

如果現(xiàn)在仍然無法連接，問題可能處在報(bào)文流程的后續(xù)階段，有可能并不在 nftables 的規(guī)則集合范圍之內(nèi)。

總結(jié)

本文介紹了如何通過 nftables 的跟蹤機(jī)制檢查丟包或其他類型的連接問題。本系列的下一篇文章將展示如何檢查連接跟蹤系統(tǒng)和可能與連接跟蹤流相關(guān)的 NAT 信息。