Ошибка слабого шифра vpnc: политика шлюза или правка рабочего стола?

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

Два исправления с очень разным радиусом действия

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

Проверка пакета — первая жертва: файл в /usr/sbin/vpnc, который больше не соответствует своему пакету, превращает рутинное обновление безопасности в расследование. Затем обновления либо молча перезаписывают обёртку, либо отказываются применяться — в зависимости от того, как менеджер пакетов обращается с изменёнными файлами. Ни один из исходов не появляется в журнале подключения, поэтому подход с обёрткой остаётся привлекательным до первого инцидента. Одна строка в профиле гораздо легче находится и удаляется, чем двоичный файл, замену которого никто не помнит.

Что на самом деле делает устаревший переключатель

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

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

Где место ограниченному исключению

Если организация сознательно принимает старого партнёра на ограниченный срок, исключение принадлежит профилю этого партнёра — с владельцем, датой пересмотра и путём миграции на поддерживаемый протокол. Держать его вне глобального пути — в этом весь смысл названия «ограниченное».

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

Проверяйте согласование, а не только зелёный значок

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

vpnc --version
vpnc --print-config /etc/vpnc/legacy.conf
dpkg -V vpnc
grep -n -E 'weak|1des|no-encryption' /etc/vpnc/legacy.conf

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

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