Linux perde conectividade com outras redes ao ativar redundância no gateway

arch_roker
(usa Arch Linux)

Enviado em 18/06/2014 - 10:43h

Fala galera,

Sou novato aqui no VOL, já conhecia o portal pois sempre procurei soluções linux e mikrotik por aqui mas só agora resolvi me cadastrar. Espero que minhas dúvidas também sejam uteis para outros com problemas semelhantes e que eu possa contribuir com o conhecimento que já tenho.

Sem mais falação, vamos ao problema:

Já fazem alguns dias que me deparei com um problema estranho, já pesquisei em vários fóruns e não encontrei nada a respeito disso.
Eu administro uma VPN que interliga algumas lojas de um cliente.
Tenho instalado em cada loja um mikrotik que faz papel de gateway e, dentro dele, 2 VPNs sendo uma saindo por um link principal e uma outra por um link redundante. Através de scripts, o mikrotik testa e chaveia as duas conexões. Toda a comunicação é feita por roteamento sem NAT. O script funciona perfeitamente, simulei varias vezes quedas nos dois link e a comunicação se manteve perfeita.

Também tenho alguns caixas usando Ubuntu Server 12.04.4 LTS com kernel 3.11 32-bits e máquinas no setor administrativo que utilizam Windows.

As máquinas windows nem perdem pacotes quando ocorre o chaveamento da VPN. Já os caixas Ubuntu perdem comunicação com hosts das outras redes.

Vamos usar o seguinte cenário:

Loja A
Rede: 10.0.1.0/24
Mikrotik: 10.0.1.254
Caixa testado: 10.0.1.15

Loja B
Rede: 10.0.2.0/24
Mikrotik: 10.0.2.254
Host testado: 10.0.2.10

Teste feito:
Ping constante a partir do 10.0.1.15 para 10.0.2.10

PING 10.0.2.10 (10.0.2.10) 56(84) bytes of data.
64 bytes from 10.0.2.10: icmp_seq=1 ttl=64 time=2.20 ms
64 bytes from 10.0.2.10: icmp_seq=2 ttl=64 time=3.25 ms
64 bytes from 10.0.2.10: icmp_seq=3 ttl=64 time=3.34 ms
64 bytes from 10.0.2.10: icmp_seq=4 ttl=64 time=3.07 ms
64 bytes from 10.0.2.10: icmp_seq=5 ttl=64 time=3.22 ms
64 bytes from 10.0.2.10: icmp_seq=6 ttl=64 time=3.17 ms
<------Primeiro chaveamento entre as VPNs------------->
64 bytes from 10.0.2.10: icmp_seq=9 ttl=64 time=45.44 ms
64 bytes from 10.0.2.10: icmp_seq=10 ttl=64 time=48.30 ms
64 bytes from 10.0.2.10: icmp_seq=11 ttl=64 time=47.18 ms
64 bytes from 10.0.2.10: icmp_seq=12 ttl=64 time=42.13 ms
64 bytes from 10.0.2.10: icmp_seq=13 ttl=64 time=44.50 ms
64 bytes from 10.0.2.10: icmp_seq=14 ttl=64 time=49.13 ms
<-------Segundo chaveamento entre as VPNs------------->
From 10.0.1.15 icmp_seq=17 Destination Host Unreachable
From 10.0.1.15 icmp_seq=18 Destination Host Unreachable
From 10.0.1.15 icmp_seq=19 Destination Host Unreachable
From 10.0.1.15 icmp_seq=20 Destination Host Unreachable
From 10.0.1.15 icmp_seq=21 Destination Host Unreachable
From 10.0.1.15 icmp_seq=22 Destination Host Unreachable
From 10.0.1.15 icmp_seq=23 Destination Host Unreachable

Logo após o chaveamento o host 10.0.2.10 parou de responder como se o próprio 10.0.1.15 estivesse derrubando os pacotes antes mesmo de enviá-los pela interface de rede. Tentei pingar um segundo host (10.0.2.11) e respondia normalmente.

