我最近使用 Dnsmasq 設定 OpenVPN 作為 DNS，並想做一些我似乎找不到任何資訊的事情。
這是我目前的理解，也是基於我目前在伺服器上設定的內容。
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
您的想法不可行，原因如下：
1）
據我所知，OpenVPN 本身沒有一項功能可以在轉送之前將資料從 VPN 連線傳輸到自訂進程。
如需快速參考：查看 OSI 堆疊中 TCP/IP 的使用位置。
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）
請參考此 IPv4 封包圖維基百科：
從本質上講，您想要做的是根據來源位址或目標位址來操作資料欄位。
這也稱為中間人攻擊。
正如您所發現的，透過監聽 OpenVPN 介面很難做到這一點，因為所有內容都是加密的。發生的情況是，發送到網際網路的 IPv4 封包被封裝在另一個發送到 OpenVPN 伺服器的 IPv4 封包中。
封裝後的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 會話，但現在我們將其擴展到屬於充滿安全專家的論壇的高級領域。
這部分遠遠超出了我的資格。 :-)