Problema de roteamento do kernel na máquina virtual Ubuntu 14.04

Question

Estamos tendo alguns comportamentos de rede estranhos em algumas VMs Linux (baseadas em nuvem, vários provedores, principalmente Ubuntu 14.04 e 16.04). Temos duas redes distintas com um gateway Strongswan intermediário.

Site A: Rede - 10.104.16.0/20 Gateway e roteamento de VPN configurados no roteador principal (não conf necessário em máquinas virtuais)

Site B: Rede - 10.240.132.0/25 Gateway Strongswan - 10.240.132.15 Roteamento configurado por VM, dependendo da necessidade (ou não) de se comunicar com o Site A

Tabela de roteamento do kernel em uma das VMs no Site B que precisam se comunicar com VMs do Site A:

# route -vn
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.240.132.1    0.0.0.0         UG    0      0        0 eth0
10.104.16.0     10.240.132.15   255.255.240.0   UG    0      0        0 eth0
10.240.132.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0

E agora, a questão ... Quando tudo funciona bem, a VM faz ping de VMs no Site A e é isso que o comando traceroute gera:

# traceroute 10.104.19.4
traceroute to 10.104.19.4 (10.104.19.4), 30 hops max, 60 byte packets
 1  10.240.132.15 (10.240.132.15)  0.248 ms  0.228 ms  0.220 ms
 2  * * *
 3  10.104.19.4 (10.104.19.4)  15.048 ms  15.042 ms  15.028 ms

Então, de repente, a VM não conseguiu executar ping nos recursos do Site A e a saída do traceroute se pareceria com isso:

# traceroute 10.104.19.4
traceroute to 10.104.19.4 (10.104.19.4), 30 hops max, 60 byte packets
 1  10.104.19.4 (10.104.19.4)  0.552 ms  0.567 ms  0.616 ms
 2  * 10.104.19.4 (10.104.19.4)  0.659 ms  0.707 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *^C

Parece completamente aleatório tho. Quando isso acontecer, eu removerei e adicionarei a rota novamente com:

# route del -net 10.104.16.0 gw 10.240.132.15 netmask 255.255.240.0
# route add -net 10.104.16.0 gw 10.240.132.15 netmask 255.255.240.0

É claro que isso resolve o problema por um tempo não dura muito tempo ... Alguma idéia do que poderia dar errado ou do que estou fazendo errado?

Obrigado a vocês;)

    

Answer 1

Ok, não importa ... Depois de perceber que a conexão seria perdida a cada 5 minutos precisamente, às 9:00, 9:05 AM, 9:10 AM ... Eu dei uma olhada nos logs do Strongswan e descobri que ele iria reiniciar o serviço nesses momentos (processo recebendo um comando SIGKILL).

Tivemos uma conversa com o líder da equipe e ele disse

Hum we might have a cron job on the strongswan server pinging a remote IP and rebooting the service if the remote IP cannot be found.

Sim, de fato. E como esse IP remoto desapareceu há muito tempo e ninguém desabilitou ou atualizou esse trabalho não documentado, ele estava reiniciando o serviço desde, bem, desde o início. Até percebermos o problema ao replicar um banco de dados do Postgres.