nf_conntrack: table full, dropping packet 連線跟蹤表已滿，開始丟包 的解決辦法

中午業務說機器不能登入，我通過USM管理介面登入單板的時候發現機器沒有僵死，然後一看日誌，g一下子就明白了

tail -2000 /var/log/messages

Apr 10 12:48:35 bj-push-pushserver83 kernel: [95129.138804] __ratelimit: 16523 callbacks suppressed (“連線跟蹤表已滿，開始丟包”！相信不少用iptables的同學都會見過這個錯誤資訊吧)

Apr 10 12:48:35 bj-xx kernel: [95129.138806] nf_conntrack: table full, dropping packet.

Apr 10 12:48:35 bj-xx kernel: [95129.138974] nf_conntrack: table full, dropping packet.

Apr 10 12:48:35 bj-xx kernel: [95129.139142] nf_conntrack: table full, dropping packet.

Apr 10 12:48:35 bj-xx kernel: [95129.139566] nf_conntrack: table full, dropping packet.

Apr 10 12:48:35 bj-xx kernel: [95129.139747] nf_conntrack: table full, dropping packet.

Apr 10 12:48:35 bj-xx kernel: [95129.139823] nf_conntrack: table full, dropping packet.

Apr 10 12:48:35 bj-xx kernel: [95129.140188] nf_conntrack: table full, dropping packet.

Apr 10 12:48:35 bj-xx kernel: [95129.140435] nf_conntrack: table full, dropping packet.

Apr 10 12:48:35 bj-xx kernel: [95129.140508] nf_conntrack: table full, dropping packet.

Apr 10 12:48:35 bj-xx kernel: [95129.141133] nf_conntrack: table full, dropping packet.

Apr 10 12:48:38 bj-xx kernel: [95131.483097] possible SYN flooding on port 443. Sending cookies.

Apr 10 12:49:01 bj-xx /usr/sbin/cron[9492]: (root) CMD (/usr/bin/tsar –cron > /dev/null 2>&1)

Apr 10 12:49:38 bj-xx kernel: [95191.382486] possible SYN flooding on port 443. Sending cookies.

Apr 10 12:50:01 bj-xx /usr/sbin/cron[9761]: (root) CMD (/opt/huawei/logs/LoadRst/suseRst.sh 2>/dev/null)

Apr 10 12:50:01 bj-xx /usr/sbin/cron[9762]: (root) CMD (/usr/bin/tsar –cron > /dev/null 2>&1)

Apr 10 12:50:38 bj-xx kernel: [95251.283552] possible SYN flooding on port 443. Sending cookies.

Apr 10 12:51:01 bj-xx /usr/sbin/cron[9990]: (root) CMD (/usr/bin/tsar –cron > /dev/null 2>&1)

Apr 10 12:51:38 bj-xx kernel: [95311.185024] possible SYN flooding on port 443. Sending cookies.

Apr 10 12:52:01 bj-xx /usr/sbin/cron[10232]: (root) CMD (/usr/bin/tsar –cron > /dev/null 2>&1)

Apr 10 12:52:38 bj-xx kernel: [95371.082714] possible SYN flooding on port 443. Sending cookies.

Apr 10 12:52:59 bj-xx sshd[9994]: pam_unix2(sshd:auth): conversation failed

Apr 10 12:52:59 bj-xx sshd[9994]: error: ssh_msg_send: write

Apr 10 12:53:01 bj-xx /usr/sbin/cron[10891]: (root) CMD (/usr/bin/tsar –cron > /dev/null 2>&1)

Apr 10 12:53:38 bj-xx kernel: [95430.983871] possible SYN flooding on port 443. Sending cookies.

Apr 10 12:54:01 bj-xx /usr/sbin/cron[11097]: (root) CMD (/usr/bin/tsar –cron > /dev/null 2>&1)

Apr 10 12:54:04 bj-xx sshd[11094]: pam_tally(sshd:account): unknown option: reset

Apr 10 12:54:04 bj-xx sshd[11094]: Accepted publickey for root from 183.62.156.75 port 16959 ssh2

Apr 10 12:54:38 bj-xx kernel: [95490.883402] possible SYN flooding on port 443. Send

都是指令碼和任務計劃惹的禍

指令碼內容

cat /opt/xx/logs/LoadRst/suseRst.sh

!/bin/bash

cd dirname $0

loadnum=uptime|awk -F':' '{print $4}'|awk -F',' '{print $1*1000}'

fileDate=date +"%Y%m%d_%H:%M:%S"

