出於某些私人目的，我需要使用附加資訊來豐富 HTTP 標頭（這些資訊將由 HTTP 伺服器端的應用程式處理）。基本想法是修改接收到的資料包，將其發送到目的地並且從不關心答案。交通路徑的非常簡化的方案是
+---+ +------+ +---+
| +<<-----o MDFY +<<------o |
| R | +------+ | S |
| C | | N |
| V | | D |
| o--------------------->>+ |
+---+ +---+
該問題與 TCP SEQ/ACK 編號有關。 TCP握手後，Sender發送4位元組長度的封包，該封包到達Modifier，長度變為22，然後封包到達Receiver，它發送ACK號+23，而Sender期望的是+5。這讓發送者大吃一驚，會話變得不同步。例如，當我嘗試使用netcat 進行測試時，我會看到這一點- 對於未修改的資料包，會話在資料交換後立即關閉，而對於修改的資料包，會話會長時間陳舊（實際上，我按Ctrl-C 來停止它）。
我看不到處理這種情況的簡單方法。看起來一旦中間修改，整個會話必須由修改者處理，因為發送者對序號的修改一無所知，並且將依賴他自己的號碼。這樣做會顯著影響效能並增加複雜性，因為我需要維護每個會話的狀態並修改來自雙方的每個資料包以維護 SEQ/ACK 編號。
除了編寫自己的 DPI 之外，我可能沒有看到其他方法？ :-) 任何知識、想法和建議都值得讚賞。
謝謝。
答案1
我看到的唯一更簡單的選擇是使用透明代理。
在這種情況下，客戶端將請求傳送到目標伺服器。代理伺服器捕獲請求，添加標頭並向目標伺服器建立另一個請求。目標伺服器將回應傳回給代理，然後代理將其傳回給客戶端。
這裡的缺點是伺服器看不到客戶端的原始IP位址，而是代理的IP位址。
然後，對於 TCP 級 MITM 方法，可能存在實現所需功能的工具包，因此不需要完全實作。
答案2
這看起來像是某種不成熟的 NAT；問題恰恰在於它還不成熟。
你不能只對 TCP 封包流的一個方向進行 MITM：你需要處理兩個流，正是為了處理這樣的情況（標準 NAT 通常只關心源和目標地址/端口，但原理是相同的；如果你想要在傳輸過程中破壞資料包，並且希望這種破壞對兩個端點都是透明的，您需要獲得一切正確的）。
一旦你開始考慮所有因素，很快你就會擁有成熟的 NAT：那麼就不需要重新發明輪子了，有很多實作可以讓你按照你的意願修改資料包。
實際可用的選項當然取決於所使用的作業系統和路由/防火牆軟體。