设备范围的 iON VPN 的正确 NAT/路由配置(使用 NETunnelProviderManager)

设备范围的 iON VPN 的正确 NAT/路由配置(使用 NETunnelProviderManager)

我正在尝试设置一个 VPN 服务器环境,以便与 Apple 提供的测试程序配合使用简单隧道工具,它使用了 iOS 9.0 中引入的 NETUnnelProviderManager。对于服务器部分,我使用的是该程序的一部分 tunnel_server 程序。

我之所以选择在这个论坛上而不是在特定于 Apple 的论坛上询问这个问题,是因为我觉得基本服务器和客户端组件正在运行,只剩下网络配置问题。

为了简单起见,我避免使用 DNS,而是在启用设备级 VPN 后尝试从我的 iPhone 访问外部 Web 服务器(使用 Yahoo 地址 98.139.183.24,端口 80)。我已在设备上配置网络扩展,以将所有 IP 数据包路由到隧道。

当我尝试访问该网站时,我看到流量从客户端(iPhone)到服务器(我的 mac book pro 上的隧道服务器),最初进入 utun2 接口,这是一个与隧道关联的特殊接口。

之后,我看到数据包移动到我服务器上的 en0,然后进入网络。

最初,我从未看到任何响应,并确定这是因为这些数据包的源地址未正确进行 NAT。经过大量实验,我终于通过以下 pfctl 规则使此 NAT 正常工作:

nat on en0 inet from !(en0) to any -> (en0)

添加此内容后,我现在看到数据包正确地进行了 NAT 并传出,甚至从 Yahoo 服务器返回响应,到达我的服务器的 en0 接口。但是,我从未看到该响应被转发到我的服务器的 utun2 接口。我不确定问题出在 NAT、路由还是其他方面。

如果有人有任何分类或解决方案建议,请告诉我。

这是我的设置信息:

Server: 10.15.68.160/21 (internal company networking, using WiFi on en0)
Client: 10.15.68.199 (initially), but changes to 192.168.2.2/21 due to the configuration I have set for the server_tunnel program

此设置似乎有点奇怪,即服务器和客户端都与 192.168.2.2 相关联。实际上,如果我尝试从 iPhone 访问该地址,我会看到它访问了在我的服务器上运行的 Web 服务器,并且可以确认所有内容都在通过隧道。

这是我的 IP4 路由表(来自 netstat -nr):

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            10.15.64.1         UGSc          468      113     en0
10.15.64/21        link#5             UCS             4        0     en0
10.15.64.1/32      link#5             UCS             2        0     en0
10.15.64.1         0:8:e3:ff:fd:90    UHLWIir       470      180     en0   1078
10.15.68.160/32    link#5             UCS             1        0     en0
10.15.68.199       70:3e:ac:7b:ea:6a  UHLWIi          2     1259     en0    837
10.15.71.141       c4:d9:87:7a:89:b0  UHLWIi          2      256     en0    744
10.15.71.255       link#5             UHLWbI          1      108     en0
127                127.0.0.1          UCS             2      159     lo0
127.0.0.1          127.0.0.1          UH              4   568903     lo0
127.0.53.53        127.0.0.1          UHWIi           1        1     lo0
169.254            link#5             UCS             1        0     en0
192.168.2          link#5             UC              3        0     en0
192.168.2.2        192.168.2.2        UH              2        0   utun2
192.168.2.3        60:3:8:9c:ea:6e    UHLWIi          1       31     lo0
192.168.2.255      link#5             UHLWbI          1      108     en0
255.255.255.255/32 link#5             UCS             2        0     en0
255.255.255.255    link#5             UHLWbI          1       99     en0

[注:我最初在网络工程上发布了这篇文章,但有人告诉我它偏离了主题,我应该尝试在 Server Fault 上重新发布]

更新:

我与一位非常熟悉此类网络的人合作,我们能够获得配置,以便 ping 能够从客户端设备传出,到达服务器,到达端点,然后返回到服务器。但是,无论我们做什么,都无法让 ping 返回到客户端设备 (iPhone)。

问题似乎出在这里的反向 ARP,可能是因为客户端和服务器似乎都被分配了相同的地址“192.168.2.2”,但这只是猜测。然而,苹果示例程序似乎不太可能不允许这种用例,因为这是典型的隧道行为。

相关内容