没有错误，没有丢包，ping到客户端，tcpdump显示软件包旅行，一切都不会到达LAN主机（或OpenVPN客户端）。
尝试消除所有可能的干扰因素后，我重新configuration我的虚拟机设置使用桥梁，而不是MacVTap 。 现在访问LAN客户端按预期工作。 我希望这不是最终的答案（我想保持MacVTap）。
我之前做过一些虚拟机和networking连接，但是下面描述的这种行为对我来说是全新的。
编辑：最让我印象深刻的是响应（例如DNS查询）被路由回客户端（我添加了一个tcpdump），但仍然运行到超时。
我已经在这个问题上摸索了好几天了，在互联网上我找不到任何东西（可能是searchfunction很弱），所以我认为是时候让你的ServerFaulters在那里了。
任务 （本质上简单）：设置一个OpenVPN服务器，将stream量路由到它后面的LAN。
问题 ：Pings成功了，“其他一切”都没有。 在主机上有一个运行的DNS服务器以及一个OpenSSH-Server，两者都不能联系到。
我认为可能会涉及伪装/ NAT ，但这根本不是罪魁祸首。
其实我觉得我现在太愚蠢了 所以，请帮助一个绝望的家伙 （不要犹豫，要求更多的细节）。
VPN-Server和Host是在一台机器上运行的虚拟机VPN-Client直接连接到。 这两个虚拟机可以看到对方，iptables策略设置为接受所有主机上。
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?
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
正如你在下面看到的，从VPN-Client到主机ping成功。 （从主机ping到VPN客户端工作同样好，但我在这里省略）
这是没有任何iptables规则。
$ 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
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
再次，没有iptables规则。
$ 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)
# 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)
尝试从防火墙中的这些规则开始：
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客户端之间的全面通信。