Я пытаюсь настроить среду VPN-сервера для работы с тестовой программой, предоставленной Apple, которая называется SimpleTunneler, который использует NETUnnelProviderManager, представленный в iOS 9.0. Для серверной части я использую программу tunnel_server, которая является частью этой программы.
Причина, по которой я решил задать этот вопрос на этой плате, а не на вопросе для Apple, заключается в том, что я чувствую, что основные серверные и клиентские компоненты работают, и осталась только проблема с конфигурацией сети.
Чтобы упростить задачу, я избегаю DNS и просто пытаюсь подключиться к внешнему веб-серверу (используя адрес Yahoo 98.139.183.24, порт 80) со своего iPhone после того, как я включил VPN на уровне устройства. Я настроил расширение сети на устройстве для маршрутизации всех IP-пакетов в туннель.
Когда я пытаюсь получить доступ к сайту, я вижу, что трафик, идущий от клиента (iPhone) к серверу (tunnel_server в моем Mac Book Pro), первоначально поступает через интерфейс utun2, который представляет собой специальный интерфейс, созданный, связанный с туннель.
После этого я вижу, что пакеты перемещаются в en0 на моем сервере, а затем уходят в сеть.
Первоначально я никогда не видел, чтобы ответ возвращался, и определил, что это произошло из-за того, что исходный адрес этих пакетов не был правильно преобразован через NAT. После долгих экспериментов я наконец заставил это преобразование NAT работать с помощью следующего правила pfctl:
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, я вижу, что он попадает на веб-сервер, работающий на моем сервере, и могу подтвердить, что все проходит через туннель.
Вот мои таблицы маршрутизации для 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
[Примечание: я изначально разместил это на сайте Network Engineering, но мне сказали, что это не по теме, и я должен попытаться повторно опубликовать сообщение о сбое сервера]
ОБНОВИТЬ:
Я работал с кем-то, кто хорошо знаком с этим типом сетей, и мы смогли получить конфигурацию, чтобы пинг отправлялся с клиентского устройства на сервер и конечную точку, а затем возвращался на сервер. Однако, что бы мы ни делали, мы не могли вернуть пинг на клиентское устройство (iPhone).
Похоже, что проблема может быть здесь с обратным ARP, и, возможно, из-за того, что клиенту и серверу, похоже, назначен один и тот же адрес «192.168.2.2», но это только предположение. Однако кажется маловероятным, что программа-пример для Apple не допускала бы такой вариант использования, поскольку это типичное поведение туннеля.