linux核心網路實現的一些問題

1.“也就是說，餘下的包不會再通過這個表，一個一個的被NAT，而是自動地完成。這就是我們為什麼不應該在這個表中做任何過濾的主要原因”這段話說明不能在nat規則中作過濾，因為linux的連結跟蹤機制，只有每個流的第一個包才會經過nat表，並將匹配的規則設定到串連跟蹤的資料結構中，接下來的包都是直接取串連跟蹤相關資料結構的結果，而不再經過nat表，如果在nat中做了過濾，那麼只有第一個包會匹配規則，而後面的則無法匹配，也許你會問，第一個包過不去後面的能過嗎？事實上，僅舉最簡單的兩個例子，第一，udp包，第二，tcp包的第一個包過去後再設定nat的過濾規則。
2.dnat為何要在output鏈中有個鉤子。dnat路由器將世界所有的主機分為三類，第一類是自己一個網卡口一側的主機，第二類是自己所有其它網卡口一側的主機，第三類是它自己。所有非自己的請求都會經過pre-routing鏈，然後被forward，而dnat則是在pre-routing上做的，但是對於自己發出的請求，則無法經過pre-routing鏈，而是經過output鏈，因此需要在output鏈上做dnat。
3.reject target這是一個咋看上去很不錯的target，因為它避免了請求在發出後在該串連被中間路由器drop的時候源端在逾時時間內的忙等，但是其只有有限的幾種通告類型，簡單說就是tcp-reset和icmp。看看會有什麼問題，tcp-reset無法用於udp，而icmp可能會在通告給源主機的路上被丟棄。
4.queue target是一個很有趣的target，它可以在使用者空間決定如何處置這個資料包。
5.MASQUERADE target在核心中會按照一定的策略選擇源ip地址，這確實是“一定的策略”，並且核心的實現很不同，因此需要注意。
6.windows的死網關檢測機制是一種坡腳的機制，第一，該機制的演算法非常傻，第二，如果使用者自己不設定，系統為何要幫使用者佈建呢？很多時候，你會發現，在windows上配置了一條靜態路由，然而當該靜態路由的下一跳不可達的時候，用route print查看，發現該路由被莫名奇妙的改變了，下一跳被改變了...
7.unix上直接提供了pf_packet，它不但能抓包，還能讓你徹底繞開tcp/ip協議棧，包括路由，netfilter等，直接將資料發送到網卡，任何資料都行，設定你可以自己定義協議。
8.為何橋接過濾要走ip層的鉤子呢？這是因為linux主機往往同時配置成橋接器和路由器，linux橋接器可以基於三層資訊進行二層過濾。
9.linux 2.6.10以前的核心的nat模組有個問題，首先在ip_nat_fn這個終極鉤子函數中會失效校正碼，這是沒有必要的，因為很多包根本就不進行nat，只是走一下過場罷了，因此最好的辦法是僅僅對真正需要nat的傢伙們進行失效校正和的操作。不管怎樣，雖然這是一個缺陷，然而更大的弊端在於其做的不乾淨，在失效校正碼的函數中如果當前skb的使用者不止一個，那麼會複製一個skb副本出來，然後傳輸該副本，但是在複製的時候並沒有複製tso的資訊，這樣在經過了netfilter接下來的是否分段的判斷中就會誤判，skb_shinfo(skb)->tso_size為0：
if ((skb->len > dst_pmtu(skb->dst) || skb_shinfo(skb)->frag_list) && !skb_shinfo(skb)->tso_size)
    return ip_fragment(skb, ip_finish_output);
因此即使網卡有tso的能力也會分段，特別是在應用設定了mtu發現並且skb的長度超過mtu的時候還會發送icmp出錯報告，這就大大延遲了應用的回應時間。還好，2.6.10之後這個問題被修正了，在2.6.1x(x>8)之後，不需要nat的傢伙們不再失效校正碼...。唉...獨立發現了問題，卻遲了一步解決問題，自己的能力還滿意，不過速度不夠快！