我觀察到一種我不太理解的奇怪行為。所以我設定了一個 OpenVPN 連接，如下圖所示。 （這是一個 TUN 和客戶端到客戶端設定）。我的想法是針對這種情況下的 ping 路由： 我的 openvpn 連接
from client: 192.168.200.102 to LAN: 10.198.0.16
一般來說，這個 ping 成功並不奇怪，但就我的理解而言，萬一我將伺服器上的 iptables 設定更改為
-P FORWARD DROP
然後甚至
net.ipv4.ip_forward = 0.
使用上述設置，流量永遠不會到達目的地。儘管流量成功，但它永遠不會到達 LAN 介面。問題是我看不到到達 LAN 介面 eth0 10.198.0.16 的流量（透過執行 tcpdump 資料網路封包分析器）。更重要的是，tun 介面似乎是在自我應答流量，就像 LAN IP 綁定到 tun 介面一樣，如下所示：
sudo tcpdump -i tun0 tcpdump: 16:34:21.391381 IP 192.168.200.102 > 10.198.0.16: ICMP echo request, id 14, seq 1885, length 64 16:34:21.391514 IP 10.198.0.16 > 192.168.200.102: ICMP echo reply, id 14, seq 1885, length 64
這裡發生了什麼事？據我了解，來自客戶端的請求會發送到伺服器上的 tun 接口，最終會被轉發由內核到 eth0，我說得對嗎？通常透過運行：sudo tcpdump -i tun0或可以看到它嗎sudo tcpdump -i eth0？
為什麼我對這件事如此挑剔，是因為我認為如果沒有辦法實施規則來阻止客戶端存取伺服器上的 LAN，就會存在安全風險。我在這裡缺少什麼，是否有一個 OpenVPN 進程本身將封包轉發到 eth0 介面（用於客戶端到客戶端配置）？
為了讓您更好地幫助我解決問題，我在下面附上了一些診斷資訊。
對於伺服器
ip addr`1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether b8:27:eb:5c:a6:e6 brd ff:ff:ff:ff:ff:ff inet 10.198.0.16/24 brd 10.198.0.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::ba27:ebff:fe5c:a6e6/64 scope link valid_lft forever preferred_lft forever 3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether b8:27:eb:09:f3:b3 brd ff:ff:ff:ff:ff:ff 4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500 link/none inet 192.168.200.1/24 scope global tun0 valid_lft forever preferred_lft forever inet6 fe80::87cd:fedd:92fc:cde/64 scope link stable-privacy valid_lft forever preferred_lft forever
`
ip routedefault via 10.198.0.1 dev eth0 proto static 10.198.0.0/24 dev eth0 proto kernel scope link src 10.198.0.16 192.168.200.0/24 dev tun0 proto kernel scope link src 192.168.200.1 192.168.178.0/24 via 192.168.200.1 dev tun0 scope linkserver openvpn.conftls-server mode server dev tun local 10.198.0.16 proto tcp-server port 1234 user openvpn group openvpn ca /etc/openvpn/cacert.pem cert /etc/openvpn/servercert.pem key /etc/openvpn/serverkey dh /etc/openvpn/dh2048.pem ifconfig-pool 192.168.200.2 192.168.200.103 255.255.255.0 client-config-dir /etc/openvpn/ccd ifconfig 192.168.200.1 255.255.255.0 keepalive 10 120 comp-lzo client-to-client push "topology subnet" topology "subnet" log /var/log/openvpn.log
對於客戶
ip addr1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 link/ether 38:af:d7:a0:52:ec brd ff:ff:ff:ff:ff:ff 3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:28:f8:8d:1c:6f brd ff:ff:ff:ff:ff:ff inet 192.168.178.79/24 brd 192.168.178.255 scope global dynamic noprefixroute wlp2s0 valid_lft 859868sec preferred_lft 859868sec inet6 2a0a:a540:d54:0:bd79:eb10:5e26:548a/64 scope global temporary dynamic valid_lft 7190sec preferred_lft 3590sec inet6 2a0a:a540:d54:0:6086:b044:dff:2694/64 scope global dynamic mngtmpaddr noprefixroute valid_lft 7190sec preferred_lft 3590sec inet6 fe80::ad5c:6e18:87fa:dff4/64 scope link noprefixroute valid_lft forever preferred_lft forever 4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100 link/none inet 192.168.200.102/24 brd 192.168.200.255 scope global tun0 valid_lft forever preferred_lft forever inet6 fe80::5dfc:6b3a:3c4d:e9a4/64 scope link stable-privacy valid_lft forever preferred_lft foreverip routedefault via 192.168.178.1 dev wlp2s0 proto dhcp metric 600 169.254.0.0/16 dev wlp2s0 scope link metric 1000 10.198.0.0/24 via 192.168.200.1 dev tun0 192.168.200.0/24 dev tun0 proto kernel scope link src 192.168.200.102 192.168.178.0/24 dev wlp2s0 proto kernel scope link src 192.168.178.79 metric 600client openvpn.confdev tun client nobind remote 11.22.33.44 proto tcp port 1234 ca /etc/openvpn/cacert.pem cert /etc/openvpn/user_cert.pem key /etc/openvpn/user comp-lzo verb 3 keepalive 10 120 log /var/log/openvpn.logccd for clientiroute 192.168.178.0 255.255.255.0
答案1
VPN 和網路其餘部分之間的流量當然會通過tun0。對於這種流量，FORWARD鏈會像往常一樣進行諮詢，您可以控制誰可以連接到哪裡。如果ip_forward不啟用，則不會轉送流量。
當client-to-client不使用時，客戶端之間的流量使用相同的路徑：它從tun0介面出現在伺服器作業系統中，使用作業系統路由表正確路由，穿過防火牆，唯一的區別是它確定目的地在後面tun0，因此數據包是通過它出去。
它的效率不是很高，因為 OpenVPN 程序位於使用者空間，而 tun0 位於核心空間，這會導致每個資料包至少發生兩次上下文變更。
然而，當client-to-client使用 時，客戶端之間的封包不會出現在 上，並且不會諮詢tun0伺服器的防火牆鏈，並且控制不會影響它們的轉送。 OpenVPN 進程本身成為一個路由器，有自己的路由表，獨立於託管作業系統。您可以使用管理介面的命令查看它或將其轉儲到狀態檔案中。您可以使用指令控制此「路由器」內的路由（我相信它代表「內部路由」），該指令僅在客戶端的檔案或腳本產生的動態設定中有效。FORWARDip_forwardstatusiprouteclient-config-dir
最簡單的方法就是不要將 VPN 視為特殊的東西。一旦建立了隧道，就不用管它了，它現在只是每台電腦（伺服器和客戶端）中的一個附加常規接口，所有這些接口都連接到某個常規簡單路由器。並考慮常用的路由和防火牆。
我終於注意到你 ping 的地址VPN 伺服器本身儘管分配給其他介面。這個數據包是不會被轉發無論如何，因為它的目的地是伺服器本身，所以ip_forward不會影響該資料包的處理方式，並且它正在穿越INPUT防火牆鏈，並且回復將穿越OUTPUT（例如，FORWARD如果它們不是注定要發送到系統本身，則不會像它們那樣進行連結）。資料包將從 進入系統tun0（並且會在那裡看到），但您不會在 上看到它，eth0因為它不會被發送走。它將在本地進行處理。回覆也是同樣的道理。
（對於與路由相關的代碼）位址分配在系統上的哪個位置（哪個介面）或您使用系統的哪個位址來存取它並不重要。重要的是它是否屬於系統。
相關的安全問題是，有些人認為，如果他們將服務綁定到分配給某個介面的某個 IP 位址，他們就會切斷透過其他介面對該服務的存取。這是錯誤的。如果位於其他介面後面的其他系統具有到綁定服務的 IP 的路由，它們仍然將能夠訪問該服務。這不是確保服務安全的正確方法；正確的防火牆設定是。
另一個相關問題是，有些人使用ping -I <local-address> <address-to-ping>或 ，ping -I <interface> <address-to-ping>他們認為直接選擇將發出哪個介面 ping。再說一次，這是錯的。這樣你就只能選擇哪一個來源位址ping 會有，但沒有發送它們的介面；路由代碼將嚴格根據僅基於數據包的目標地址的路由表選擇接口（我假設沒有完成 VRF 或 RPDB 設置，但這是高級內容，設置它的人無論如何都知道此功能）。