Estou tentando configurar um ambiente de servidor VPN para trabalhar com o programa de teste fornecido pela Apple chamado SimpleTunneler , que usa o NETUnnelProviderManager introduzido no iOS 9.0. Para a parte do servidor, estou usando o programa tunnel_server, que faz parte desse programa.
A razão que escolhi para fazer esta pergunta neste fórum em oposição a uma específica da Apple é que sinto que os componentes básicos do servidor e do cliente estão funcionando, com apenas um problema de configuração de rede restante.
Para manter as coisas simples, estou evitando DNS e tentando acessar um servidor da Web externo (usando o endereço do Yahoo 98.139.183.24, porta 80) do meu iPhone depois de ativar a VPN no nível do dispositivo. Eu configurei a extensão de rede no dispositivo para rotear todos os pacotes IP para o túnel.
Quando tento acessar o site, vejo o tráfego indo do cliente (iPhone) para o servidor (tunnel_server no meu mac book pro), inicialmente chegando na interface utun2, que é uma interface especial criada que é associado ao túnel.
Depois disso, vejo os pacotes passarem para en0 no meu servidor e, em seguida, saírem para a rede.
Inicialmente, nunca vi nenhuma resposta voltando, e determinei que era porque o endereço de origem desses pacotes não estava sendo NATed corretamente. Depois de muita experimentação, finalmente consegui que este NAT funcionasse através da regra pfctl abaixo:
nat on en0 inet from !(en0) to any -> (en0)
Depois de adicionar isso, vejo agora os pacotes sendo corretamente NATed saindo, e até mesmo uma resposta voltando do servidor do Yahoo, para a interface en0 do meu servidor. No entanto, nunca vejo essa resposta ser encaminhada para a interface utun2 do meu servidor. Não tenho certeza se o problema é com NAT, roteamento ou qualquer outra coisa.
Se alguém tiver alguma triagem ou sugestões de solução, informe-nos.
Aqui estão minhas informações de configuração:
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
Uma coisa que parece estranha sobre essa configuração é que tanto o servidor quanto o cliente estão associados a 192.168.2.2. Na verdade, se eu tentar acertar esse endereço do iPhone, vejo um servidor web sendo executado no meu servidor e posso confirmar que tudo está passando pelo túnel.
Aqui estão minhas tabelas de roteamento para IP4 (de 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
[Nota: Originalmente eu havia postado isso em Engenharia de Redes, mas me disseram que estava fora do assunto e eu deveria tentar repassar a falha do servidor]
ATUALIZAÇÃO:
Trabalhei com alguém muito familiarizado com esse tipo de rede e conseguimos a configuração para que um ping fosse enviado para o servidor, para o servidor e para o terminal, e depois voltasse para o servidor. servidor. No entanto, não importa o que fizemos, não foi possível obter o ping para retornar ao dispositivo cliente (iPhone).
Parece que o problema poderia estar com o ARP reverso aqui e possivelmente porque o cliente e o servidor parecem ter o mesmo endereço "192.168.2.2", mas isso é apenas um palpite. No entanto, parece improvável que o programa de amostra de apple não permitiria esse tipo de caso de uso, já que é um comportamento típico de túnel.