1、什麼是連接配接跟蹤？
封包過濾和連接配接跟蹤可以說是
Netfilter
提供的兩大基本功能。連接配接跟蹤可以讓Netfilter知道某個特定連接配接的狀态，運作連接配接跟蹤的防火牆稱作帶有狀态機制的防火牆，以下簡稱為狀态防火牆。狀态防火牆比非狀态防火牆要安全，因為它允許我們編寫更嚴密的規則。
無狀态防火牆通常會檢視經過它的流量，并使用諸如它的位址、來源位址和其他預定義的統計資訊。這是最簡單、最容易使用的防火牆類型；大多數基于軟體的防火牆都使用這種技術。它不像有狀态防火牆那樣安全，但它通常更快，因為它不必處理太多的資訊。有狀态防火牆不僅可以更深入地檢查資料包，消除資料包假裝不是它的樣子并可能造成損害的可能性，它還可以跟蹤傳入和傳出流量的連接配接狀态它将把資訊儲存在一個稱為狀态表的表中，這樣它就可以根據更詳細的資訊過濾和路由流量，例如資料包的大小和它在連接配接程序中的哪個部分。這使得有狀态防火牆更有效，因為它們不必為連接配接的每個部分重新檢查資料包，它們隻需檢查狀态表；這是一個更快的過程，至少出于安全目的，它們比無狀态防火牆更安全，但通常速度較慢。
2、為什麼需要連接配接跟蹤？
For example：（1）當你通過浏覽器通路一個網站(連接配接網站的
80
端口)時，預期會收到伺服器發送的源端口為
80
的封包回應，防火牆自然應該放行這些回應封包。那是不是所有源端口為
80
端口的封包都應該放行呢？顯然不是，我們隻應該放行源IP為伺服器位址，源端口為
80
的封包，而應該阻止源位址不符的封包，即使它的源端口也是
80
。總結一下這種情況就是，我們隻應該讓主動發起的連接配接産生的雙向封包通過，那麼這種功能誰來實作呢？顯然就是接下來的連接配接跟蹤。
（2）另一個例子是
NAT
。我們可以使用
iptables
配置
nat
表進行位址或者端口轉換的規則。如果每一個封包都去查詢規則，這樣效率太低了，因為同一個連接配接的轉換方式是不變的！連接配接跟蹤提供了一種緩存解決方案：當一條連接配接的第一個資料包通過時查詢
nat
表時，連接配接跟蹤将轉換方法儲存下來，後續的封包隻需要根據連接配接跟蹤裡儲存的轉換方法就可以了。
3、連接配接跟蹤依據什麼？
TCP/IP的四元組、五元組、七元組：
四元組是：源IP位址、目的IP位址、源端口、目的端口
五元組是：源IP位址、目的IP位址、協定号、源端口、目的端口
七元組是：源IP位址、目的IP位址、協定号、源端口、目的端口、服務類型以及接口索引
例如：192.168.1.1 10000 TCP 121.14.88.76 80 就構成了一個五元組。其意義是，一個IP位址為192.168.1.1的終端通過端口10000，利用TCP協定，和IP位址為121.14.88.76，端口為80的終端進行連接配接。
4、封包連接配接跟蹤狀态？
途徑
Netfilter
架構的每一個封包總是會在入口處(
PRE ROUTING
或者
LOCAL OUT
)被賦予一個連接配接跟蹤狀态。這個狀态存儲在
skb->nfctinfo
，有以下常見的取值：
- IP_CT_ESTABLISHED：這是一個屬于已經建立連接配接的封包，
Netfilter
- IP_CT_RELATED：這個狀态的封包所處的連接配接與另一個IP_CT_ESTABLISHED狀态的連接配接是有聯系的。比如典型的
ftp
ftp-data
ftp-control
RELATED
- IP_CT_NEW：這是連接配接的第一個包，常見的就是
TCP
SYN
UDP
ICMP
- IP_CT_ESTABLISHED + IP_CT_IS_REPLY：與IP_CT_ESTABLISHED類似，但是是在回複方向
- IP_CT_RELATED + IP_CT_IS_REPLY：與IP_CT_RELATED類似，但是是在回複方向
5、連接配接跟蹤具體分析舉例
（1）TCP
一個TCP連接配接是經過三次握手協商連接配接資訊才建立起來的。整個會話由一個SYN包開始，然後是一個 SYN/ACK包，最後是一個ACK包，此時，會話才建立成功，能夠發送資料。最大的問題在于連接配接跟蹤怎樣控制這個過程？
首先，在/proc/net/ip_conntrack裡，可以看出，SYN_SENT狀态被設定了，這說明連接配接已經發出一個SYN包，但應答還沒發送過 來，這可從[UNREPLIED]标志看出。
tcp 6 117 SYN_SENT src=192.168.1.5 dst=192.168.1.35 sport=1031 \
dport=23 [UNREPLIED] src=192.168.1.35 dst=192.168.1.5 sport=23 \
dport=1031 use=1
接下來，在/proc/net/ip_conntrack裡，可以看出，已經收到了相應的SYN/ACK包，狀态也變為SYN_RECV，這說明最初發出的SYN包已正确傳輸，并 且SYN/ACK包也到達了防火牆。 這就意味着在連接配接的兩方都有資料傳輸，是以可以認為兩個方向都有相應的回應。
tcp 6 57 SYN_RECV src=192.168.1.5 dst=192.168.1.35 sport=1031 \
dport=23 src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 \
use=1
最後，在/proc/net/ip_conntrack裡，可以看出，現在我們發出了三步握手的最後一個包，即ACK包，連接配接也就進入ESTABLISHED狀态了。再傳輸幾個資料 包，連接配接就是[ASSURED]的了。
tcp 6 431999 ESTABLISHED src=192.168.1.5 dst=192.168.1.35 \
sport=1031 dport=23 src=192.168.1.35 dst=192.168.1.5 \
sport=23 dport=1031 use=1
（2）UDP
UDP連接配接是無狀态的，因為它沒有任何的連接配接建立和關閉過程，而且大部分是無序列号的。以某個順序收 到的兩個資料包是無法确定它們的發出順序的。但核心仍然可以對UDP連接配接設定狀态。接下來就看看netfilter是如何跟蹤UDP連接配接的，以及conntrack的相關記錄。
首先，看看第一個UDP包發出後的conntrack記錄，從前兩個值可知，這是一個UDP包。第一個是協定名稱，第二個是協定号，第三個是此狀态的生存時間， 預設是30秒。接下來是包的源、目位址和端口，還有期待之中回應包的源、目位址和端口。[UNREPLIED]标 記說明還未收到回應。
udp 17 20 src=192.168.1.2 dst=192.168.1.5 sport=137 dport=1025 \
[UNREPLIED] src=192.168.1.5 dst=192.168.1.2 sport=1025 \
dport=137 use=1
然後，一旦收到第一個包的回應，[UNREPLIED]标記就會被删除，連接配接就被認為是ESTABLISHED的，但在記錄裡 并不顯示ESTABLISHED标記。相應地，狀态的逾時時間也變為180秒了。在本例中，隻剩170秒了，10秒後， 就會減少為160秒。有個東西是不可少的，雖然它可能會有些變化，就是前面提過的[ASSURED]。要想變為 [ASSURED]狀态，連接配接上必須要再有些流量。
udp 17 170 src=192.168.1.2 dst=192.168.1.5 sport=137 \
dport=1025 src=192.168.1.5 dst=192.168.1.2 sport=1025 \
dport=137 use=1
最後， 可以看出來，[ASSURED]狀态的記錄和前面的沒有多大差别，除了标記由[UNREPLIED]變成[ASSURED]。如 果這個連接配接持續不了180秒，那就要被中斷。180秒是短了點兒，但對大部分應用足夠了。隻要遇到這個連接配接 的包穿過防火牆，逾時值就會被重置為預設值，所有的狀态都是這樣的。
udp 17 175 src=192.168.1.5 dst=195.22.79.2 sport=1025 \
dport=53 src=195.22.79.2 dst=192.168.1.5 sport=53 \
dport=1025 [ASSURED] use=1
6、總結
連接配接跟蹤是
Netfilter
提供的一項基本功能，它可以儲存連接配接的狀态。使用者可以為不同狀态的連接配接的封包制定不同的政策；
連接配接跟蹤在封包進入
Netfilter
的入口将資訊記錄在封包上，在出口進行
confirm
.确認後的連接配接資訊可以影響之後的封包；
連接配接跟蹤的資訊主要包括基本的描述連接配接的
tuple
以及各協定的私有資訊。
本文主要參考其它文章進行的摘抄和總結，希望可以帶來更直覺的幫助，如有不當，請留言指正，謝謝！
https://segmentfault.com/a/1190000019605260
https://blog.csdn.net/weixin_34223655/article/details/92005628
https://blog.csdn.net/x356982611/article/details/82462343
![linux-svn解除安裝與安裝[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)