路由器進行NAT地址轉換時，如何避免可能出現的如下錯誤？

12-30

路由器在進行NAT地址轉換時，改變了源IP，這勢必需要重新計算TCP校驗和。
如果，在NAT地址轉換這個過程中，路由器硬體由於外界的干擾或損壞，導致在這個過程中，數據包的數據部分出現了差錯（比如其中的一位或幾位數據出現翻轉）
這樣一來，NAT過程變成了 1.源IP改變 2.數據內容改變
接下來，重新計算、填寫TCP校驗和
此時，校驗和是根據替換後的源IP和已經被改變的數據內容來計算出來的

當這個數據包最終傳送到目標主機時，目標主機雖然驗證校驗和通過，但實際上數據部分已經發生了變化（此時的校驗和本身就是路由器根據已經被改變的數據內容計算出來的），已經不是源主機最初所發出的內容了。
----------------------
我想問一下，以上這種情況是否會發生？或者網路中還有什麼機制能預防或檢測出這種錯誤的發生？

你的擔心是合理的，符合科學發展觀的精神。

當NAT時，一般是 IP + Port 一起發生改變，所以IP + TCP 的CRC都會重新計算，如果這個時候發生了一些非常罕見的硬體故障，重新計算的TCP的CRC到達目的地，CRC校驗通過，無法校驗出原始數據其實已經改變，提交給應用程序，那完全要靠應用程序來鑒別數據的真偽了。

對於這種情況，源主機的應用程序可以將數據做一個MD5 hash，附在數據的末尾，等到達目的主機，也對接收的數據先計算MD5 hash，如果兩個hash完全一致，那可以放心地認為數據是可靠的。

以上實現只能解決非人為篡改數據，如果有中間人篡改原始數據、修改TCP CRC、修改 Application MD5 Hash，則目的主機一樣會被欺騙。

對於後者使用基於SSL的HTTPS更合理。

1、是否有可能出現這種錯誤。

是。

2、如何避免？

自行校驗數據完整性。

其實提問者已經進入了一個誤區。

你要知道任何設備都可能出現問題，任何程序都可能出現問題。

為什麼我們世界沒有大亂，你的郵件為什麼沒有發到我的郵箱？

因為任何小概率的錯誤我們都可以通過各種手段控制在一個極小的範圍之內。

我們要確認的是這個出問題的概率是不是可接受的。

而不是去糾結哪些地方可能出問題。

所有，所有地方都可能出問題。

譬如說你的程序不會出問題嗎？你的網卡驅動不會出問題嗎？

從計算機可靠計算的角度看，隨機位翻轉無藥可救。但，在現實生活中它有特點我們可以利用——那就是這事概率極低。

所以，只要用一些低密度的額外校驗即可檢測此類錯誤，例如增加額外的MD5，或者Parity Code，甚至奇偶校驗即可。

但是，這最多能做到檢測。如何避免呢？有一種方法就是把校驗和改為ECC，同時為了針對NAT過程的出錯，額外增加地址和埠信息以外的數據的ECC。這樣，校驗信息可以幫助修復至少一個位的翻轉，就避免了錯誤發生。但這就涉及硬體改變了——這不是現有網路幀處理硬體能輕易搞定的事。

而且，這不是完全的避免。NAT過程本身改變的信息，將沒有好辦法檢測是否有錯。這就回到了計算機可靠計算的領域。要避免的話，除了針對位翻轉的原因做保護之外，就只能使用冗餘了。

你的擔心是合理的，但是在實際路由器實現中是不存在的。

因為，路由器為了效率考慮不會在NAT之後對所有數據重新計算校驗和。

IP頭校驗和和TCP/UDP(ICMP)頭校驗和都是「取補」校驗，所以只需要計算轉換前的地址和轉換後地址的差，然後加入原來的校驗和即可。

這樣，錯誤的數據自然會在目標主機端被校驗和檢查發現。

樓主糾結於非常非常小概率的錯誤，不如想想太陽黑子的影響

去讀一下nat協議吧

會發生。

所以可靠的路由器（企業級或更高等級）會採用ECC內存減少這個概率。

是可能的，但是ip層上面還有傳輸層、應用層，每層都可以自己獨立做校驗、使用更強的散列演算法，就能極大的降低出錯概率，低到可以忽略。

你這裡考慮的是低概率意外故障，但現實中有時候黑客人為攻擊網路，篡改數據，導致的安全問題比這嚴重的多。然而只要網路協議各層，尤其是應用層適當設計安全方案，就能有效避免人為或意外的數據不一致。

現實中的一個例子。在有些網站，特別是國外網站，下載文件，特別是大文件時，往往網站會在頁面上文件的旁邊放一個散列值或散列文件，一般是md5或sha1之類的。你把文件下下來以後呢，可以自己找個散列值計算軟體，算一下你下下來的這個文件。如果計算結果跟網站上公布的值一致，那就可以認為你這個文件跟網站上的原始文件是一模一樣的。如果不一致，那麼你的這個文件肯定跟原始的不一樣。這時候怎麼辦呢？很簡單，重新下載。

可以看出，基於普通散列的防篡改技術太簡單粗暴，很多場景需要更智能的技術——糾錯碼。糾錯碼跟散列類似，核心原理也是信息冗餘，但是冗餘度一般高於散列。接收方收到數據後，不但能檢測數據完整性，還能根據糾錯碼自動恢復少量出錯的數據。

傳輸層不提供可靠傳輸。

數據發送時加個校驗和再發。

這樣tcp校驗和通過後，自己在計算下你收到的數據的校驗和。

校驗和有多個，IP層有校驗和，TCP也有校驗和，UDP也有校驗和，這看一下協議結構就很顯然了。假如發生了你說的情況，那麼在終端那裡過了IP層的校驗，但過不了TCP的校驗，於是TCP丟包，等對端重傳。UDP就沒辦法了。如果你要說路由器的故障問題能那麼巧妙的改了裡面的數據，而又不引起TCP的校驗失效，那就只能依賴應用層了，比如各種摘要演算法。

檢驗校驗和又不是只有一個，不要混為一談哈

我理解校驗和不同於crc。

可以基於修改而重新計算，而非基於全部數據。

比如tcp埠由1變2，那校驗和就由3變4好了。這樣你說的錯誤就迎刃而解了。

另外，你說的問題其實不僅僅是nat有。本身校驗和的能力就非常弱，隨隨便便一個物理信號翻轉都可能造出類似問題且校驗和校驗不出？腫么辦？

一，鏈路層會有crc校驗，解掉大部分問題。當然鏈路層校驗在節點處失效，所以解不了你這個問題。

那隻能靠上層解決了。

二，這種問題概率極小，可以忽略不計。重要傳輸業務設計上要自己加校驗，比如crc，hash演算法。最保險的還是tls。

是不是可以理解為，路由器要準備做nat之前tcp包的數據段就由於某種原因出錯了？這樣的話在轉換源IP之前檢查一下原tcp包的校驗如何？如果這時候已經對不上了，就說明這個包已經出錯了，沒必要再轉換源ip以及重新計算校驗和了。