PING 10.0.2.11 (10.0.2.11) 56(84) bytes of data.
64 bytes from 10.0.2.11: icmp_seq=1 ttl=64 time=6.50 ms
64 bytes from 10.0.2.11: icmp_seq=2 ttl=64 time=4.38 ms
64 bytes from 10.0.2.11: icmp_seq=3 ttl=64 time=3.47 ms
64 bytes from 10.0.2.11: icmp_seq=4 ttl=64 time=3.19 ms
64 bytes from 10.0.2.11: icmp_seq=5 ttl=64 time=3.17 ms
64 bytes from 10.0.2.11: icmp_seq=6 ttl=64 time=3.44 ms
64 bytes from 10.0.2.11: icmp_seq=7 ttl=64 time=3.19 ms
64 bytes from 10.0.2.11: icmp_seq=8 ttl=64 time=3.16 ms
64 bytes from 10.0.2.11: icmp_seq=9 ttl=64 time=3.15 ms
64 bytes from 10.0.2.11: icmp_seq=10 ttl=64 time=3.17 ms
64 bytes from 10.0.2.11: icmp_seq=11 ttl=64 time=3.16 ms
64 bytes from 10.0.2.11: icmp_seq=12 ttl=64 time=3.16 ms

Logo cheguei a conclusão que quando há o chaveamento durante a comunicação entre dois host o kernel, imagino eu, identifica a mudança no caminho e começa a derrubar os pacotes para aquele host em específico assumindo ser um ataque de IP Spoofing. O que não me fez sentido foi que no primeiro chaveamento a comunicação se manteve perfeita mas no segundo não.

Tentei desativar o rp_filter (Reverse Path Filter), tentei reiniciar o serviço de rede, tentei derrubar e levantar a interface, tentei limpar o routing cache mas nada adiantava. Somente após reiniciar a máquina que o outro host 10.0.2.10 voltou a responder.

Fiz exatamente o mesmo teste em todos os caixas e todos tiveram o mesmo resultado.
Por via das dúvidas, testei com outras distros (Arch Linux e Fedora), testei com outra versão de kernel (3.13 e 3.14) e sempre tive o mesmo resultado. Funciona no primeiro chaveamento mas no segundo não.

Cheguei a pensar que o problema poderia estar no mikrotik mas o fato das máquinas windows funcionarem perfeitamente com os chaveamentos me fez descartar essa ideia.

Eu não conheço o kernel linux tanto quanto gostaria e me vi sem alternativas em relação a este problema. Agradeço desde já se alguém puder me ajudar.

Buckminster
(usa Debian)

Enviado em 18/06/2014 - 14:30h

Verifique no firewall dos servidores da rede dos dois IPs (10.0.1.15 e 10.0.2.10) se não tem alguma regra derrubando a comunicação.

Execute route -n e/ou netstat -rn para ver as rotas.

Apesar de que não está me parecendo um problema de rotas, tu criou as rotas para essas redes no Mikrotik em Ip > routes?

As máquinas estão com IP estático ou dinâmico?

arch_roker
(usa Arch Linux)

Enviado em 24/06/2014 - 09:28h

Desculpe a demora para a resposta, infelizmente na minha cidade o serviço de internet é horrível e fico dependente de usar a internet da minha empresa pra conseguir fazer alguma coisa.

Bom, vamos lá:


Em cada loja, estou usando o próprio mikrotik como gateway para internet. O firewall do mikrotik está limpo nas chains de Output e Forward com política permissiva. A chain Input possui uma regra liberando qualquer atividade entre os IPs externos das lojas, esta regra está no topo. Logo abaixo tenho um regra que permite a comunicação das redes dentro da VPN com o próprio mikrotik. A política da chain INPUT está restritiva. Já chequei varias essas regras inclusive montei um estudo dessas regras com packet flow para tentar identificar algum ponto em que isso pudesse estar interferindo. Sem resultados até agora...



Seguem as tabelas de rotas dos dois hosts:




Como pode ver, possuem apenas o mikrotik de cada loja com gateway e nada mais.


Sim, tenho rota pra cada uma das lojas em cada um dos mikrotiks.


Todas as máquinas estão com IP estático, até tenho uma faixa pequena de DHCP rodando mas é raramente usado, tudo fechado por MAC.

Buckminster
(usa Debian)

Enviado em 24/06/2014 - 18:38h

Tu criou essas VPNs com o próprio Mikrotik?

Como tu acessa a VPN com o Windows?

E como tu acessa com o Linux?

arch_roker
(usa Arch Linux)

Enviado em 25/06/2014 - 08:49h

As VPNs são gerenciadas pelo Mikrotik, as máquinas (tanto Linux quanto Windows) não recebem nenhuma configuração relacionada a VPN.