O servidor OpenVPN não encaminha o tráfego ping de tun0 para eth0 para o restante dos hosts na sub-rede

Question

Atualmente eu tenho um servidor openvpn e configuração do cliente com rounting (não bridging)

Quando tento pingar do meu cliente para o endereço IP do servidor, ele funciona bem. Mas quando eu tento pingar o resto dos hosts de sub-rede por trás do servidor openvpn, ele não funciona. Alguém pode identificar algo obviamente errado na minha configuração? (servidor openvpn está em 10.10.145.181 e host está em 10.10.146.8 endereço IP. Eles estão em duas sub-redes separadas. Eu posso pingar 10.10.146.8 a partir de 10.10.145.181 diretamente por sshing para esse host. Só quando eu vou via VPN ele faz não funciona.)

Pelo que entendi, o tráfego de ping chega ao servidor vpn na interface tun0, mas, em seguida, o servidor vpn não está encaminhando-o sobre a eth0 para o host & daí o host pingado não vê nenhum tráfego & pacote é descartado. Mas o que poderia estar causando isso? Existe uma configuração em openvpn para encaminhar o tráfego de tun0 para eth0?

Aqui está o que eu observo ...

No host do cliente openvpn:

> ping 10.10.146.8
PING 10.10.146.8 (10.10.146.8) 56(84) bytes of data.
<no further output>

No host do servidor openvpn:

> sudo tcpdump -i tun0 'icmp[icmptype] = icmp-echo or icmp[icmptype] = icmp-echoreply'
00:34:32.624639 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1863, length 64
00:34:33.634564 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1864, length 64
00:34:34.640753 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1865, length 64
00:34:35.648922 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1866, length 64
00:34:36.659062 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1867, length 64
00:34:37.665402 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1868, length 64
00:34:38.673295 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1869, length 64
00:34:39.685336 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1870, length 64
00:34:40.687703 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1871, length 64
00:34:41.695766 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1872, length 64
> sudo tcpdump -i eth0 'icmp[icmptype] = icmp-echo or icmp[icmptype] = icmp-echoreply'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
04:14:48.583673 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 4807, seq 442, length 64
04:14:49.592908 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 4807, seq 443, length 64
04:14:50.600010 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 4807, seq 444, length 64
04:14:51.616401 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 4807, seq 445, length 64

No host da sub-rede que estou tentando fazer ping (10.10.146.8):

> sudo tcpdump -i eth0 'icmp[icmptype] = icmp-echo or icmp[icmptype] = icmp-echoreply'
sudo: unable to resolve host ip-10-10-146-8
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
<no further output>

O syslog (log openvpn) está dizendo:

Jul  8 00:36:25 ip-10-10-145-181 ovpn-server[1513]: xyz/<ip_address>:35315 UDPv4 READ [133] from [AF_INET]<ip_address>:35315: P_DATA_V1 kid=0 DATA len=132 
Jul  8 00:36:25 ip-10-10-145-181 ovpn-server[1513]: xyz/<ip_address>:35315 TUN WRITE [84]

netstat no cliente openvpn:

10.10.0.1       10.10.0.5       255.255.255.255 UGH       0 0          0 tun0
10.10.0.5       0.0.0.0         255.255.255.255 UH        0 0          0 tun0
10.10.146.0     10.10.0.5       255.255.255.0   UG        0 0          0 tun0

netstat no servidor openvpn:

10.10.0.0       10.10.0.2       255.255.255.0   UG        0 0          0 tun0
10.10.0.2       0.0.0.0         255.255.255.255 UH        0 0          0 tun0
10.10.145.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0

Eu tenho uma declaração na configuração do servidor openvpn para rotear o tráfego do lado do cliente & Eu vejo isso acontecendo.

push "route 10.10.146.0 255.255.255.0"

Informações adicionais para a pergunta de Andrew

> echo "sysctl -a | grep 'forwarding = 1'" | sudo -s
error: permission denied on key 'vm.compact_memory'
error: permission denied on key 'net.ipv4.route.flush'
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.eth0.forwarding = 1
net.ipv4.conf.tun0.forwarding = 1
error: permission denied on key 'net.ipv6.route.flush'



> sudo iptables -L INPUT
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         


> sudo iptables -L FORWARD
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Atualização: na verdade, agora vejo tráfego na eth0 no servidor, mas esse tráfego não está chegando à rede e sendo recebido pelo outro host. Eu acho que isso é problema da Amazon VPC.

    

Answer 1

Ok, eu percebi isso depois de algumas horas de investigação.

O problema está na configuração de encaminhamento. Os pacotes encaminhados para a porta eth0 não possuem o endereço IP de origem correto do host dentro da rede. O endereço IP da VPN.

05:07:43.991961 IP 10.8.0.6 > 10.10.146.8: ICMP echo request, id 3497, seq 499, length 64

Você pode mudar isso habilitando o equivalente de NAT (em roteadores) no SO linux:

iptables -t nat -A POSTROUTING -o <eth0 or whatever else> -j MASQUERADE

Isso resolveu o problema para mim.

    

Answer 2

Esse problema pode acontecer quando o gateway padrão para os hosts na LAN não é o servidor OpenVPN. Nesse caso, os hosts precisam de uma rota estática para os endereços de VPN para que as respostas cheguem ao servidor VPN em vez do gateway padrão.

Nos hosts da LAN, verifique as rotas ( route print para Windows, route -n para Linux, ǹetstat -rn para Mac).

    

Answer 3

Eu encontrei esta discussão via google, e obrigado esta informação foi útil. Eu tenho exatamente o mesmo problema, e esta informação PARCIALMENTE resolveu isso.

Masqueie e funcionou. Mas para o meu propósito, isso não é bom o suficiente e não a solução nem a resposta final para mim, eu ainda estou tentando enviá-lo sem Masquerading. Para o meu propósito, obter a conexão sozinho não é bom o suficiente. Porque eu preciso do IP de origem para identificação de logging & Objetivos de Controle de Acesso. Masquerading ficou ligado, mas aceito cegamente. A conexão sempre parece ser de um único endereço IP FALSO.

Eu tenho um servidor SQL, que deve aceitar / negar conexões dependendo do endereço IP de origem depois de acessar a VPN. É também preferível manter o registro do IP de acesso, para ajudar a rastrear erros ou a segurança contra hackers.

Ainda se perguntando por que o encaminhamento neste ponto final da VPN não acontecerá, a menos que seja Masqueraded. Suspeitando que haja um firewall local ou um problema de segurança causando.

Por favor, compartilhe alguma experiência ou sugestões, enquanto você navega nessa discussão. Obrigado.