我相信我的问题与这个问题类似通过 VPN 访问 VirtualBox 访客，但不完全是。我正在尝试走另一条路：我正在尝试从访客到达主机可以通过 OpenVPN 访问的目的地。
我的 VirtualBox 来宾有一个仅主机网络 ( vboxnet0)，其中来宾为192.168.56.101，主机为192.168.56.1。主机是 OpenVPN 网络上的客户端，10.44.55.55通过 OpenVPN 上的虚拟tun1网关10.9.0.1.从客户端到远程的连接是已知良好的。
在guest上，我定义了一条路线：route add -host 10.44.55.55 gw 192.168.56.1 dev enp0s8
...这样路由表看起来像这样：
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.1.1 0.0.0.0 UG 0 0 0 enp0s3
10.44.55.55 192.168.56.1 255.255.255.255 UGH 0 0 0 enp0s8
正如您所看到的，这是仅主机网络的主机端的 IP 地址以及通向该网络的虚拟网络适配器。
关于客人，我现在尝试了ping 10.44.55.55。没有任何回应，以下是我尝试系统诊断问题的方法：
tcpdump -nn icmp于主持人显示数据包是由绑定到目标的客户端地址发出：192.168.56.101 > 10.44.55.55。问题是，他们实际上并没有到达那里。尽管主机知道到达的路由10.44.55.55并且可以 ping 它，并且尽管主机上可以看到数据包tcpdump，但它们不会像主机上相同命令发出的数据包一样通过隧道到达目的地。
tcpdump -nn icmp执行于远端显示 ping 数据包未到达，如果流量源自虚拟机。 （当然，如果主持人问题ping 10.44.55.55,数据包做到达。）
主机是Mac OS/X（埃尔卡皮坦）我突然想到“也许这是主机上的数据包转发问题”。现在参考这个线程OS X 中的数据包转发，我找到了正确的sysctl命令并按照那里的描述启用了数据包转发，但没有高兴。
以下是我如何知道 OS/X 主机上的端口转发已打开，尽管它没有任何作用：
$ sysctl -a | grep forw
net.inet.ip.forwarding: 1
我有信心我相当关闭这里有一个解决方案，但我只是找不到合适的网络魔力。提前致谢 ...
进一步说明：仍在修改这个，我试图定义一条路线10.9.0.1 （相关 OpenVPN 门户）具有类似的负面结果。
答案1
解决了！
奇怪的是，当我将主机适配器类型从Bridged Network（直接访问主机适配器）更改为时NAT，我发现我可以查看主机可访问的遥控器的 IP 地址。
我现在对自己 1 月 19 日的评论 (#5) 感到相当困惑。（当时我一定是“太困惑了”。）
现在，这是专门针对“从客户端到达主机的 VPN 连接。”它不适用于相反方向的交通。 （即使主机也无法 ping 通“NAT”虚拟接口。）