CentOS - Сетевая карта внезапно не может связаться с устройствами за пределами локальной подсети
У меня есть сервер CentOS 7 (ранее CentOS 6) HP DL385p, который подключен через одну сетевую карту (с помощью преобразователя SFP к меди) к локальной сети.
Кроме того, он использует VPN-клиент F5 для опроса информации из безопасного удаленного местоположения.
Он также имеет док-контейнер, работающий на Nginx с PHP.
Проблема, которую я вижу, заключается в следующем.
Сервер загружается, подключается к сети и может обмениваться данными с устройствами в Интернете, а также во внутренних локальных сетях, где это разрешено.
Затем мы подключаем F5 vpn, конечно, все еще в состоянии достигнуть того же, что и устройства, но с добавлением удаленно защищенных устройств через vpn.
Это будет работать некоторое время, и внезапно сервер окажется не в состоянии связываться ни с чем, кроме локальной подсети, к которой он подключен.
Изучая сообщения, dmesg и journalctl (journalctl --this-boot --all --no-pager) не обнаруживает ничего очевидного и значимого, кроме интерфейса tun0, используемого f5 vpn как "удаленного".
NetworkManager[1047]: <info> (tun0): device state change: activated -> unmanaged (reason 'removed') [100 10 36]
Тем не менее, F5 vpn (f5fpc) сообщает об отсутствии изменений (он находится в ожидании повторного подключения), и хотя это единственный показанный журнал (какого-либо очевидного отношения к проблеме), я считаю, что это не причина, а просто симптом эта проблема.
Я имею в виду, что я полагаю, что F5 vpn отключается, потому что основное требование ушло - способность общаться вне локальной подсети (включая удаленные устройства BIG-IP).
Если я проверяю таблицу маршрутизации сервера, маршруты выглядят нормально - маршрут по умолчанию к действительному устройству шлюза (который он все еще может достичь).
Интерфейс также показывает, что он правильно адресуется и работает и работает в iproute2 и net-tools.
Самое быстрое решение для временного разрешения (без предсказуемого периода времени, когда это произойдет в следующий раз) - это запустить systemctl restart networking и затем переподключите F5 VPN после восстановления подключения.
Я немного озадачен и что посмотреть дальше, и как я мог бы увеличить многословие в Journalctl или из NetworkManager о том, что происходит.
NB: Я упоминал, что ранее имел CentOS 6 (не использовал NetworkManager), и там произошло то же самое, я обновил, полагая, что это, возможно, ядро 2.6 или, возможно, более старые драйверы. CentOS 7, кажется, включает в себя достаточное количество драйверов be2net для NIC, как видно из lsmod. Я также упомянул докер просто для того, чтобы предоставить как можно больше подробностей (насколько мне позволено).
Изменить: я отправил в devcentral в случае, если проблема связана с клиентом F5 VPN - https://devcentral.f5.com/questions/linux-big-ip-vpn-client-disconnecting-but-potentially-taking-down-the-local-nic-in-its-process-47920
Изменить 2:
Таблица маршрутизации без 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
Таблица маршрутизации с:
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
Последний IP удален для конфиденциальности.