MULTI：來自客戶端的錯誤源地址 - 任何一次性解決方案？
設置： 我有一個 openvpn 客戶端/伺服器設置（底部的配置文件），我
MULTI: bad source address from client [192.168.x.x], packet dropped在伺服器上收到了臭名昭著的消息。伺服器有一個公共 IP 地址，而客戶端位於 NAT 後面。先前提出的解決方案的缺點： 伺服器
client-config-dir配置中定義的目前為空。以前的文章（在此處和在 openvpn 支持論壇中）建議在 中添加一個以DEFAULT適當規則命名的文件client-config-dir，或者添加一個具有這些規則的每個使用者文件來解決問題。但是，這似乎不是一個長期的解決方案，因為這些規則是特定於客戶端位置的。所以，我可以添加一個規則來允許客戶端
192.168.x.0連接。但是，如果他們從另一個用於 NAT 的網路連接，192.168.y.0則需要一個新規則。問題：
- 可以用通用/一次性的方式編寫所需的規則嗎？
- 有人可以解釋為什麼首先會出現這個問題嗎？
伺服器配置：
port 1234 proto tcp dev tun ca ca.crt cert openvpn.crt key openvpn.key dh dh2048.pem server 10.78.96.0 255.255.255.0 keepalive 10 120 comp-lzo cipher CAMELLIA-128-CBC user nobody group nogroup persist-key persist-tun client-cert-not-required plugin /usr/lib/openvpn/openvpn-auth-pam.so login status openvpn-status.log push "redirect-gateway def1" push "remote-gateway 1.2.3.4" push "dhcp-option DNS 8.8.8.8" client-config-dir ccd verb 4客戶端配置：
ca ca.crt client dev tun proto tcp remote 1.2.3.4 1234 auth-user-pass script-security 2 keepalive 5 60 topology subnet resolv-retry infinite nobind persist-key persist-tun ns-cert-type server cipher CAMELLIA-128-CBC comp-lzo verb 4
你問：“有人能解釋一下為什麼會出現這個問題嗎？ ”
根據官方 OpenVPN FAQ 中的報告，我敢打賭這是由 OpenVPN 引擎中的路由問題引起的。
為了更好地闡明場景，讓我參考下圖：
在這裡你可以看到：
- 連接到 HEADQUARTER 內部網路 (10.0.1.0/24) 的 OpenVPN“伺服器”
- 在遠端站點上執行的 OpenVPN“客戶端”，並連接到遠端 192.168.1.0/24 網路
還
我們假設 OpenVPN 隧道已建立，並且：
- OpenVPN“伺服器”可通過其自己的tun介面訪問，地址為 10.10.0.1。另外tun介面使用的P2P地址是10.10.0.2（這個對於後面的討論很重要，所以要強調一下）
- OpenVPN“客戶端”有一個IP 為 10.10.0.2的tun介面
現在，讓我們假設：
- OpenVPN“客戶端”重新定義了它的預設網關，以便在隧道內重定向所有傳出的 IP 流量；
- OpenVPN“客戶端”啟用了 IP_FORWARDING，因此可以路由來自其內部 LAN (192.168.1.0/24) 的數據包（我強調這一點，因為這對我們的討論至關重要）。
有了這樣的場景，讓我們詳細檢查當 R_PC1 (192.168.1.2) 向 L_PC1 (10.0.1.2) 發送數據包（如回應要求）時會發生什麼：
- 離開 R_PC1 網卡後，數據包到達 OpenVPN 客戶端；
- OpenVPN 客戶端（配置為普通路由器），根據其路由表進行路由。因為它的預設網關是隧道，所以它將數據包發送到隧道；
- 數據包到達 OpenVPN 伺服器的 tun 介面。OpenVPN 將“看到”它，並且因為它（OpenVPN 伺服器）知道 10.0.1.2 是屬於其 LAN 子網的地址，所以它會將數據包從 TUN“轉發”到 LAN；
- 數據包到達 L_PC1。
所以一切都很好…
現在讓我們檢查一下 L_PC1 回复 R_PC1 的 echo-reply 會發生什麼。
- echo-reply 離開 L_PC1 NIC 並到達 OpenVPN 伺服器 LAN 介面 (10.0.1.1)；
現在，如果我們希望 OpenVPN Server 能夠訪問遠端站點，我們需要使用“靜態路由”定義路由。就像是：
route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.10.0.2請注意用作網關的 P2P 地址。
此類靜態路由將在作業系統級別執行。換句話說，作業系統需要正確地路由數據包。它的意思是這樣的：“請，所有發往 192.168.1.0/24 子網的流量都需要轉發到 OpenVPN 引擎，作業系統可以通過 P2P 地址與之通信”。多虧了這樣的靜態路由，現在…
- 數據包離開作業系統路由上下文並到達 OpenVPN。在 OpenVPN 伺服器上執行的 OpenVPN 實例。因此，此時，作業系統無事可做，所有路由（在 VPN 內）都留給 OpenVPN 伺服器軟體。
所以，現在的問題是：openvpn 伺服器軟體如何能夠決定數據包的路由，SRC_IP 為 10.0.1.2 和 DST_IP 為 192.168.1.2？
請注意，基於 OpenVPN 伺服器的配置，它對192.168.1.0/24 網路和 192.168.1.2 主機一無所知。它不是連接的客戶端。它不是本地客戶。所以？OpenVPN 也知道它不是“OS-Router”，因此它並不真正想要（並且可以….）將數據包發送回本地網關。因此，這裡唯一的選擇是引發錯誤。正是您遇到的錯誤
用常見問題解答的語言來說：“ ……它不知道如何將數據包路由到這台機器，所以它丟棄了數據包…… ”。
我們怎樣才能解決這個問題？
正如您從官方文件中看到的那樣，選項iroute完全適用於我們的範圍：
--iroute network [netmask] Generate an internal route to a specific client. The netmask parameter, if omitted, defaults to 255.255.255.255. This directive can be used to route a fixed subnet from the server to a particular client, regardless of where the client is connecting from. Remember that you must also add the route to the system routing table as well (such as by using the --route directive). The reason why two routes are needed is that the --route directive routes the packet from the kernel to OpenVPN. Once in OpenVPN, the --iroute directive routes to the specific client.所以你需要一個：
--iroute 192.168.1.0 255.255.255.0當您的 OpenVPN 客戶端連接時應用（到伺服器），例如通過伺服器上定義的臨時配置文件（client-config-dir 等）。
如果您想知道為什麼上述步驟 2)沒有發生此問題，我的理解是 OpenVPN 客戶端知道如何路由它，因為它知道 VPN 隧道是預設網關。
在 OpenVPN 伺服器上不能這樣做，因為那裡的預設網關通常不會被覆蓋。另外，考慮到您可以有一個帶有大量 OpenVPN 客戶端的 OpenVPN 伺服器：每個客戶端都知道如何訪問伺服器，但是……伺服器如何決定哪個客戶端充當未知子網的網關？
至於您的第一個問題（可以用通用/一次性的方式編寫所需的規則嗎？），很抱歉，但我沒有遇到您的問題。你能改寫提供更多細節嗎？
