VPN на Mac завис на «Отключение»: что на самом деле работает

Отключение — это переход, а не остановленный туннель. Проверьте, какой компонент владеет разбором, прочитайте маршруты и DNS и не убивайте процессы огульно.

«Отключение» — это состояние, которое клиент сообщает, пока разбирает туннель, а не приговор о том, что трафик остановился. На Mac такой разбор идёт короткой последовательностью, и метка меняется только после того, как компонент, владеющий соединением, отвечает. Когда один шаг ждёт помощника, плагин или решение политики, метка может остаться на месте после исчезновения интерфейса, либо туннель может продолжать передавать, пока меню ещё его показывает. Воспринимайте текст как «разбор идёт, результат неизвестен» и выясните, какая половина верна.

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

Что отслеживает метка

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

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

Найдите компонент, владеющий соединением

Для штатных конфигураций scutil --nc list выводит службы, известные системе, и их состояние, а scutil --nc status "Work VPN" даёт подробности по одной службе. Туннель, который держит стороннее приложение, может вообще не появиться в этом списке, поэтому пустой результат не доказывает, что ничего не подключено.

Если профиль принадлежит приложению, полагайтесь на его представление состояния и документированную кнопку «Отключить». Закрытие окна не является запросом на остановку, если туннелем владеет фоновый помощник; значок исчезает, а помощник сохраняет интерфейс живым. Справочник Apple по настройкам VPN описывает штатные элементы управления и происхождение управляемых настроек.

Читайте интерфейсы, маршруты и DNS

Три проверки отвечают на большую часть вопроса, не трогая соединение. Важно толковать их вместе, потому что каждая по отдельности вводит в заблуждение.

scutil --nc list
netstat -rn -f inet | head -20
ifconfig | grep -A 3 '^utun'
scutil --dns | head -30
  • интерфейс utun присутствует, через него идёт маршрут по умолчанию или разделённый маршрут, резолвер указывает на провайдера: туннель ещё поднят, а метка устарела.
  • нет utun, обычный маршрут по умолчанию, DNS из DHCP, интернета нет: политика, блокирующая при отключении, выполняет свою работу.
  • нет utun, нет маршрута, резолвер по-прежнему указывает на провайдера: разбор остановился на полпути, и DNS — это остаток, который нужно убрать.

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

Почему огульное убийство процессов и удаление профиля вводят в заблуждение

Имена процессов вроде pppd, racoon и configd принадлежат конкретным реализациям. Их убийство может затронуть другие соединения, оставляет маршруты и интерфейсы utun и не даёт никакой записи о том, на каком шаге всё застряло. Старое имя процесса тоже не доказывает, что оно владеет текущим профилем.

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

Последовательность остановки, оставляющая след

Порядок ниже оставляет в ответе собственные элементы управления соединения и создаёт запись, если зависание вернётся. Он также удерживает вас от превращения проблемы отображения в изменение сети.

  1. Сохраните удалённую работу и убедитесь, что можете добраться до Mac другим способом, если он удалённый.
  2. Запишите имя клиента, версию и профиль. Захватите короткое окно с помощью log show --last 5m --predicate 'subsystem == "com.apple.networkextension"'; старые версии хранят меньше истории, поэтому запустите это вскоре после зависания.
  3. Используйте документированную кнопку «Отключить», подождите, затем повторите проверки интерфейса и маршрутов.
  4. Если метка устарела, а туннель опущен, оставьте её и дайте клиенту обновиться, вместо того чтобы принудительно завершать процессы.
  5. Если разбор действительно завис, перезапустите клиент, а затем запланируйте перезагрузку Mac после сохранения работы. Управляемые машины требуют процедуры администратора.

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

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