Gateway OpenVPN sem NAT

0

Estou tentando configurar um gateway VPN transparente para uma rede remota, na rede remota há um servidor OpenVPN e na rede local um cliente OpenVPN atuando como gateway.

O diagrama mostra o IP e rotas para cada host, em verde eu marquei as rotas que adicionei para fazer todo o trabalho, eu quero fazer NAT no servidor VPN, por isso não são necessárias rotas adicionais em cada servidor do que rede (O servidor chamado Destination é um exemplo de um servidor nessa rede).

Editado para adicionar esclarecimentos:

Meu problema reside apenas no servidor rotulado "cliente VPN", posso fazer a configuração funcionar configurando um NAT nesse servidor como descrito abaixo, mas quero rotear pacotes para "servidor VPN" sem NAT , o NAT será executado pelo "servidor VPN".

Nomeuentender,umpingdocomputadorchamado"workstation" para o servidor rotulado "destination" deve funcionar, mas não funciona, o mesmo ping do cliente VPN funciona como esperado com apenas um NAT executado no servidor VPN.

Se eu abrir um tcpdump no tun0 em ambos os lados, posso ver os pacotes de ping da estação de trabalho para o destino no cliente VPN, mas nada no servidor VPN, aqui está a saída do tcpdump no cliente VPN:

$ sudo tcpdump -i tun0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
16:07:11.391614 IP 10.1.110.7 > 192.168.1.63: ICMP echo request, id 10871, seq 49, length 64
16:07:12.404989 IP 10.1.110.7 > 192.168.1.63: ICMP echo request, id 10871, seq 50, length 64

Se eu adicionar uma regra de mascaramento no cliente VPN, o ping chegará ao destino e enviará a resposta:

$ iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Mas com esta configuração eu estaria realizando NAT duas vezes, eu quero o cliente VPN para encaminhar os pacotes sem precisar de permissão.

A política de encaminhamento do firewall está definida para aceitar:

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

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

E não há regras de NAT que possam interferir:

$ sudo iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination        

O IP forwaring está ativado:

$ cat /proc/sys/net/ipv4/ip_forward
1

O que eu sinto falta?

    
por hchinchilla 13.11.2017 / 16:23

1 resposta

0

Acontece que o OpenVPN tem suas próprias tabelas de roteamento, uma parte daquelas que você pode ver com ip ro ou route -n .

Se o servidor OpenVPN receber um pacote de um cliente com um endereço de origem para o qual não tenha rotas (o servidor vpn, não o host), ele será descartado antes de atingir o tun0. Quando isso acontece, você pode ver uma mensagem como esta no log openvpn:

Tue Nov 14 11:26:21 2017 us=135733 client/X.X.X.X:40770 MULTI: bad source address from client [10.1.110.7], packet dropped

Quando isso acontece, você precisa adicionar um iroute , os iroutes são específicos do cliente e você deve ativar o client-config-dir

#/etc/openvpn/server.conf
...
client-config-dir ccd

Então, dentro de /etc/openvpn/ccd/<client_name> você pode adicionar sua iroute:

# /etc/openvpn/ccd/client
iroute 10.1.0.0 255.255.0.0

Depois de reiniciar o servidor OpenVPN, você começará a ver seus pacotes alcançando o tun0 no outro lado, já que desta vez o OpenVPN não os derrubará.

    
por 14.11.2017 / 14:49