У меня есть сервер HP DL385p CentOS 7 (ранее CentOS 6), который подключен через одну сетевую карту (с использованием преобразователя SFP в медь) к локальной сети.
Кроме того, он использует клиент F5 VPN для опроса информации из безопасного удаленного места.
В нем также есть докер-контейнер, на котором работает 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) сообщает об отсутствии изменений (он сидел в ожидании повторного подключения), и хотя это единственный показанный журнал (любого очевидного отношения к проблеме), я считаю, что это не причина, а просто симптом эта проблема.
Я имею в виду, что я считаю, что vpn F5 отключается, потому что исчезло основное требование - возможность общаться за пределами локальной подсети (включая удаленные устройства BIG-IP).
Если я проверю таблицу маршрутизации сервера, маршруты будут выглядеть нормально - с маршрутом по умолчанию к действительному шлюзу (до которого он все еще может добраться).
Интерфейс также отображается как правильно адресованный и работающий в iproute2 и net-tools.
Самое быстрое решение для временного решения (без предсказуемого периода времени, когда это произойдет в следующий раз) - запустить systemctl restart networking а затем повторно подключите F5 VPN после восстановления связи.
Я немного озадачен, и на что смотреть дальше и как я могу увеличить подробность того, что происходит в journalctl или NetworkManager.
N.B: Я упоминал о CentOS 6 ранее (без использования NetworkManager), и там произошло то же самое, я обновился, полагая, что это, возможно, ядро 2.6 или более старые драйверы. CentOS 7, похоже, включает в себя достаточное количество драйверов be2net для сетевой карты, как показано в lsmod. Я также упомянул докер просто для того, чтобы предоставить как можно больше подробностей (насколько мне позволено).
Изменить: я написал на devcentral, если проблема связана с клиентом F5 VPN - https://devcentral.f5.com/questions/linux-big-ip-vpn-client-disconnecting-but-potential-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-адрес удален в целях конфиденциальности.