Eu tenho um servidor HP DL385p do CentOS 7 (anteriormente CentOS 6) que é conectado por meio de uma única NIC (usando o conversor SFP para cobre) na LAN local.
Além disso, ele usa o cliente VPN F5 para pesquisar informações de um local remoto seguro.
Ele também tem um contêiner docker rodando Nginx com PHP.
O problema que estou vendo é o seguinte.
O servidor inicializa, conecta-se à rede e é capaz de se comunicar com dispositivos na Internet e também nas LANs internas, quando permitido.
Em seguida, conectamos o F5 vpn, com certeza ainda conseguimos alcançar o mesmo que os dispositivos, mas com a adição dos dispositivos remotamente protegidos via vpn.
Isso será deixado em execução por algum tempo e, de repente, o servidor não conseguirá se comunicar com outra coisa que não seja a sub-rede local à qual está conectado.
Examinar as mensagens, dmesg e journalctl ( journalctl --this-boot --all --no-pager ) não revela nada de relevância óbvia além da interface tun0 utilizada pela f5 vpn como sendo 'removida'.
NetworkManager[1047]: <info> (tun0): device state change: activated -> unmanaged (reason 'removed') [100 10 36]
No entanto, o F5 vpn (f5fpc) relata que não fez nenhuma alteração (ficou aguardando para reconectar) e enquanto este é o único registro mostrado (de qualquer relação aparente com o problema), acredito que esta não é a causa, mas simplesmente um sintoma do problema.
O que quero dizer é que eu acredito que a VPN da F5 está se desconectando porque o requisito subjacente passou - a capacidade de se comunicar fora da sub-rede local (incluindo dispositivos BIG-IP remotos).Se eu verificar a tabela de roteamento do servidor, as rotas aparecem bem - tendo uma rota padrão para um dispositivo de gateway válido (que ainda pode ser acessado).
A interface também mostra como sendo endereçada corretamente e instalada e funcionando em iproute2 e net-tools.
A solução mais rápida para resolver temporariamente (sem um prazo previsível para a próxima ocorrência) é executar systemctl restart networking e depois reconectar a VPN F5 quando a conectividade for restaurada.
Estou um pouco perplexo e o que ver a seguir e como eu poderia aumentar a verbosidade no journalctl ou do NetworkManager sobre o que está acontecendo.
N.B: Eu me referi a ter o CentOS 6 anteriormente (não usando o NetworkManager) e a mesma coisa aconteceu lá, eu atualizei acreditando que era possivelmente o Kernel 2.6 ou talvez drivers mais antigos. O CentOS 7 parece incluir drivers be2net suficientes para o NIC, como visto em lsmod. Também mencionei o docker apenas para fornecer o máximo de detalhes possível (na medida em que sou permitido).
Editar: eu postei no devcentral caso o problema esteja relacionado ao cliente VPN F5 - link
Editar 2:
Tabela de roteamento sem VPN:
default via 192.168.3.254 dev eno1 proto static metric 100
192.168.0.0/22 dev eno1 proto kernel scope link src 192.168.0.22 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
Tabela de roteamento com:
default via 192.168.3.254 dev eno1 proto static metric 100
192.168.0.0/22 dev eno1 proto kernel scope link src 192.168.0.22 metric 100
192.168.3.254 via 192.168.0.22 dev eno1 proto none metric 1
10.0.0.0/16 via 10.112.194.63 dev tun0 proto none metric 1
10.1.0.0/16 via 10.112.194.63 dev tun0 proto none metric 1
10.2.0.0/16 via 10.112.194.63 dev tun0 proto none metric 1
10.3.0.0/16 via 10.112.194.63 dev tun0 proto none metric 1
10.4.0.0/16 via 10.112.194.63 dev tun0 proto none metric 1
10.5.0.0/16 via 10.112.194.63 dev tun0 proto none metric 1
10.6.0.0/16 via 10.112.194.63 dev tun0 proto none metric 1
10.7.0.0/16 via 10.112.194.63 dev tun0 proto none metric 1
10.8.0.0/16 via 10.112.194.63 dev tun0 proto none metric 1
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
x.x.x.x via 192.168.3.254 dev eno1 proto none metric 1
Último IP removido para privacidade.