Linux系統如何平滑生效NAT BUGFIX

2021-08-27 13:30:18 字數 3669 閱讀 2343

在《

linux系統如何平滑生效nat》中,**有兩處問題。這只是目前發現的,沒有發現的還有很多很多,這就是我為何不一開始把**搞複雜的原因。

注意以下的**:

if (!nf_nat_initialized(ct, maniptype))  else

//nat已經設定進conn的情況

pf_debug("already setup manip %s for ct %p\n",

maniptype == ip_nat_manip_src ? "src" : "dst",

ct);

在nat已經設定進conn的情況下,僅僅列印了一行日誌,而判斷nat是否已經設定進conn的nf_nat_initialized實現正是兩個bit位,不同的hook點判斷位不同,而在我的原始實現中,是清除了alloc_null_binding設定的bit位,進而如果是alloc_null_binding將nat設定到了conn,也算沒有匹配到nat規則,最終繼續匹配,這樣就達到了「如果開始沒有配置任何nat時已經confirm了資料流,當配置好nat後能瞬時生效」的目的。

然而卻存在乙個問題,那就是當原來的nat規則改變了的時候,無法瞬時生效新nat規則的問題。這個問題比較難以解決,我先放置一邊,即使不考慮這個這個問題,光上述的**也有問題。何必在alloc_null_binding之後清除bit位呢?直接把「繼續查詢的邏輯放在那個else列印日誌的位置不就可以了麼?因此我還原了$k/net/ipv4/netfilter/nf_nat_standalone.c檔案的修改,也就是說nf_nat_rule_find函式不必再修改,而只需要修改nf_nat_fn,在else列印日誌的地方新增乙個goto即可,goto到if (!nf_nat_initialized(ct, maniptype))判斷的下一行,其餘的修改保持不變。

現在可以考慮已經是established狀態的conntrack的新nat規則及時生效的問題了,剛才之所以說它比較難,是因為這需要讓nf_nat_fn函式知道什麼時候有一條新的nat規則代替了舊的,而這種行為對於計算機而言,最終無非落實到的就是一系列的查詢與比較操作,這種事情做下來的話,還不如不再區分new與established狀態,乾脆每乙個資料報都執行一次nf_nat_rule_find算了,最終將完全失效linux nat實現的有狀態語義以及效率。因此這種高度策略化的配置應該由呼叫者來決定,所以我的修改方案就是增加乙個sysctl引數,如果使用者管理員想即使生效被改變的nat,那麼就將該引數設定為非0,以此來改變nat規則的匹配行為:

static unsigned int

nf_nat_fn(unsigned int hooknum,

struct sk_buff *skb,

const struct net_device *in,

const struct net_device *out,

int (*okfn)(struct sk_buff *))

}switch (ctinfo)

/* fall thru... (only icmps can be ip_ct_is_reply) */

//只要沒有返回包到來,能保證一直都是new

case ip_ct_new:

or local packets.. */

if (!nf_nat_initialized(ct, maniptype))

//以上沒有優化!!優化點在於:只有在非alloc_null_binding呼叫成功的情況

//下才會嘗試更新tuple的chain位置,否則不做無用功!

} else

break

default:

/* established */

nf_ct_assert(ctinfo == ip_ct_established ||

ctinfo == (ip_ct_established+ip_ct_is_reply));

//對於estableshed狀態的連線在sysctl引數為1的狀態下,強行進行nat規則查詢!

if ((ctinfo == ip_ct_established && ctinfo != (ip_ct_established+ip_ct_is_reply)) &&

nf_nat_slowpath)

...}

如果想對於已經生效nat的資料流改變nat策略的話,請設定sysctl_nf_nat_slowpath為1,持續$max_time後,將其設定回0。這是為何?因為不能破壞linux nat的原始邏輯以及不能影響效率!那麼max_time該怎麼選擇呢?當然是所有conntrack超時時間的最長者+10了,因為如果這麼長時間沒有資料報,conntrack超時被釋放,下乙個到來的包就是new了,如果恰好在這段時間期間有包,直接生效新的nat,加上5到10秒時間作為使用者態程式的時鐘校正,故而max_time設定的不多也不少。還有問題!

conntrack預設最長的時間是tcp的establish狀態,5天之久,這也太久了,因此就將所有的conntrack超時時間都縮短,最長的時間縮短為120秒,同時將nf_ct_tcp_be_liberal和nf_ct_tcp_loose兩個sysctl引數設定為1,撤銷tcp的詳細語義。

以上**的hlist_nulls_del_rcu,nf_conntrack_hash_insert等鍊錶操作涉及到了增和刪,一定要有鎖保護,但是我的**中沒有,這就是乙個明顯的bug,因此需要nf_conntrack_lock鎖的保護:

if (nf_ct_is_confirmed(ct)) {

struct net *net = nf_ct_net(ct);

spin_lock_bh(&nf_conntrack_lock);

//如果匹配到了新的規則,則更新tuple在chian中的位置。

hlist_nulls_del_rcu(&ct->tuplehash[ip_ct_dir_original].hnnode);

hlist_nulls_del_rcu(&ct->tuplehash[ip_ct_dir_reply].hnnode);

//如果不進行這個del and reinsert操作,那麼就會出現返回包無法被轉換

//成原始包的情形!

nf_conntrack_hash_insert(ct);

spin_unlock_bh(&nf_conntrack_lock);

...

本來我還想做的更完美一些的,就是說將delete/insert操作全部pending到乙個rcu序列裡面,因為我怕在delete和insert之間的空隙,同一流的資料報進入協議棧的conntrack_in,發生了find操作,這樣就會認為沒有找到tuple,進而重建乙個new狀態的conntrack,所以我想用rcu鎖進行保護,保證在沒有任何執行緒find這個雜湊的時候,才進行delete/insert操作,畢竟find操作真的是rcu鎖保護著呢!然而很快我就發現自己杞人憂天多此一舉了,如果發生上述的情況,新建立的new狀態的conntrack在離開協議棧的時候是不會被成功confirm的,因為在confirm的時候會進行一次find,如果已經find到了,就drop!如果進入confirm的時候,find之前,被delete的node還沒有insert進去怎麼辦?如果是我最初的那個版本,就完蛋了,然而剛剛進行了bugfix,不是有nf_conntrack_lock保護嗎,所以上面的情況是不會發生的。

Linux系統如何平滑生效NAT BUGFIX

在 linux系統如何平滑生效nat 中,有兩處問題。這只是目前發現的,沒有發現的還有很多很多,這就是我為何不一開始把 搞複雜的原因。注意以下的 if nf nat initialized ct,maniptype else nat已經設定進conn的情況 pf debug already setu...

Linux系統如何平滑生效NAT BUGFIX

在 linux系統如何平滑生效nat 中,有兩處問題。這只是目前發現的,沒有發現的還有很多很多,這就是我為何不一開始把 搞複雜的原因。注意以下的 if nf nat initialized ct,maniptype else nat已經設定進conn的情況 pf debug already setu...

Linux系統如何平滑生效NAT BUGFIX

在 linux系統如何平滑生效nat 中,有兩處問題。這只是目前發現的,沒有發現的還有很多很多,這就是我為何不一開始把 搞複雜的原因。注意以下的 if nf nat initialized ct,maniptype else nat已經設定進conn的情況 pf debug already setu...