O servidor OpenVPN não pode pingar clientes

5

Eu tenho o OpenVPN configurado em um servidor Debian. Os clientes podem se conectar e os clientes podem executar ping e acessar recursos (compartilhamentos do Samba e intranet) no servidor.

No entanto, o servidor não pode fazer ping no cliente - apenas expira.

Diagrama

Client OpenVPN assigned IP: 10.67.15.26
   ↓ UDP on 1194
Internet
   ↓
Router port-forwards 1194 to server
   ↓ 
Server LAN IP: 10.67.5.1

Configuração do servidor OpenVPN (bits relevantes)

port 1194
proto udp
dev tun
server 10.67.15.0 255.255.255.0
push "route 10.67.5.0 255.255.255.0"

Tabela de roteamento do servidor

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.67.15.2      0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.67.15.0      10.67.15.2      255.255.255.0   UG    0      0        0 tun0
10.67.5.0       0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0         10.67.5.254     0.0.0.0         UG    0      0        0 eth1

Firewall do servidor

Eu desativei temporariamente o firewall do servidor, as políticas de todas as cadeias são ACCEPT e todos os sinalizadores de encaminhamento estão definidos:

1 : /proc/sys/net/ipv4/conf/all/forwarding
1 : /proc/sys/net/ipv4/conf/default/forwarding
1 : /proc/sys/net/ipv4/conf/lo/forwarding
1 : /proc/sys/net/ipv4/conf/eth1/forwarding
1 : /proc/sys/net/ipv4/conf/tun0/forwarding
1 : /proc/sys/net/ipv4/ip_forward

Casos de teste:

cliente: ping 10.67.5.1 funciona, assim como outros recursos.

servidor: ping 10.67.15.26 expirou.

    
por artfulrobot 29.08.2012 / 13:03

1 resposta

4

Ao comparar dois clientes diferentes, consegui identificar e corrigir dois problemas.

Problema 1: roteamento

Por algum motivo (e não tenho certeza de que resolvi isso), a tabela de roteamento do servidor continuou esquecendo a rota de / para sua LAN (10.67.5.0/24). Isso estava fazendo com que todo o tráfego LAN de saída passasse pelo seu gateway principal, que não será roteado para a LAN do OpenVPN (10.67.15.0/24). Isso estava causando tráfego da rede OpenVPN destinada à LAN a falhar no gateway principal; assim pings foram enviados, mas a resposta foi retirada.

Editar: Infelizmente, não sei o que estava causando a queda dessa rota; como você pode ver, estava na tabela de roteamento acima. Eu tentei adicionar um comando de rota em / etc / network / interfaces, mas depois acabei com duas rotas duplicadas e idênticas, então tirei novamente. Era meu fwbuilder config que estava causando a queda desta rota: ao configurar o adaptador eth1 eu tinha dado uma máscara de rede / 32 (ou seja, um host) em vez de / 24 (para a LAN). / p>

Ao testar um cliente Debian, consegui descobrir este, depois disso, funcionou, mas o cliente Windows 7 não.

Problema 2: firewall / config do Windows 7

Houve dois problemas com o Windows configurado.

O Windows deve ter o perfil particular "Work" definido para o adaptador TAP

Crédito para esta seção vai para kalwi

No "Centro de Rede e Compartilhamento", você deve ver (pelo menos) 2 "redes ativas". Eu tinha a rede sem fio e depois uma "Rede não identificada". O último é o dispositivo OpenVPN TAP e tinha um ícone de banco de parque, o que significa que foi tratado como público, não confiável. Para poder mudar isso, você precisa adicionar um gateway padrão para o adaptador.

Inicie um terminal DOS / Cygwin como administrador . (Inicie o Orb > procure por CMD > clique com o botão direito nele > execute como administrador).

Em seguida, faça route print -4 . Você verá uma lista de interface. Cada linha começa com um número e à direita você verá o nome. Identifique o número da interface para o Adaptador TAP-Win32. O meu tinha 17 anos.

Agora adicione a rota:

route -p add 0.0.0.0 mask 0.0.0.0 1.2.3.4 metric 500 if 17

Onde 1.2.3.4 precisa ser o IP do seu gateway OpenVPN (revelado na coluna Gateway na saída do comando anterior) e 17 precisa ser o número da sua interface TAP. A opção -p torna a rota permanente. Eu fiz isso sem primeiro, para testar. Isso supõe que o IP do gateway OpenVPN do cliente não vai mudar entre as conexões .

Uma vez que você tenha feito isso, uma caixa de diálogo deve aparecer e pedir que você classifique a nova rede. Escolha Trabalhar .

Neste momento, consegui enviar tráfego da LAN da minha empresa para o cliente (testado com o netcat), mas os pings ainda continuavam sem resposta.

Diz ao Windows para permitir pings (ICMPv4)

Iniciar Orb > Firewall do Windows com Segurança Avançada Em seguida, vá para Regras de Entrada e Nova Regra ...

  • Regra personalizada
  • Todos os programas
  • Protocolo: ICMPv4
  • Permitir a conexão
  • Aplicar ao perfil particular
  • Nomeie-o.

Finalmente, os pings foram devolvidos.

    
por 30.08.2012 / 13:23