O servidor OpenVPN não pode executar ping nos clientes

O servidor OpenVPN não pode executar ping nos clientes

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

No entanto, o servidor não consegue executar ping no cliente - ele simplesmente 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 OpenVPN do servidor (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 de 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

Desativei temporariamente o firewall do servidor, todas as políticas das cadeias estã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.1funciona, assim como outros recursos.

servidor: ping 10.67.15.26expira.

Responder1

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

Problema 1: roteamento

Por algum motivo (e não tenho certeza se resolvi isso), a tabela de roteamento do servidor esquecia a rota de/para sua LAN (10.67.5.0/24). Isso fazia com que todo o tráfego de saída da LAN passasse pelo gateway principal, que não será roteado para a LAN OpenVPN (10.67.15.0/24). Isso estava causando falha no tráfego da rede OpenVPN destinada à LAN no gateway principal; assim, os pings estavam sendo enviados, mas a resposta foi descartada.

Editar:Infelizmente não sei o que causou o abandono dessa rota; como você pode ver, estava na tabela de roteamento acima. Tentei adicionar um comando de rota em /etc/network/interfaces, mas acabei com duas rotas idênticas e duplicadas, então retirei-o novamente.Era meuconstrutorconfig que estava causando o abandono desta rota: ao configurar o adaptador eth1 eu dei uma máscara de rede /32 (ou seja, um host) em vez de /24 (para a LAN).

Testando um cliente Debian, consegui descobrir isso, depois disso funcionou, mas o cliente Windows 7 não.

Problema 2: firewall/configuração do Windows 7

Houve dois problemas com a configuração do Windows.

O Windows deve ter o perfil privado "Trabalho" definido para o adaptador TAP

O crédito por esta seção vai para Kalwi

Atualização em 11/06/2020

Você pode alterar uma interface para privada usando os dois comandos do PowerShell a seguir:

# this first one will let you see the available connections, 
# find the interface index of the one you would like to change
Get-NetConnectionProfile
Set-NetConnectionProfile -InterfaceIndex NN -NetworkCategory Private

Na “Central de Rede e Compartilhamento” você deverá ver (pelo menos) 2 “redes ativas”. Eu tinha a rede wireless e depois uma "Rede Não Identificada". Este ú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 alterar isso, você precisa adicionar um gateway padrão para o adaptador.

Inicie um terminal DOS/Cygwincomo administrador. (Inicie Orb > pesquise CMD > clique com o botão direito > execute como administrador).

Então faça route print -4. Você verá uma lista de interfaces. Cada linha começa com um número e à direita você verá o nome. Identifique o número da interface do 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 -popção torna a rota permanente. Fiz sem isso primeiro, para testar.Isso pressupõe que o IP do gateway OpenVPN do cliente não mudará entre as conexões.

Depois de fazer isso, uma caixa de diálogo deverá aparecer e solicitar que você classifique a nova rede. EscolherTrabalhar.

Nesse ponto, consegui enviar tráfego da LAN da minha empresa para o cliente (testado usando o netcat), mas os pings ainda não eram respondidos.

Diga ao Windows para permitir pings (ICMPv4)

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

  • Regra personalizada
  • Todos os programas
  • Protocolo: ICMPv4
  • Permitir a conexão
  • Aplicar ao perfil privado
  • Diga.

Finalmente os pings foram retornados.

informação relacionada