Eu tenho uma VPN site a site configurada usando OpenVPN. O túnel parece subir muito bem (e posso pingar de uma ponta a outra), mas não consigo fazer com que as redes nas duas pontas se vejam.
Minha topologia é a seguinte:
Net1 (192.168.13.0/24)
|
|
|
192.168.13.35
ens160
-----------
OVPN Client
-----------
tun0
10.13.10.2
|
|
10.13.10.1
tun0
-----------
OVPN Server
-----------
ens160
10.1.121.6
|
|
Net2 (10.1.121.0/26)
Eu posso pingar do cliente para o servidor:
srv# ping 10.13.10.2
PING 10.13.10.2 (10.13.10.2) 56(84) bytes of data.
64 bytes from 10.13.10.2: icmp_seq=1 ttl=64 time=5.46 ms
64 bytes from 10.13.10.2: icmp_seq=2 ttl=64 time=5.01 ms
Posso ir do cliente para Net1 (depois de adicionar as rotas apropriadas, é claro):
client#ping 10.1.121.8
PING 10.1.121.8 (10.1.121.8) 56(84) bytes of data.
64 bytes from 10.1.121.8: icmp_seq=1 ttl=63 time=48.0 ms
No entanto, não consigo fazer o contrário (pingar algo na rede do cliente -Net2- do servidor). Não consigo nem acessar o IP do cliente na Net2 do servidor:
server#ping 192.168.13.35
PING 192.168.13.35 (192.168.13.35) 56(84) bytes of data.
^C
--- 192.168.13.35 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2014ms
Eu tenho as rotas apropriadas:
server# ip route
default via 10.1.121.1 dev ens160 onlink
10.1.121.0/26 dev ens160 proto kernel scope link src 10.1.121.6
10.13.10.0/24 dev tun0 proto kernel scope link src 10.13.10.1
192.168.13.0/24 via 10.13.10.2 dev tun0
client# ip route
default via 192.168.13.1 dev ens160 onlink
10.1.121.0/24 via 10.13.10.1 dev tun0
10.13.10.0/24 dev tun0 proto kernel scope link src 10.13.10.2
192.168.13.0/24 dev ens160 proto kernel scope link src 192.168.13.35
O IPTables não está bloqueando nada (tudo está configurado para ACEITAR):
client# iptables -L -vn
Chain INPUT (policy ACCEPT 56 packets, 3839 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 40 packets, 4343 bytes)
pkts bytes target prot opt in out source destination
server# iptables -L -vn
Chain INPUT (policy ACCEPT 736 packets, 75398 bytes)
pkts bytes target prot opt in out source destination
2 168 ACCEPT all -- tun0 * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT 4 packets, 236 bytes)
pkts bytes target prot opt in out source destination
1 84 ACCEPT all -- tun0 * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 449 packets, 43393 bytes)
pkts bytes target prot opt in out source destination
Se eu executar um tcpdump na interface do túnel, vejo os pacotes ICMP saindo do cliente, mas não os vejo entrando no servidor:
server# ping 192.168.13.35
PING 192.168.13.35 (192.168.13.35) 56(84) bytes of data.
16:57:40.262004 IP 10.13.10.1 > 192.168.13.35: ICMP echo request, id 1562, seq 1, length 64
16:57:41.269165 IP 10.13.10.1 > 192.168.13.35: ICMP echo request, id 1562, seq 2, length 64
16:57:42.277154 IP 10.13.10.1 > 192.168.13.35: ICMP echo request, id 1562, seq 3, length 64
16:57:43.285163 IP 10.13.10.1 > 192.168.13.35: ICMP echo request, id 1562, seq 4, length 64
client# tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
Ambos os endpoints são Ubuntu 16.04 Server LTS (x64, instalado principalmente com os padrões).
Eu pensei que sabia um pouco sobre redes Linux, mas... parece que eu estava errado :) . Não tenho ideia de por que isso não está funcionando e fiquei sem ideias de coisas que poderia tentar. Será que alguém me pode apontar a direção certa, por favor?
Obrigada!
Você pode estar perdendo o
iroute. Além de empurrar rotas, você precisariairoutede arquivos de configuração. Aqui está o trecho da página de manual do OpenVPN.--iroute rede [máscara de rede]
Gere uma rota interna para um cliente específico. O parâmetro netmask, se omitido, assume como padrão 255.255.255.255. Essa diretiva pode ser usada para rotear uma sub-rede fixa do servidor para um cliente específico, independentemente de onde o cliente está se conectando. Lembre-se de que você também deve adicionar a rota à tabela de roteamento do sistema (por exemplo, usando a diretiva --route). A razão pela qual duas rotas são necessárias é que a diretiva --route roteia o pacote do kernel para o OpenVPN. Uma vez no OpenVPN, a diretiva --iroute roteia para o cliente específico. Essa opção deve ser especificada em um arquivo de configuração de instância do cliente usando --client-config-dir ou gerada dinamicamente usando um script --client-connect. A diretiva --iroute também tem uma interação importante com --push "route ...". --iroute define essencialmente uma sub-rede que pertence a um cliente específico (vamos chamá-lo de cliente A). Se você quiser que outros clientes possam acessar a sub-rede de A, você pode usar --push "route ..." junto com --client-to-client para efetuar isso. Para que todos os clientes vejam a sub-rede de A, o OpenVPN deve enviar esta rota para todos os clientes, EXCETO para A, pois a sub-rede já pertence a A. O OpenVPN consegue isso não enviando uma rota para um cliente se ela corresponder a um dos clientes iroutes.
Você precisaria de entradas de configuração como abaixo no respectivo cliente e servidores.
rota 192.168.3.0 255.255.255.0
Além disso, você pode precisar verificar o CCD se tiver várias redes por trás de vários clientes.
client-config-dir
Esta diretiva define um diretório de configuração do cliente, que o servidor OpenVPN verificará em cada conexão de entrada, procurando por um arquivo de configuração específico do cliente (consulte a página de manual para obter mais informações). Os arquivos neste diretório podem ser atualizados imediatamente, sem reiniciar o servidor. Observe que as alterações nesse diretório só terão efeito em novas conexões, não em conexões existentes. Se você quiser que uma alteração no arquivo de configuração específico do cliente tenha efeito imediato em um cliente atualmente conectado (ou um que foi desconectado, mas onde o servidor não atingiu o tempo limite de seu objeto de instância), elimine o objeto de instância do cliente usando o gerenciamento interface (descrita abaixo). Isso fará com que o cliente se reconecte e use o novo arquivo client-config-dir
A resposta da Fossil era exatamente o que eu precisava e já aceitei. Gostaria apenas de acrescentar algumas informações para outras pessoas que possam ter o mesmo problema. Porque a pergunta foi feita antes em serverfault, mas as respostas não mencionam iroute ( um exemplo ) ou têm apenas links mortos (como este )
Então... em primeiro lugar, encontrei uma boa explicação sobre o irout (e por que ele é necessário) aqui . Mas como acabei de mencionar o risco de links ficarem inativos, também tentarei mencionar as ideias mais importantes abaixo.
Parece que as rotas do kernel não são suficientes para o tráfego passar por um túnel OpenVPN. Se você deseja alcançar uma LAN que está atrás de um cliente OpenVPN, também precisa de uma rota interna OpenVPN (route). Isso é adicionado usando uma instrução client-configuration-dir em server.conf e adicionando as instruções irout nos arquivos de configuração colocados dentro desse subdiretório.
No meu caso, eu também precisava de:
Isso também levanta um problema interessante - se o OpenVPN não pode funcionar usando apenas rotas de kernel, parece à primeira vista que é impossível executar um protocolo de roteamento no topo dos túneis ovpn. Alguém conseguiu essa solução (ovpn+rip/ospf) funcionando?