echo $fileDate

echo $loadnum

loadnum_ora=uptime|awk -F':' '{print $4}'|awk -F',' '{print $2}'

softirq=top -bn 1|awk '/ksoftirqd/ {print $9}'|head -1

echo -e $fileDate >>log

echo $softirq >>log

if [ $loadnum -ge “900” ]

then

echo “asdfasdf”

echo -e $fileDate >>log

/sbin/rcSuSEfirewall2 restart >> log 2>&1

else

echo -e “${fileDate}:success” >>log

fi

任務計劃

crontab -l

DO NOT EDIT THIS FILE - edit the master and reinstall.

(/tmp/crontab.XXXXWNPsHE installed on Wed Apr 9 20:10:57 2014)

(Cron version V5.0 – Id:crontab.c,v1.122004/01/2318:56:42vixieExp)

/5 * * * /opt/xx/logs/LoadRst/suseRst.sh 2>/dev/null

0 0 * * * /opt/xx/logs/Firewall_log/tar-firewall.sh >/dev/null 2>&1

解決辦法

一、關閉防火牆。 簡單粗暴，直接有效

/etc/init.d/SuSEfirewall2_init stop

/etc/init.d/SuSEfirewall2_setup stop

切記：在防火牆關閉狀態下，不要通過iptables指令（比如 iptables -nL）來檢視當前狀態！因為這樣會導致防火牆被啟動，而且規則為空。雖然不會有任何攔截效果，但所有連線狀態都會被記錄，浪費資源且影響效能並可能導致防火牆主動丟包！

二、加大防火牆跟蹤表的大小，優化對應的系統引數

1、狀態跟蹤表的最大行數的設定，理論最大值

CONNTRACK_MAX = RAMSIZE (in bytes) / 16384 / (ARCH / 32)

以64G的64位作業系統為例

CONNTRACK_MAX = 64*1024*1024*1024/16384/2 = 2097152

即時生效請執行：

sysctl –w net.netfilter.nf_conntrack_max = 2100000

或者

vi /etc/sysctl.conf

net.netfilter.nf_conntrack_max = 2100000

sysctl -p

2、其雜湊表大小通常為總表的1/8，最大為1/2。

CONNTRACK_BUCKETS = CONNTRACK_MAX / 8

同樣64G的64位作業系統，雜湊最佳範圍是 262144 ~ 1048576 。

執行狀態中檢視

sysctl net.netfilter.nf_conntrack_buckets

通過檔案 /sys/module/nf_conntrack/parameters/hashsize 進行設定。

或者新建 /etc/modprobe.d/iptables.conf，重新載入模組才生效：

options nf_conntrack hashsize=262144

3、還有些相關的系統引數sysctl -a | grep nf_conntrack可以調優（/etc/sysctl.conf ）：

net.netfilter.nf_conntrack_max = 1048576

net.netfilter.ip_conntrack_tcp_timeout_established = 3600

net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60

net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120

net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120

三、使用祼表，新增“不跟蹤”標識。如下示例更適合桌面系統或隨意性強的伺服器。因為它開啟了連線的狀態機制，方便和外部通訊。修改 /etc/sysconfig/iptables 檔案：

*raw

對TCP連線不啟用追蹤，解決ip_contrack滿導致無法連線的問題

-A PREROUTING -p tcp -m tcp –dport 80 -j NOTRACK

-A PREROUTING -p tcp -m tcp –dport 22 -j NOTRACK

-A PREROUTING -p tcp -m tcp –dport 21 -j NOTRACK

-A PREROUTING -p tcp -m tcp –dport 11211 -j NOTRACK

-A PREROUTING -p tcp -m tcp –dport 60000:60100 -j NOTRACK

-A PREROUTING -p tcp -s 192.168.10.1 -j NOTRACK

-A OUTPUT -p tcp -m tcp –sport 80 -j NOTRACK

-A OUTPUT -p tcp -m tcp –sport 22 -j NOTRACK

-A OUTPUT -p tcp -m tcp –sport 21 -j NOTRACK

-A OUTPUT -p tcp -m tcp –sport 11211 -j NOTRACK

-A OUTPUT -p tcp -m tcp –sport 60000:60100 -j NOTRACK

-A OUTPUT -p tcp -s 192.168.10.1 -j NOTRACK

COMMIT

*filter

允許ping

-A INPUT -p icmp -j ACCEPT

對本地迴路、第5張網絡卡放行

-A INPUT -i lo -j ACCEPT

