简短简历
没有错误，没有丢弃数据包，ping 到达客户端，tcpdump 显示数据包正在传输，其他一切都不会到达 LAN 主机（或 OpenVPN 客户端）。
编辑
在尝试消除所有可能的破坏因素后，我重新配置了我的虚拟机设置，以使用桥接而不是麦金塔。现在访问 LAN 客户端的工作正常了。我希望这不是最终答案（我想保留 MacVTap）。
我之前做过一些虚拟机和网络方面的工作，但下面描述的行为对我来说还是全新的。
编辑： 最让我震惊的是，响应（例如 DNS 查询）被路由回客户端（我添加了它的 tcpdump），但 dig 仍然会超时。
我已经为此苦思冥想好几天了，但是在互联网上却找不到任何东西（可能是搜索功能太弱了），所以我想是时候请你们这些 ServerFaulters 来解决了。
任务（本质上很简单）：设置一个 OpenVPN 服务器，将流量路由到其后面的 LAN。
问题：Ping 成功，“其他一切都失败”。主机上有一个正在运行的 DNS 服务器以及一个 OpenSSH 服务器，但两者都无法访问。
我认为可能会有伪装 / NATing但这根本不是罪魁祸首。
事实上，我认为我现在太笨了。 所以，请帮助这个绝望的人（如需了解更多详细信息，请随时询问）。
设置
VPN 服务器和主持人虚拟机是否在计算机上运行VPN 客户端直接连接到。两个虚拟机可以互相看到，所有主机上的 iptables 策略均设置为 ACCEPT。
OpenVPN 服务器
eth0 10.0.0.3
tun0:1 172.16.0.3
tun0 10.8.0.1
# cat /proc/sys/net/ipv4/ip_forward
1
# lsmod
xt_conntrack 12681 3
iptable_filter 12536 1
ipt_MASQUERADE 12594 3
iptable_nat 12646 1
nf_conntrack_ipv4 18499 4
nf_defrag_ipv4 12483 1 nf_conntrack_ipv4
nf_nat_ipv4 12912 1 iptable_nat
nf_nat 22379 3 ipt_MASQUERADE,nf_nat_ipv4,iptable_nat
nf_conntrack 70753 6 ipt_MASQUERADE,nf_nat,nf_nat_ipv4,xt_conntrack,iptable_nat,nf_conntrack_ipv4
ip_tables 21914 2 iptable_filter,iptable_nat
x_tables 23015 4 ip_tables,ipt_MASQUERADE,xt_conntrack,iptable_filter
[…]
/etc/openvpn/server.conf
port 1194
proto udp
dev tun
server 10.8.0.0 255.255.255.0
push "route 10.0.0.0 255.255.255.0"
topology subnet # is this actually needed?
VPN 客户端
eth0 172.16.0.100
tun0 10.8.0.4
$ ip route
10.0.0.0/24 via 10.8.0.1 dev tun0
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.4
172.16.0.0/24 dev eth0 proto kernel scope link src 172.16.0.100
OpenVPN 连接（摘录）
$ sudo openvpn --config vpn.ovpn
…
UDPv4 link remote: [AF_INET]172.16.0.3:1194
TLS: Initial packet from [AF_INET]172.16.0.3:1194, sid=b636ac88 2ef4c575
[…] Peer Connection Initiated with [AF_INET]172.16.0.3:1194
SENT CONTROL […]: 'PUSH_REQUEST' (status=1)
PUSH: Received control message: 'PUSH_REPLY,route 10.0.0.0 255.255.255.0,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.4 255.255.255.0'
/sbin/ip link set dev tun0 up mtu 1500
/sbin/ip addr add dev tun0 10.8.0.4/24 broadcast 10.8.0.255
/sbin/ip route add 10.0.0.0/24 via 10.8.0.1
主持人
eth0 10.0.0.2
$ ip route
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.2
10.8.0.0/24 via 10.0.0.3 dev eth0
ICMP 回显
如下所示，从 VPN 客户端到主机的 ping 操作成功。（从主机到 VPN 客户端的 ping 操作同样有效，但我在这里省略了它们）
这是在没有任何 iptables 规则的情况下完成的。
VPN 客户端
$ ping -c1 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=63 time=1.30 ms
--- 10.0.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.303/1.303/1.303/0.000 ms
OpenVPN 服务器
tcpdump -i tun0
11:01:25.787428 IP 10.8.0.4 > 10.0.0.2: ICMP echo request, id 4209, seq 1, length 64
11:01:25.787899 IP 10.0.0.2 > 10.8.0.4: ICMP echo reply, id 4209, seq 1, length 64
主持人
# tcpdump net 10.8.0.0/24
11:01:25.797640 IP 10.8.0.4 > 10.0.0.2: ICMP echo request, id 4209, seq 1, length 64
11:01:25.797682 IP 10.0.0.2 > 10.8.0.4: ICMP echo reply, id 4209, seq 1, length 64
DNS 查询
再次，没有 iptables 规则。
VPN 客户端
$ dig @10.0.0.2 serverfault.com
; <<>> DiG 9.9.3-rpz2+rl.13214.22-P2-Debian-1:9.9.3.dfsg.P2-4 <<>> @10.0.0.2 serverfault.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
编辑：连接超时，但在tcpdump中可以看到响应：
# tcpdump -i tun0
14:26:26.609399 IP vpnclient.56553 > 10.0.0.2.domain: 44738+ [1au] A? serverfault.com. (44)
14:26:26.738504 IP 10.0.0.2.domain > vpnclient.56553: 44738$ 1/0/0 A 198.252.206.16 (49)
OpenVPN 服务器
# tcpdump -i tun0
10:03:52.077784 IP 10.8.0.4.58792 > 10.0.0.2.domain: 61705+ [1au] A? serverfault.com. (44)
10:03:52.092420 IP 10.0.0.2.domain > 10.8.0.4.58792: 61705$ 1/0/0 A 198.252.206.16 (49)
主持人
# tcpdump net 10.8.0.0/24
10:03:57.061048 IP 10.8.0.4.58792 > 10.0.0.2.domain: 61705+ [1au] A? serverfault.com. (44)
10:03:57.075223 IP 10.0.0.2.domain > 10.8.0.4.58792: 61705$ 1/0/0 A 198.252.206.16 (49)
答案1
尝试在防火墙中从这些规则开始：
iptables -A FORWARD -i tun0 -o eth0 -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -s 10.0.0.0/24 -j ACCEPT
它应该允许 LAN 和 VPN 客户端之间的完全通信。