深度包檢測速記
我正在嘗試開發一些可以繞過深度數據包檢查的東西，這樣我就可以將所有這些作為額外資訊或其他協議放入 HTTP 數據包中，而不是看起來像 OpenVPN 流量等。我將控制客戶端和伺服器機器，並且可以像在 OpenVPN 中一樣安全地通信，但數據包會偽裝成合法的 HTTP 流量，隱藏額外的 OpenVPN 流量。
我知道如果有人知道這種情況正在發生並且通過默默無聞的安全性不是最佳實踐，那麼數據包的完整性就會出現問題。
我的問題實際上是要問您對實施的想法。你會怎麼做？
我相信它會像這樣工作：
- 通過 iptables 強制 NIC 或通過我自己的虛擬介面的靜態路由。
- 嗅探我的介面並進行修改，以便可以更改數據包並將相關的其他流量（voip、SSL）等添加到 HTTP 的流量中，然後通過 eth0 泵入網際網路。
- 當它到達目標伺服器時，它會做相反的事情來解密流量。
- 通過伺服器處理流量並返回報告。
到目前為止，我已經找到了 stunnel 和 obfsproxy，但我不相信這是同一個概念。
這在很大程度上是一個正在進行的想法。你能告訴你的想法嗎？歡迎任何回饋。
謝謝，truex0r
出於可靠性和性能原因，在 TCP 之上執行 IP 是一個壞主意。這並不意味著您不能將 VPN 流量偽裝成 TCP 流量，但這確實意味著您需要以創新的方式處理 TCP 層。
您最好將 VPN 流量偽裝成一些已經加密的協議，例如 HTTPS。首先設置一個真正的 HTTPS 連接並讓客戶端與伺服器進行身份驗證。一旦通過身份驗證，您的 VPN 層將接管 TCP 下方 IP 層的通信，並開始使用加密的 HTTPS 有效負載發送 VPN 數據包。
在 TCP 上執行 VPN 的主要問題是，當一個封包遺失時，接收端會將所有後面的數據包排隊，直到失去的數據包被重新傳輸。解決這個問題的最簡單方法是使用普通的未修改 TCP 發送數據包，但讓連接的每一端在 IP 層接收原始加密數據包並將它們交給 VPN 層。同時接收到的數據包也會被傳遞到 TCP 層，所以你還需要一個普通的 TCP 接收器來接收流量。這樣，您將解決在 TCP 上執行 IP 的主要問題，同時仍然保留看起來像真實 TCP 流量的流量給任何中間人，因為它將由真實的 TCP 堆棧生成。
這種方法不能完全避免在 TCP 上執行 IP 的問題。如果發送端由於接收視窗或擁塞視窗填滿而導致流量停止，VPN 層將不再能夠在該方向傳輸流量。但是，任何允許您繞過此限制的方法都會以中間人可以檢測到的方式改變 TCP 連接的特性，因此此時您必須權衡 VPN 的可靠性與可檢測性。