Estou solucionando problemas em uma configuração do OpenVPN Server no OS X Mavericks. Antes da atualização 10.9, tudo isso funcionou e estou tentando isolar o problema para algo fundamental ou para minha configuração de servidor / cliente.
Os clientes VPN podem fazer conexões TCP com toda a Internet e todas as caixas da rede local, exceto pelo próprio servidor VPN. Além disso, os clientes VPN são capazes de executar ping e rastrear o servidor com sucesso, o que é um salto de distância.
Estou perplexo e gostaria de agradecer a todos os ponteiros.
Meu servidor é 10.0.1.3 na interface 10.0.1 / 24 en0. Minha VPN está em 10.8.0 / 24 no tun0. O firewall está desabilitado, mas é necessário ativar o NAT no firewall baseado em pf para acesso do cliente à Internet, o que é feito usando as linhas pfctl pf.conf,
nat on en0 from { 10.8.0.0/24 10.0.1.0/24 } to any -> (en0)
pass all
O link de retorno TCP quebrado entre o servidor e o cliente existe, esteja o firewall ativado ou não, fazendo com que eu descarte o firewall como a causa. O encaminhamento de pacotes é ativado com os comandos do BSD:
/usr/sbin/sysctl -w net.inet.ip.fw.enable=1
/usr/sbin/sysctl -w net.inet.ip.forwarding=1
Parece que a VPN não está retornando pacotes [SYN, ACK] corretamente do servidor para o cliente VPN sobre tun0. O que impediria que pacotes de clientes VPN atingissem a LAN através da interface tun0? Os pacotes para o cliente VPN estão sendo retornados no en0, não no tun0, e isso está interrompendo a conexão. Isto ilustrado com este exemplo abaixo usando wireshark para capturar pacotes da porta 22 em tun0 e en0. Aqui está o que eu vejo no wireshark:
server [10.0.1.3]$ ssh [email protected] # Successful
tun0:
10.8.0.1 -> 10.8.0.10 ssh [SYN]
10.8.0.10 ssh -> 10.8.0.1 [SYN,ACK]
10.8.0.1 -> 10.8.0.10 ssh [ACK]
...
en0:
<No packets>
iPhone [10.8.0.10]$ ssh [email protected] # Unsuccessful
tun0:
10.8.0.10 -> 10.0.1.3 ssh [SYN]
10.8.0.10 [TCP Retransmission] -> 10.0.1.3 ssh [SYN]
10.8.0.10 [TCP Retransmission] -> 10.0.1.3 ssh [SYN]
10.8.0.10 [TCP Retransmission] -> 10.0.1.3 ssh [SYN]
10.8.0.10 [TCP Retransmission] -> 10.0.1.3 ssh [SYN]
...
en0:
10.0.1.3 ssh -> 10.8.0.10 [SYN,ACK]
10.0.1.3 [TCP Retransmission] ssh -> 10.8.0.10 [SYN,ACK]
10.0.1.3 [TCP Retransmission] ssh -> 10.8.0.10 [SYN,ACK]
10.0.1.3 [TCP Retransmission] ssh -> 10.8.0.10 [SYN,ACK]
10.0.1.3 [TCP Retransmission] ssh -> 10.8.0.10 [SYN,ACK]
10.0.1.3 [TCP Retransmission] ssh -> 10.8.0.10 [SYN,ACK]
...
Estou trabalhando no livro Ferramentas de solução de problemas de rede tentando rastrear isso. Seu primeiro exemplo usando netstat mostra uma tabela de roteamento semelhante a esta, com resolução explícita para os endereços 172.16.2.1 e 172.16.2.255.
bsd1# netstat -rn
Routing tables
Internet:
Destination
…
172.16.1/24 172.16.2.1 xl1
172.16.2/24 link#2 xl1
172.16.2.1 0:10:7b:66:f7:62 xl1
172.16.2.255 ff:ff:ff:ff:ff:ff xl1
Mas minha tabela de roteamento real para o tun0 é assim:
server$ netstat -rn
default 10.0.1.1 UGSc 157 21721 en0
…
10.8/24 10.8.0.2 UGSc 1 6 tun0
10.8.0.2 10.8.0.1 UH 2 0 tun0
Não há nada explícito para 10.8.0.1 ou 10.8.0.255 na interface tun0 - deve haver? Se sim, como faço para adicionar este caminho? Poderia ser por isso que os pacotes de retorno do servidor estão sendo enviados de volta na interface en0 padrão?
Todos os ponteiros seriam muito apreciados.