OpenConnect может завершить рукопожатие туннеля и всё равно оставить вас без маршрута к частной подсети, потому что клиент и помощник, меняющий состояние локальной сети, — две разные программы. Аутентификация доказывает, что шлюз принял сеанс; она ничего не доказывает о том, какой интерфейс, какие маршруты или какие настройки распознавателя были установлены после этого. Большинство запутанных отчётов возникает из-за замены помощника копией из старого ответа, что меняет поведение каждого подключения на машине. Прежде чем что-либо в нём менять, найдите помощника, которого работающий клиент действительно вызывает.

Две программы, две ответственности

Клиент отвечает за транспорт, аутентификацию и устройство туннеля. Отдельный помощник отвечает за то, что происходит в локальной системе после появления туннеля: адресацию на интерфейсе, маршруты к подсетям, объявленным шлюзом, и настройку распознавателя. документация помощника OpenConnect описывает это разделение и среду, которую получает помощник. Различие важно при сбое, потому что отклонённый пароль и отсутствующий маршрут — не одно и то же событие, даже если рабочий стол показывает для обоих одно окно.

Память об этом разделении объясняет и то, почему подключение может сообщать об успехе, пока частные имена всё ещё не разрешаются. Туннель поднят в обоих случаях, и различается только этап локальной интеграции.

Найдите помощника, которого использует работающий клиент

Путь задаётся при сборке пакета и может быть переопределён при каждом вызове, поэтому файл, который вы помните из другого дистрибутива, может не иметь к этому подключению никакого отношения. Спрашивайте работающий процесс, а не документацию, которая случайно открыта.

openconnect --version
ps -o args= -C openconnect
dpkg -L openconnect | grep -i script
ls -l /etc/vpnc/ 2>/dev/null

Если в строке процесса есть аргумент --script , этот файл важнее скомпилированного значения по умолчанию. Старые пути вроде /etc/vpnc/vpnc-script могут существовать и оставаться неиспользуемыми, поэтому их удаление или правка ничего не меняет в свежей сборке. Проверьте и дату изменения: помощник, которого годами никто не трогал, — сильный признак того, что работу выполняет значение по умолчанию из пакета.

Интеграция с NetworkManager — третий владелец, со своим помощником и своими настройками профиля. Добавление второго скрипта маршрутов или распознавателя поверх этой интеграции дублирует маршруты и оставляет распознаватель, которым, по утверждению двух программ, управляют обе. Выберите одного владельца на подключение и отключите другого перед проверкой.

Читайте первую неудачную операцию, а не последнее предупреждение

Настройка интерфейса, установка маршрутов, выбор распознавателя и очистка устаревшего состояния — отдельные шаги, и последнее напечатанное предупреждение часто является жалобой на очистку, а не сбоем, разорвавшим соединение. Читайте вверх до первой конкретной неудачной операции. Ошибка помощника, называющая файл или адрес, ценнее десяти строк шума от разборки.

Сравните предполагаемый локальный результат с наблюдаемым: устройство туннеля существует, маршрут к известному частному адресу идёт через него, а распознаватель отвечает за частное имя. Помощник, который справляется с первыми двумя и терпит неудачу на третьем, указывает на политику распознавателя, а не на маршрутизацию. Помощник, который вовсе не настраивает устройство, вероятно, никогда не запускался, и это вопрос прав, а не сети. Подтвердите бит исполнения и служебную учётную запись, прежде чем переписывать любую логику.

Проверьте подключение, переподключение и отключение

Настройка — лишь половина договора, потому что тот же помощник должен восстановить или удалить состояние, которым владеет, когда туннель закрывается. Помощник, который добавляет маршруты и никогда их не удаляет, оставляет машину с устаревшим путём, переживающим сеанс.

ip -brief address show tun0
ip route get 10.24.8.15
resolvectl status tun0
journalctl -u NetworkManager -b --no-pager | grep -i -E 'vpnc|script'

Выполните первые три строки, пока подключены, отключитесь, затем выполните их снова и убедитесь, что маршрут и запись распознавателя исчезли. Четвёртая строка показывает, вызывался ли помощник вообще и какой исполняемый путь использовала служба. Сохраните эту пару выводов в заявке, потому что именно сравнение до и после делает ошибку очистки очевидной.

Держите помощника упакованным и исполняемым для служебной учётной записи, потому что скрипт, работающий в вашей оболочке, всё равно может быть отклонён при ограниченной служебной политике. Когда настройка действительно нужна, задокументируйте её цель и владельца и сравнивайте с упакованной версией при каждом обновлении. Необъяснённый форк помощника — одна из немногих вещей, способных заставить работающее подключение отказать через год.

Похожие статьи