-A INPUT -i eth4 -j ACCEPT

連線狀態跟蹤，已建立的連線允許傳輸資料

-A INPUT -m state –state ESTABLISHED,RELATED,INVALID,UNTRACKED -j ACCEPT

filter表裡存在但在raw裡不存在的，預設會進行連線狀態跟蹤

-A INPUT -s 192.168.10.31 -p tcp –dport 2669 -j ACCEPT

-A INPUT -j REJECT –reject-with icmp-host-prohibited

-A FORWARD -j REJECT –reject-with icmp-host-prohibited

COMMIT

或者乾脆對所有連線都關閉跟蹤，不跟蹤任何連線狀態。不過規則就限制比較嚴謹，進出都需要顯式申明。示例如下：

*raw

對TCP/UDP連線不啟用追蹤，解決nf_contrack滿導致無法連線的問題

-A PREROUTING -p tcp -j NOTRACK

-A PREROUTING -p udp -j NOTRACK

-A OUTPUT -p tcp -j NOTRACK

-A OUTPUT -p udp -j NOTRACK

COMMIT

*filter

允許ping

-A INPUT -p icmp -j ACCEPT

對本地迴路和eth1放行

-A INPUT -i lo -j ACCEPT

-A INPUT -i eth1 -j ACCEPT

只允許符合條件的連線進行傳輸資料

-A INPUT -p tcp –dport 22 -j ACCEPT

-A INPUT -p tcp –sport 80 -j ACCEPT

-A INPUT -p udp –sport 53 -j ACCEPT

-A INPUT -p udp –sport 123 -j ACCEPT

出去的包都不限制

-A OUTPUT -p tcp -j ACCEPT

-A OUTPUT -p udp -j ACCEPT

輸入和轉發的包不符合規則的全攔截

-A INPUT -j REJECT –reject-with icmp-host-prohibited

-A FORWARD -j REJECT –reject-with icmp-host-prohibited

COMMIT

效果如下圖：

四、刪除連線跟蹤模組lsmod | grep nf_conntrack，不使用連線狀態的跟蹤功能。

1、刪除nf_conntrack和相關的依賴模組，示例：

rmmod nf_conntrack_ipv4

rmmod nf_conntrack_ipv6

rmmod xt_state

rmmod xt_CT

rmmod xt_conntrack

rmmod iptable_nat

rmmod ipt_REDIRECT

rmmod nf_nat

rmmod nf_conntrack

2、禁用跟蹤模組，把它加到黑名單（/etc/modprobe.d/blacklist.conf ）：

禁用 nf_conntrack 模組

blacklist nf_conntrack

blacklist nf_conntrack_ipv6

blacklist xt_conntrack

blacklist nf_conntrack_ftp

blacklist xt_state

blacklist iptable_nat

blacklist ipt_REDIRECT

blacklist nf_nat

blacklist nf_conntrack_ipv4

3、去掉防火牆裡所有和狀態相關的配置（比如state狀態，NAT功能），示例：

*filter

允許ping

-A INPUT -p icmp -j ACCEPT

對本地迴路和第2張網絡卡放行

-A INPUT -i lo -j ACCEPT

-A INPUT -i eth1 -j ACCEPT

對埠放行

-A INPUT -p tcp –dport 1331 -j ACCEPT

對IP放行

-A INPUT -s 192.168.10.31 -j ACCEPT

允許本機進行DNS查詢

-A INPUT -p udp –sport 53 -j ACCEPT

-A OUTPUT -p udp -j ACCEPT

-A INPUT -j REJECT –reject-with icmp-host-prohibited

-A FORWARD -j REJECT –reject-with icmp-host-prohibited

COMMIT

另外，防火牆的配置檔案最好也改下，不要載入任何額外模組（/etc/sysconfig/iptables-config）：

IPTABLES_MODULES=”” # 不需要任何附加模組

IPTABLES_MODULES_UNLOAD=”no” # 避免iptables重啟後sysctl中對應的引數被重置為系統預設值

IPTABLES_SAVE_ON_STOP=”no”

IPTABLES_SAVE_ON_RESTART=”no”

IPTABLES_SAVE_COUNTER=”no”

IPTABLES_STATUS_NUMERIC=”yes”

IPTABLES_STATUS_VERBOSE=”no”

IPTABLES_STATUS_LINENUMBERS=”no”

往往我們對連線的跟蹤都是基於作業系統的（netstat / ss ），防火牆的連線狀態完全是它自身實現產生的。