IP分片

【寫在前面】：

1，該案例是一個特殊應用、特殊環境下的疑難故障案例，給我們的啓示是在故障現場，我們需要充分了解清楚跟故障有關的應用特性，比如此案例中的加密機的工作機制；

2，該案例涉及到以下知識點：IP報頭校驗和、IP分片（請參考本博《IP分片》一文）、防火牆對分片報文的處理等；

3，此案例在整理文檔時，應該簡化了很多的分析測試過程，我按照我的理解做一些梳理：

（1），IP報頭校驗和只跟IP報頭有關，跟IP封裝的數據無關，因此，如果原文中的描述的“收到報文是否進行校驗和檢查”是指IP報頭檢驗和的話，那麼應該不會存在校驗和錯誤而被防火牆丟棄的問題，如果是指TCP校驗和或UDP檢驗和的話，那麼，每個來自於加密機的報文其TCP或UDP校驗和都是錯誤的（因爲多了33字節），因此防火牆肯定會直接丟棄這個報文，根本不存在文檔中描述的在防火牆轉發接口抓到1460字節數據包的情況；

（2），防火牆不對收到的報文進行校驗和計算，那麼這個報文才會進入防火牆的內核處理流程，因爲來自於加密機的報文是IP分片報文，因此防火牆會對此分片報文進行處理（選擇直接轉發分片報文還是重組後匹配策略再轉發），如果防火牆直接轉發，則沒什麼問題，如果是重組轉發，這裏就存在一個問題：防火牆能否完成這個報文的重組？因爲IP分片的重組是根據IP報頭中的相關信息來完成的，其中非常重要的一個參數就是分片偏離量，這個值決定了分片報文在原始報文中的位置，而在這個故障環境下，每個報文都被加密機在尾部添加了只有加密機能夠識別的特徵碼，防火牆並不能識別，那麼防火牆在重組這些報文的時候，如何處理正常分片報文跟前一分片報文尾部添加的33字節部分的重疊呢？這是值得思考的。如是覆蓋33字節的尾部識別碼，則到達對端加密機後，加密機會丟棄這個報文，並不是因爲文中所說的“認爲加密數據被篡改”，而是由於被覆蓋了數個識別碼導致接收端加密機無法正常識別加密報文（篡改的識別是通過校驗和得到的，接收方根據報頭信息可以計算出校驗和，也就是說只要報頭信息沒錯，校驗和就不會錯，而防火牆在重組完畢後轉發前肯定會重新計算轉發報文的報頭校驗和）。

4，各位讀者兄弟根據自己的理解，自由參考我上面的分析和下面的案例原文，歡迎探討和交流。

【原文全文】：

一、拓撲

二、環境描述

該拓撲使用的VPN鏈路是某公司的產品，該VPN在做加密處理時，TCP頭和IP頭都不做加密，只對數據區做加密，通過在加密機的抓包，發現加密機把所有MTU大於1300的數據包做了分片處理，並且在所有包的末尾加入自己的N字節加密識別碼，這樣從加密機發出的數據包MTU值最大1333，對於大於1333的報文（如1460）的數據包加密機都是分2個包進行傳送，在沒接防火牆時一切正常，接入防火牆後導致訪問不正常；
拓撲中客戶端172.16.1.22在訪問服務器172.16.1.33時，服務器迴應的MTU值1460數據包被服務器端加密機拆成2個包（第一個包1300），並在每個包的末尾加入33位，而防火牆在接收時將兩個包合併轉發，具體表現爲防火牆接收口（接服務器端加密機）收到的報文數據長度是1333，而轉發口（接客戶端加密機）轉發的報文數據長度是1460，這樣客戶端加密機就認爲加密數據被篡改，導致VPN加密通訊錯誤；

三、分析過程與解決方式

1、由於加密機的特殊性，所以加密封包後的數據在通過防火牆時，會被認爲是錯誤報文，
解決方法：將防火牆“選項設置”---“安全設備系統參數”---“系統參數開關”下的“收到報文進行是否效驗和檢查”選項取消，如下圖所示

2、加密機對大於1300的數據包做分片處理，到防火牆時，發現數據是分片包，防火牆又給重組後轉發，導致對端加密機認爲數據被篡改，不再對該數據包做解密處理；
解決方法：啓用防火牆中的分片處理，將經過防火牆的數據都不做分片重組處理；
3、以上兩點設置好後，TCP報文可以正常通訊，但UDP報文（如視頻報文）由於數據量大的緣故在通過防火牆時，經常丟包；
解決方法：研發根據該問題給了一個特殊的補丁，專門解決UDP報文處理的，只要打上該補丁即可；

四、總結

1、將防火牆“選項設置”---“安全設備系統參數”---“系統參數開關”下的“收到報文進行是否效驗和檢查”選項取消；
2、啓用防火牆中的分片功能，將經過防火牆的數據都不做分片重組處理；
3、打上專用的補丁；

閱讀全文>>

標籤: ip分片天融信分片防火牆重組校驗和 IP報頭檢驗和

評論(0)引用(0)瀏覽(850)

IP分片(IP Fragment)

作者：易隱者發佈於：2012-9-3 22:22 Monday 分類：網絡分析

爲什麼要分片

