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

Разделите три утверждения

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

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

ClaimEvidence that settles itWho owns the change
Software defectAdvisory naming affected versionsPackage or product maintainer
Provider buildRelease notes for that clientThe provider
Profile omissionThe configuration actually loadedWhoever owns the profile

Найдите исполняемый файл, который действительно работает

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

systemctl cat openvpn-client@*.service
ps -o pid,cmd -C openvpn
apt-cache policy openvpn network-manager-openvpn

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

Доказательства из пакета вместо впечатлений о версии

Обслуживание безопасности дистрибутивов часто переносит исправления назад, поэтому более старая на вид версия upstream может всё ещё содержать патч. Верно и обратное: пакет из незнакомого репозитория не имеет автоматического права на текущее обслуживание. Читайте статус поддержки выпуска, а не номер версии.

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

Конфигурация — вторая половина

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

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

Решайте по доказательствам в записи

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

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

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