增加nf_conntrack_max固然可以緩解這個問題,或者說減小conntrack表項占據內核內存的時間也可以緩解之,然而這種補救措施都是治標不治本的.
然后在客戶端上執行echo $sec /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
其中sec要比服務器端的sleep參數更小即可。
如此udp客戶端將收不到服務器eho回來的字符串,因為客戶端只是放行狀態為establish的入流量,如果ip_conntrack_udp_timeout配置過于短暫,NEW狀態的conntrack過早被釋放,這樣將不會有establish狀態的流量了。對于UDP而言,由于它是不確認無連接允許丟包的,因此影響還不是很大,TCP也有類似的問題,那就是如果你連接一個很遠的且網絡狀況很惡劣的TCP服務器,然后你把ip_conntrack_tcp_timeout_synsent設置很小,這樣就幾乎完不成三次握手了,更進一步,如果你把ip_conntrack_tcp_timeout_established設置過小,那么一旦三次握手建立連接之后,客戶端和服務器之間很久不發包,當establish狀態到期后,conntrack被釋放,此時服務器端主動發來一個包,該包的conntrack狀態會是什么呢?因此給予tcp的establish狀態5天的時間,是可以理解的。需要注意的是,對于tcp而言,由于無法簡單的控制服務器發送syn-ack的延時,因此需要在establish狀態而不是new狀態做文章了(實際上,ip_conntrack的establish狀態映射成了tcp的多個狀態,包括syn-ack,ack,established),試試看,效果和udp的一樣。
前面關于ip_conntrack扯的太遠了,我們的首要問題是conntrack full的問題。實際上,如果深入思考這個conntrack full的問題,就會發現,并不是conntrack容量太小或者表項保留時間過長引發的full。現實中的萬事萬物都不是無限的,對于計算機資源而言,更應該節約使用,不能讓無關人士浪費這種資源,另外既然內核默認了一個表項的存活時間,那肯定是經過測試的經驗值,自有它的道理。因此本質問題在于很多不需要conntrack的包也被conntrack了,這樣就會擠掉很多真正需要conntrack的流量。
那么都是哪些流量需要conntrack呢?常用的就兩個,一個是任何使用ctstate或者state這些match的iptables規則,另外一個就是所有的iptables的nat表中的規則,如果我們事先知道哪些流量需要使用iptables的[ct]state來控制,并且也知道哪些流量需要做NAT,那么余下的流量就都是和conntrack無關的流量了,可以不被ip_conntrack來跟蹤。
幸運的是,Linux的Netfilter在PREROUTING以及OUTPUT這兩個HOOK的conntrack之前安插了一個優先級更高的table,那就是raw,通過它就可以分離出不需要被conntrack的流量。如果你確定只有某個網卡進來的流量才需要做NAT,那么就執行下面的規則:
可見,必要時同時采取三種方式比較有效:1.增大conntrack_max;2.減少狀態保存時間;3.分離無關流量。然而除了第三種方式,其余兩種方式在操作時必須給自己十足的理由那么做才行,對于1,比必須明白內核內存被占有的方式,對于2,看看本文的前半部分。
注解:不要過度減小NEW以及TCP的establish的CT狀態的timeout的原因
盡量不要減小NEW狀態時間,因為對于某些惡劣的網絡,一個數據包的來回確實需要很長時間,對于TCP而言,此時RTT還沒有測量呢。如果NEW狀態的conntrack保留時間過短,就會導致大量NEW狀態的連接,而對于很多依賴ctstate的模塊而言,這樣就會有問題,比如iptables的filter表中使用ESTABLISH狀態來放過前向包的返回包就會有問題,此時ip_conntrack很有可能由于NEW狀態時間過短而將返回包作為NEW狀態處理而不是ESTABLISH狀態,如此一來,返回包就無法通過了。如下圖所示:
使用簡單的實驗可以很容易證實上面的圖示,以簡單的udp通信為例,編寫一個udp-echo程序,服務器簡單echo客戶端送達的字符串:for(;;) { n = recvfrom(sd, msg, MAXLINE, 0, pcliaddr, &len); sleep(5); sendto(sd, msg, n, 0, pcliaddr, len); }
然后在客戶端上執行echo $sec /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
其中sec要比服務器端的sleep參數更小即可。
如此udp客戶端將收不到服務器eho回來的字符串,因為客戶端只是放行狀態為establish的入流量,如果ip_conntrack_udp_timeout配置過于短暫,NEW狀態的conntrack過早被釋放,這樣將不會有establish狀態的流量了。對于UDP而言,由于它是不確認無連接允許丟包的,因此影響還不是很大,TCP也有類似的問題,那就是如果你連接一個很遠的且網絡狀況很惡劣的TCP服務器,然后你把ip_conntrack_tcp_timeout_synsent設置很小,這樣就幾乎完不成三次握手了,更進一步,如果你把ip_conntrack_tcp_timeout_established設置過小,那么一旦三次握手建立連接之后,客戶端和服務器之間很久不發包,當establish狀態到期后,conntrack被釋放,此時服務器端主動發來一個包,該包的conntrack狀態會是什么呢?因此給予tcp的establish狀態5天的時間,是可以理解的。需要注意的是,對于tcp而言,由于無法簡單的控制服務器發送syn-ack的延時,因此需要在establish狀態而不是new狀態做文章了(實際上,ip_conntrack的establish狀態映射成了tcp的多個狀態,包括syn-ack,ack,established),試試看,效果和udp的一樣。
前面關于ip_conntrack扯的太遠了,我們的首要問題是conntrack full的問題。實際上,如果深入思考這個conntrack full的問題,就會發現,并不是conntrack容量太小或者表項保留時間過長引發的full。現實中的萬事萬物都不是無限的,對于計算機資源而言,更應該節約使用,不能讓無關人士浪費這種資源,另外既然內核默認了一個表項的存活時間,那肯定是經過測試的經驗值,自有它的道理。因此本質問題在于很多不需要conntrack的包也被conntrack了,這樣就會擠掉很多真正需要conntrack的流量。
那么都是哪些流量需要conntrack呢?常用的就兩個,一個是任何使用ctstate或者state這些match的iptables規則,另外一個就是所有的iptables的nat表中的規則,如果我們事先知道哪些流量需要使用iptables的[ct]state來控制,并且也知道哪些流量需要做NAT,那么余下的流量就都是和conntrack無關的流量了,可以不被ip_conntrack來跟蹤。
幸運的是,Linux的Netfilter在PREROUTING以及OUTPUT這兩個HOOK的conntrack之前安插了一個優先級更高的table,那就是raw,通過它就可以分離出不需要被conntrack的流量。如果你確定只有某個網卡進來的流量才需要做NAT,那么就執行下面的規則:
iptables -t raw -A PREROUTING ! –I $網卡 -j NOTRACK iptables –t raw –A OUTPUT –j NOTRACK這樣一來,資源就不會浪費在無關人士身上了,性能也會有所提高,因為凡是NOTRACK的流量,都不會去查詢conntrack的hash表,因為在ip(nf)_conntrack_in的內部的開始有一個判斷:
if ((*pskb)->nfct) return NF_ACCEPT;而NOTRACK這個target的實現也很簡單:
(*pskb)->nfct = &ip_conntrack_untracked.info[IP_CT_NEW];事實上將一個占位者設置給skb的nfct,這樣可以保持其它代碼的一致性。
可見,必要時同時采取三種方式比較有效:1.增大conntrack_max;2.減少狀態保存時間;3.分離無關流量。然而除了第三種方式,其余兩種方式在操作時必須給自己十足的理由那么做才行,對于1,比必須明白內核內存被占有的方式,對于2,看看本文的前半部分。
iptables -A FORWARD -m state --state UNTRACKED -j ACCEPT
最后有個提問:
對于沒有keepalive的TCP連接而言,試想服務器和客戶端在establish狀態之后5天內都沒有互相通信,5天后的一天,服務器主動發送了一個數據包給客戶端,然而此時防火墻/NAT設備上的conntrack狀態已經過期被刪除,此時該數據包將會被認為是NEW狀態的數據包,被DROP,客戶端永遠收不到這個數據包,進而也不會發送ACK,服務器端不斷重發,不斷被防火墻DROP,當重發次數達到一定次數后,服務器RESET該連接,然而客戶端如何得知,只有客戶端主動發包才能打破這個僵局,然而誰能保證客戶端一定會主動發包?這是不是Linux的ip_conntrack的一種缺陷,設計5天時間的establish狀態是不是一種極限措施,然而誰又能保證5天內兩端不斷通信呢?
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
