OpenVPN сообщает, что ncp-disable неизвестен: что его заменило?

Клиент отказывается запускаться с ошибкой опций, в которой упомянут ncp-disable, хотя профиль работал на предыдущей машине. Это сообщение не означает, что опция написана с ошибкой или что шифрование сломано. Оно означает, что бинарный файл перед вами вообще не знает этой директивы, и для этого есть две очень разные причины. Какая из них действует, решает, будете вы править профиль или менять клиент.

Ошибка может исходить от более нового бинарного файла

Ошибка неизвестной опции относится к парсеру, а не к туннелю. OpenVPN 2.4 добавил согласуемые параметры шифрования, 2.5 объявил устаревшим переключатель, который их отключал, а 2.6 полностью его удалил. Поэтому профиль, написанный для 2.3 или 2.4, сбоит на текущем клиенте, даже если в файле ничего не менялось. Жалующаяся версия новее, а не старее.

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

openvpn --version решает это для проверяемого бинарного файла. GUI-клиент может не показывать эту команду, тогда прочитайте его экран «О программе» или версию встроенной библиотеки.

Чем на самом деле управляла опция

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

Когда согласование существует, эквивалентный вопрос — какие шифры каждая сторона готова использовать. Это вопрос политики, а политика живёт в data-ciphers начиная с 2.5.

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

Замените политику, а не написание

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

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

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

Две строки, которые выглядят как список шифров, но ими не являются

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

Проверяйте принимаемые имена с помощью openvpn --show-ciphers на целевом бинарном файле, а не копируйте список из руководства, написанного для другой ветки. Список меняется между выпусками. Имя, допустимое в одной ветке, не обязательно допустимо в другой.

Если целью было сравнение производительности, запишите алгоритмы и нагрузку. Переход на CBC не является измерением отсутствия шифрования.

Проверьте, что именно согласовало соединение

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

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