我需要设置从本地网络到 VPN 的路由。也就是说，LAN 内部的任何人都应该能够与 VPN 中的机器进行通信，本身无需成为 VPN 客户端。问题是，当谈到网络时，我有点儿像个傻瓜……
本地网络的范围是 8 位，即 192.168.2.X VPN 服务器本身位于另一个网络中，即 192.168.3.20（8 位） VPN 网络的范围是 16 位，即 10.8.XX
运行 openvpn 服务器的机器的 eth0 接口有一个静态 IP，为 192.168.3.20。vpn 服务器本身的 tun0 接口监听 10.8.0.1
我们已经完成的工作是将本地网络中发往 10.8.xx 的数据包重新路由到服务器：
traceroute to 10.8.0.1 (10.8.0.1), 30 hops max, 60 byte packets
1 gateway (192.168.2.1) 2.508 ms 2.364 ms 2.325 ms
2 10.8.0.1 (10.8.0.1) 1.898 ms 1.895 ms 1.911 ms
所以我已经可以通过 10.8.0.1 ssh 进入它了，没问题。
然而，当我尝试通过 VPN 访问客户端时，结果却有很大不同：
traceroute to 10.8.0.178 (10.8.0.178), 30 hops max, 60 byte packets
1 gateway (192.168.2.1) 2.315 ms 2.152 ms 2.036 ms
2 192.168.3.20 (192.168.3.20) 1.764 ms 1.760 ms 1.776 ms
3 * * *
etc...
让我有点恼火的是，对服务器的直接请求终止于 10.8.0.1，而我原本以为它要么不起作用，要么终止于 192.168.3.20。所以显然我不太明白这里发生了什么……
从那里开始，我认为我可以通过将进入 eth0 的流量转发到 tun0 来解决问题：
sudo iptables -A FORWARD -i eth0 -o tun0 -d 10.8.0.0/16 -j ACCEPT
但那并没有任何效果。这就是我陷入困境的地方。我尝试了上述几种变体，并在 OpenVPN 配置中尝试了路由，所有这些都没有任何明显的变化。
但有趣的是，跟踪活动实际上出现在
*VPN log, but I don't understand much of what's going on here either:
Fri Oct 19 11:57:53 2018 us=219532 GET INST BY VIRT: 10.8.0.158 -> y18022c/185.184.117.20:1194 via 10.8.0.158
Fri Oct 19 11:57:53 2018 us=219539 y18022c/185.184.117.20:1194 TUN READ [60]
Fri Oct 19 11:57:53 2018 us=219544 y18022c/185.184.117.20:1194 TLS: tls_pre_encrypt: key_id=0
Fri Oct 19 11:57:53 2018 us=219555 y18022c/185.184.117.20:1194 ENCRYPT IV: 14c0471a 9fe7860f
Fri Oct 19 11:57:53 2018 us=219580 y18022c/185.184.117.20:1194 ENCRYPT FROM: 000000ae fa450000 3cac0400 000b1135 5ec0a803 010a0800 9e98b682 bf00282[more...]
Fri Oct 19 11:57:53 2018 us=219612 y18022c/185.184.117.20:1194 ENCRYPT TO: 14c0471a 9fe7860f 00bbfc72 b50c8915 8390d362 82f0a84c c22803b1 2a7ceca[more...]
Fri Oct 19 11:57:53 2018 us=219622 PO_CTL rwflags=0x0002 ev=4 arg=0x5654a4302150
Fri Oct 19 11:57:53 2018 us=219629 PO_CTL rwflags=0x0000 ev=5 arg=0x5654a4302068
Fri Oct 19 11:57:53 2018 us=219637 I/O WAIT Tr|Tw|Sr|SW [0/63574]
Fri Oct 19 11:57:53 2018 us=219646 PO_WAIT[0,0] fd=4 rev=0x00000004 rwflags=0x0002 arg=0x5654a4302150
Fri Oct 19 11:57:53 2018 us=219652 event_wait returned 1
Fri Oct 19 11:57:53 2018 us=219658 I/O WAIT status=0x0002
Fri Oct 19 11:57:53 2018 us=219696 y18022c/185.184.117.20:1194 UDPv4 WRITE [101] to [AF_INET]185.184.117.20:1194: P_DATA_V1 kid=0 DATA c15dc78e ddd12705 8c3a860c 9cd9fe1e da29c4b2 14c0471a 9fe7860f 00bbfc7[more...]
Fri Oct 19 11:57:53 2018 us=219707 y18022c/185.184.117.20:1194 UDPv4 write returned 101
Fri Oct 19 11:57:53 2018 us=219715 PO_CTL rwflags=0x0001 ev=4 arg=0x5654a4302150
Fri Oct 19 11:57:53 2018 us=219722 PO_CTL rwflags=0x0001 ev=5 arg=0x5654a4302068
Fri Oct 19 11:57:53 2018 us=219730 I/O WAIT TR|Tw|SR|Sw [0/63574]
Fri Oct 19 11:57:53 2018 us=231770 PO_WAIT[0,0] fd=4 rev=0x00000001 rwflags=0x0001 arg=0x5654a4302150
Fri Oct 19 11:57:53 2018 us=231782 event_wait returned 1
Fri Oct 19 11:57:53 2018 us=231789 I/O WAIT status=0x0001
Fri Oct 19 11:57:53 2018 us=231799 UDPv4 read returned 53
Fri Oct 19 11:57:53 2018 us=231809 GET INST BY REAL: 185.184.117.20:1194 [succeeded]
Fri Oct 19 11:57:53 2018 us=231837 y18022c/185.184.117.20:1194 UDPv4 READ [53] from [AF_INET]185.184.117.20:1194: P_DATA_V1 kid=0 DATA 1196c495 845bb7fd e61cc8d8 ed4d427a b901d6c8 e81fe5a9 3ab1acce b5687f0[more...]
Fri Oct 19 11:57:53 2018 us=231846 y18022c/185.184.117.20:1194 TLS: tls_pre_decrypt, key_id=0, IP=[AF_INET]185.184.117.20:1194
Fri Oct 19 11:57:53 2018 us=231859 y18022c/185.184.117.20:1194 DECRYPT IV: e81fe5a9 3ab1acce
Fri Oct 19 11:57:53 2018 us=231876 y18022c/185.184.117.20:1194 DECRYPT TO: 00000036 fa2a187b f3641eb4 cb07ed2d 0a981fc7 48
Fri Oct 19 11:57:53 2018 us=231897 y18022c/185.184.117.20:1194 PID_TEST [0] [SSL-0] [>EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE] 0:53 0:54 t=1539943073[0] r=[0,64,15,0,1] sl=[11,53,64,528]
Fri Oct 19 11:57:53 2018 us=231905 y18022c/185.184.117.20:1194 RECEIVED PING PACKET*
我最大的问题其实是我不知道这里到底发生了什么……为什么对 10.8.0.1 的请求没有通过 192.168.3.20 路由？我的意思是，在终止于 VPN 之前，它必须经过实际服务器，这合乎逻辑……？当请求到达 eth0 时（从跟踪中显示的 192.168.3.20 可以看出），为什么它们没有转发到 tun0？openVPN 本身在这里阻止了什么吗？
答案1
我没有足够的要点来评论，但我想知道你是如何连接 192.168.2.X 和 192.168.3.X 的？我猜你需要将 192.168.3.X 的路由推回到 VPN 的另一端。在 /etc/openvpn/server.conf 中添加 192.168.2.X 的路由：（你可能已经有 192.168.3.X 网络了）
# /etc/openvpn/server.conf
# Router Subnet
route 192.168.3.0 255.255.255.0
push "route 192.168.3.0 255.255.255.0"
# The other local Subnet that you need to tell the far end about
route 192.168.2.0 255.255.255.0
push "route 192.168.2.0 255.255.255.0"
现在假设本地 vpn 服务器是 LAN 的默认网关，则每一端都应该能够路由到另一端。
你是这个意思吗？