Tenho uma VPN site a site configurada usando OpenVPN. O túnel parece funcionar bem (e posso fazer ping 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)
Posso fazer ping 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, sou completamente incapaz de fazer o contrário (fazer ping em 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
IPTables não está bloqueando nada (tudo está configurado para ACCEPT):
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 chegando 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, instalados principalmente com os padrões).
Achei que sabia um pouco sobre redes Linux, mas... parece que 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?
Obrigado!
Responder1
Você pode estar perdendo o iroute. Além de enviar rotas, você precisaria iroutede 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, será padronizado como 255.255.255.255. Esta 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 (como 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 é encaminhada para o cliente específico. Esta opção deve ser especificada em um arquivo de configuração da 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 (chamaremos esse cliente de A). Se você quiser que outros clientes possam acessar a sub-rede 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, uma vez que a sub-rede já pertence a A. O OpenVPN faz isso não enviando uma rota para um cliente se ela corresponder a uma das rotas do cliente. rotas.
Você precisaria de entradas de configuração como abaixo nos respectivos clientes 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 atrás de vários clientes.
diretório-configuração do cliente
Esta diretiva define um diretório de configuração do cliente, que o servidor OpenVPN irá verificar em cada conexão de entrada, procurando por um arquivo de configuração específico do cliente (veja a página do manual para mais informações). Os arquivos neste diretório podem ser atualizados dinamicamente, sem reiniciar o servidor. Observe que as alterações neste diretório só terão efeito para novas conexões, não para conexões existentes. Se desejar que uma alteração no arquivo de configuração específica do cliente tenha efeito imediato em um cliente conectado no momento (ou em 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 método de gerenciamento interface (descrita abaixo). Isso fará com que o cliente se reconecte e use o novo arquivo client-config-dir
Responder2
A resposta da Fossil era exatamente o que eu precisava e já aceitei. Gostaria apenas de adicionar algumas informações para outras pessoas que possam ter o mesmo problema. Porque a pergunta foi feita antes sobre serverfault, mas as respostas não fazem menção a iroute (um exemplo) ou ter apenas links inativos (comoEste)
Então... em primeiro lugar, encontrei uma boa explicação sobre iroute (e por que ela é necessária)aqui. Mas como acabei de mencionar o risco de links inativos, também tentarei mencionar as ideias mais importantes a seguir.
Parece que as rotas do kernel não são suficientes para o tráfego passar por um túnel OpenVPN. Se você deseja acessar uma LAN que está atrás de um cliente OpenVPN, você também precisa de uma rota interna OpenVPN (iroute). Isso é adicionado usando uma instrução client-configuration-dir em server.conf e adicionando as instruções iroute nos arquivos de configuração colocados dentro desse subdiretório.
No meu caso, eu também precisava de:
#Inside server.conf
client-configuration-dir my-config-dir
#Inside my-config-dir/client1 (same name as the client!)
#Tell OpenVPN that 192.168.13.0/24 is reachable via client1
iroute 192.168.13.0 255.255.255.0
Isto também levanta uma questão interessante - se o OpenVPN não puder funcionar usando apenas rotas de kernel, à primeira vista parece que é impossível executar um protocolo de roteamento sobre os túneis ovpn. Alguém conseguiu essa solução (ovpn + rip/ospf) funcionando?