OpenVPN 使用自定義腳本修改傳入流量或有效負載
我最近使用 Dnsmasq 作為 DNS 設置 OpenVPN，並想做一些我似乎找不到任何資訊的事情。
這是我目前的理解，也是基於我目前在我的伺服器上設置的。
A. 客戶端連接到 OpenVPN，比如通過電話
B. 客戶發送流量，即打開一個網站，比如 YouTube
C. OpenVPN 伺服器接受請求。
D. 將請求轉發到目標伺服器，即 YouTube。
E. YouTube 做出回應。
F. OpenVPN 將響應從 A 轉發給客戶端
當然，上面的內容過於簡單化了。
我想做的事？
在階段 C 和 D 之間，如在 OpenVPN 接受請求（或從目標伺服器即 D->C 獲得響應）之後，我想處理實際數據。
例如，一個典型的案例。
在 D 和 C 之間，我想將有效負載傳遞給例如 Python 腳本，在將有效負載打包並發送給客戶端之前，將網頁 html 中的所有“我愛你”文本更改為“我討厭你”。
問題
OpenVPN 是否有任何形式的“生命週期掛鉤”，我基本上可以在其中收聽和更改請求的有效負載？
我了解來自 OpenVPN 的任何入站或出站連接都是“諾克堡”安全的。我對響應有效負載裸露在伺服器上的點感興趣。
我有哪些可用選項？我是否需要使用不同的軟體包/軟體來建議達到這樣的結果？
您的想法不可行有幾個原因：
1)
據我所知，OpenVPN 本身沒有一項功能可以在轉發之前將數據從 VPN 連接傳輸到自定義程序。
快速參考：查看 TCP/IP 在 OSI 堆棧中的使用位置。
OpenVPN 位於 OSI 堆棧的第 3 層（網路層），而 TCP 包屬於第 4 層（傳輸層）。
您的問題僅出於這個原因，超出了 OpenVPN 想要實現的範圍。
您唯一可以操作的是當客戶端連接到伺服器或斷開連接時會發生什麼。
這些情況可以通過以下設置在您的伺服器配置文件中定義：
# client connected to VPN server client-connect "/script/client_connect.sh" # client disconnected from VPN server client-disconnect "/script/client_disconnect.sh"您的自定義腳本可用的所有環境變數都可以在此處獲得：
但本質上，您可以監控的唯一資訊是使用哪個客戶端證書連接到伺服器以及分配給客戶端的 IP 地址，然後根據誰連接以及再次斷開連接時的操作在伺服器上進行一些自定義邏輯。
一種典型的設置可能是實現動態 DNS 伺服器端或執行一些自定義路由，例如故障轉移路由，具體取決於哪個 VPN 連接已啟動。
2)
參考來自WikiPedia的 IPv4 數據包圖：
本質上，您要做的是根據源地址或目標地址操作數據欄位。
這也稱為中間人攻擊。
正如您發現的那樣，通過偵聽 OpenVPN 介面很難做到這一點，因為所有內容都是加密的。發生的情況是，發往 Internet 的 IPv4 數據包被封裝在另一個 IPv4 數據包中，該數據包發往 OpenVPN 伺服器。
封裝後的 IPv4 數據包儲存在上圖中的數據欄位中。
它是從 VPN 伺服器轉發到 Internet 的解封裝數據包。
但是有一個警告：
我認為 VPN 客戶端沒有公共IP 地址。這意味著在與 Internet 上的任何主機聯繫之前，會進行 NAT 轉換，並將源地址重寫為 VPN 伺服器的源地址。
同樣，當主機回復一個答案時，我們的目標 IPv4 地址與 VPN 伺服器相同。
這意味著為了操作數據欄位，我們需要跟踪
network address translation table（也稱為 NAT）中正在使用哪些埠。使用的埠通常是動態的，因為多個 VPN 客戶端可以通過 VPN 和 NAT 連接到 Internet，並且每個 TCP 會話（郵件、Web、ssh 等等）都使用不同的埠。
因此，如果您想操縱解密的 TCP 數據包，它必須在解密之後，但在它在 NAT 中轉換之前發生。
理論上您可以使用 攔截數據包
iptables，但是當 VPN 和 NAT 位於同一台機器上時，這並非易事。另一種方法是直接攻擊加密的 OpenVPN 流量，因為您控制 OpenVPN 伺服器意味著您還可以控制伺服器和客戶端都使用哪些證書和私鑰。
作為一種經典的中間人攻擊，這是可行的。我不知道這是怎麼做到的。:-)
…但這引出了我的最後一個論點：
3)
Internet 上的大多數流量都是 TLS 加密的。
因此，即使在您解密 OpenVPN 流量之後，您也必須通過另一層加密才能操縱數據欄位的內容。
這部分比僅僅攻擊加密的 OpenVPN 流量更難攻擊，因為您無法控制用於會話的加密密鑰。
即使您嘗試解密 TLS 流量並重新加密內容，因此對於最終使用者來說，加密流量確實來自 YouTube 或其他任何東西，但它仍然是徒勞的，因為您用於加密 https 流量的證書不是受最終使用者電腦上的瀏覽器信任。
僅此一項就使您的中間人攻擊無效。
現在，這已接近您問題的完整答案。
攻擊 TCP 會話還有其他角度，但現在我們將其作為一個高級領域，屬於一個充滿安全專家的論壇。
那部分遠遠超出了我的資格。:-)