不同的鏈路類型能夠支持的最大傳輸單元值（MTU: Maxitum Transmission Unit）主要是由相關RFC文檔規定的，常見的以太網鏈路的MTU值爲1500，如果需要轉發的IP報文超出其轉發接口的MTU值，則在轉發該報文之前，需要將其分片，分爲多個適合於該鏈路類型傳輸的報文，這些分片報文在到達接收方的時候，由接收方完成重組。

各種常見鏈路類型的MTU值如下圖所示：

報文的分片和重組

我們先來看一下分片的過程，爲了簡單起見，我就用《TCPIP詳解卷一》第11章《UDP：用戶數據報協議》中關於IP分片的案例，應用進程將1473字節應用字段交給UDP處理，UDP加上8字節的UDP報頭之後，交給IP層處理，IP層在轉發之前，發現該報文長度超出轉發接口的MTU，因此需要分片，分爲兩個IP分組，如下圖所示：

從上圖可以看出原始的IP報文經過分片後，只有第一個分片報文是帶有四層信息的，後續報文均不帶四層信息，爲做直觀展示，我找了一個實際環境下抓取的分片報文，如下圖所示：

這是分片的第一個報文，我們可以看到該報文IP層封裝的上層協議爲ICMP協議，這是一個ping報文（上層協議信息），我們再來看一下後續分片報文的解碼：

這是分片後續報文，我們能看到封裝的是ICMP協議，但是封裝的上層協議的具體信息就無法看到了。

IP數據報被分片之後，所有分片報文的IP報頭中的源IP、目的IP、IP標識、上層協議等信息都是一樣的（TTL不一定是一樣的，因爲不同的分片報文可能會經過不同的路由路徑達到目的端），不同的地方在於分片標誌位和分片偏移量，而接收方正是根據接收到的分片報文的源IP、目的IP、 IP標識、分片標誌位、分片偏移量來對接收到的分片報文進行重組。

接收方根據報文的源IP、目的IP、IP標識將接收到的分片報文歸爲不同原始IP數據報的分片分組；分片標誌中的MF位（More Fragment）標識了是否是最後一個分片報文，如果是最後一個分片報文，則根據分片偏移量計算出各個分片報文在原始IP數據報中的位置，重組爲分片前的原始IP報文。如果不是最後一個分片報文，則等待最後一個分片報文達到後完成重組。

分片帶來的問題

1，分片帶來的性能消耗

分片和重組會消耗發送方、接收方一定的CPU等資源，如果存在大量的分片報文的話，可能會造成較爲嚴重的資源消耗；
分片對接收方內存資源的消耗較多，因爲接收方要爲接收到的每個分片報文分配內存空間，以便於最後一個分片報文到達後完成重組。

2，分片丟包導致的重傳問題

如果某個分片報文在網絡傳輸過程中丟失，那麼接收方將無法完成重組，如果應用進程要求重傳的話，發送方必須重傳所有分片報文而不是僅重傳被丟棄的那個分片報文，這種效率低下的重傳行爲會給端系統和網絡資源帶來額外的消耗。

3，分片攻擊

黑客構造的分片報文，但是不向接收方發送最後一個分片報文，導致接收方要爲所有的分片報文分配內存空間，可由於最後一個分片報文永遠不會達到，接收方的內存得不到及時的釋放（接收方會啓動一個分片重組的定時器，在一定時間內如果無法完成重組，將向發送方發送ICMP重組超時差錯報文，請大家參考本博客《ICMP重組超時》一文），只要這種攻擊的分片報文發送的足夠多、足夠快，很容易佔滿接收方內存，讓接收方無內存資源處理正常的業務，從而達到DOS的攻擊效果。

4，安全隱患

       由於分片只有第一個分片報文具有四層信息而其他分片沒有，這給路由器、防火牆等中間設備在做訪問控制策略匹配的時候帶來了麻煩。
       如果路由器、防火牆等中間設備不對分片報文進行安全策略的匹配檢測而直接放行IP分片報文，則有可能給接收方帶來安全隱患和威脅，因爲黑客可以利用這個特性，繞過路由器、防火牆的安全策略檢查對接收方實施攻擊；
       如果路由器、防火牆等中間設備對這些分片報文進行重組後在匹配其安全策略，那麼又會對這些中間設備的資源帶來極大的消耗，特別是在遇到分片攻擊的時候，這些中間設備會在第一時間內消耗完其所有內存資源，從而導致全網中斷的嚴重後果。

基於以上原因，很多應用程序都儘量避免分片的產生，其通過將IP報文的分片標誌中的DF位（Don’t Fragment）置一來實現，而這可能給應用帶來一些難以預料的麻煩。下一篇我將介紹端系統如何處理這種狀況，請大家關注。

分片補充

1，分片既有可能發生在端系統（發送主機）上，也可能發生在轉發報文的路由器、防火牆等中間系統上。
2，分片只發生在轉發出接口上。

跟分片有關的案例

後續我會在本博客裏添加一些跟分片有關的案例，有興趣的同學可關注。

閱讀全文>>

標籤: ip分片重組超時 IP標識 icmp差錯分片 ip fragment IPID UDP 分片攻擊分片偏移量 DF位 MF位 MTU 重組 fragment ICMP