openvpn se conecta mas não funciona até que o servidor faça um pingo no cliente

1

Eu estou tentando configurar uma conexão usando o openvpn de uma máquina cliente do windows 7 para um host linux. Estou usando o openvpn no modo roteado tradicional usando dispositivos de toque, e a configuração que estou usando é basicamente uma que funcionou bem para mim no passado para conexões linux-linux. No servidor eu tenho:

lport 1198
dev tap
ifconfig 192.168.0.16 255.255.255.240
secret bubble.key
ping 10
verb 3
mute 10
route 192.168.2.0 255.255.255.0 192.168.0.17

No cliente, tenho:

remote [my server's public ip address]
rport 1198
dev tap
ifconfig 192.168.0.17 255.255.255.240
secret bubble.key
ping 10
ping-restart 120
verb 3
mute 10

Meu problema é que toda vez que o lado do cliente é reiniciado, inicialmente é incapaz de contatar o servidor. No entanto, quando eu envio um ping do servidor para o cliente, tudo começa a funcionar. Além de deixar um processo de ping em execução no servidor, não sei como fazer isso funcionar ...

Mais informações: suspeitando de um problema de ARP, estive examinando as configurações de ARP. O host linux tem as seguintes informações de rede:

tap1      Link encap:Ethernet  HWaddr 00:ff:55:4d:06:47
          inet addr:192.168.0.16  Bcast:192.168.0.31  Mask:255.255.255.240
          inet6 addr: fe80::2ff:55ff:fe4d:647/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:45508 errors:0 dropped:0 overruns:0 frame:0
          TX packets:45318 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:3375338 (3.2 MiB)  TX bytes:3561021 (3.3 MiB)

Mas a máquina do Windows parece estar pegando um endereço físico incorreto para isso:

$ arp -a

Interface: 192.168.0.17 --- 0xf
  Internet Address      Physical Address      Type
  192.168.0.16          00-ff-51-1e-af-f3     dynamic
  192.168.0.31          ff-ff-ff-ff-ff-ff     static
  224.0.0.22            01-00-5e-00-00-16     static
  224.0.0.252           01-00-5e-00-00-fc     static
  255.255.255.255       ff-ff-ff-ff-ff-ff     static

Que é então corrigido quando recebe um pacote da extremidade remota. No entanto, toda vez que eu executo 'arp -d 192.168.0.16', o endereço físico é revertido para o mesmo incorreto. Eu não tenho certeza de onde está começando. Alguma idéia?

Atualização: alternar de "tocar" para "tun" resolve o problema, mas eu ainda gostaria de entender por que ele não funciona corretamente no modo "tocar".

    
por Jules 01.02.2013 / 22:00

1 resposta

0

Olá eu aprendi que habilitar o promisc mode em todos os níveis de interfaces no servidor ajuda a acelerar este processo - no entanto, notei este bug também - ele realmente funciona ao longo do tempo - tente pingar vários endereços do windows sobre tap e um por um será dicovered, mas vai levar tempo, maneira mais rápida é ping de servidores, mas nem sempre é possível. Eu estou procurando por outras soluções que, na verdade, atualizam manualmente a tabela arp, mas parece um bug no driver TAP ou nas atualizações do Windows ARP. Estranho o suficiente, depois de estabelecer uma conexão, funciona de forma flácida. (eu estou usando o TCP - talvez mais hickups, mas é mais estável - eu estou raching 45 mbit de download e 50 mbit de upload que é muito o suficiente eu acho)

    
por 11.02.2014 / 09:16