Бинарный файл pppd не найден: исправьте окружение, а не аутентификацию

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

Меню и демон — разные вещи

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

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

Читайте пакет, а не файл

Прежде чем что-либо трогать, проверьте состояние установленного пакета, его объявленные зависимости и ожидаемый список файлов. Пакетирование дистрибутивов документирует это явно, а пакет NetworkManager PPTP в Debian — полезный пример, потому что он зависит отдельно от пакета демона PPP и от клиента PPTP. Это унаследованная интеграция, а не рекомендация развёртывать PPTP сегодня. Она показывает, как помощник приходит как собственная зависимость, а не внутри клиента.

Различайте три режима отказа: пакет, который не установился, репозиторий, который не предлагает кандидата, и бинарный файл, установленный вручную вне собственности пакета. Им нужны разные исправления, и только первый исправляется переустановкой того же пакета.

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

dpkg -s network-manager-pptp | grep -E "Status|Depends"
dpkg -L ppp | grep -E "bin/pppd$"
command -v pppd; ls -l /usr/sbin/pppd

Исправьте окружение, не ломая другие

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

Установка другого VPN-клиента тоже не исправление. Она создаёт новое требование совместимости, оставляя исходный профиль без объяснения.

Если организация решила, что сам протокол должен уйти, это решение о миграции с ответственным. Это не шаг диагностики, и его не следует принимать в момент, когда соединение отказывает.

Считайте следующую ошибку новым этапом

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

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

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