Маршруты удаляются при подключении к нескольким VPN соединениям
Это могло быть вызвано разными причинами. Я бы проверил все следующее:
- Доступна ли файловая система только для чтения? Проверьте, вызвав
mountили просмотрев/ proc / self / mounts? - Является ли файловая система локальной файловой системой? Сетевые файловые системы часто ограничивают root.
- Действительно ли вы root или ваш набор возможностей ограничен? Проверьте, запустив
capsh --print. - Вы используете selinux? Проверьте, возвращает ли
getenforceEnforcing. - Если вы используете selinux, вы ограничены? Отметьте
id -Z, который должен вернуть что-то вродеunlimited_u: unlimited_r: unlimited_t: s0-s0: c0.c1023, если вы не ограничены. - Вы уверены, что нет никаких странных атрибутов? Убедитесь, что
lsattrне возвращает никаких необычных битов.
VPN-клиенты явно конкурируют друг с другом за таблицу маршрутизации.
Они также возятся с маршрутами и шлюзами по умолчанию, причем очевидно, что последний загруженный имеет преимущество в том, что он находится в позиции изменения маршрутов, созданных первым.
Наконец, после загрузки последнего VPN-клиента отсутствие маршрутов/различных путей связи может привести к путанице во времени согласования/таймерах поддержания активности первого клиента.(и это само по себе также может объяснить исчезновение маршрутов ).
Как вы выяснили, не совсем кошерно запускать несколько VPN-клиентов одновременно в одном и том же клиенте, и даже больше, если они реализуют полные туннельные VPN.
Один из шансов, что вам, возможно, придется попытаться запустить их одновременно, заключается в том, что вы возитесь с таблицей маршрутизации после их завершения. Однако это, вероятно, должно быть заскриптовано, так как у вас очень мало времени, если это возможно сделать.
Боюсь, описанные вами в вопросе симптомы — это просто стандартное поведение.
ПС. Я возился с маршрутами клиента Ckeckpoint в Linux, и из эмпирических и теоретических знаний я знаю, что у меня есть ограниченное время, прежде чем клиент/брандмауэр решит, что соединение испортилось.