Грешка за слаб шифър във 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

Третата команда съобщава за файлове, които вече не съответстват на пакета, и точно така забравената обвивка се издава. Четвъртата показва отстъпките, които профилът носи, за да не може изключение тихо да се разпространи към втори профил чрез копиран файл. Изпълнете и двете преди и след промяна и пазете изхода с профила на връзката, а не в чат прозорец.

Дръжте debug изхода извън тикетите, докато някой не го прочете, защото ръководството предупреждава, че най-високото ниво на debug изхвърля данни за удостоверяване, включително пароли. Критерият за приемане е разрешено, поддържано споразумение между клиента и шлюза, а не меню елемент, който най-накрая става зелен. Ако партньорът предлага само счупен алгоритъм, честният резултат е изключение с крайна дата или заместващ протокол и това решение принадлежи на този, който притежава шлюза. Записването на решението е разликата между управлявано изключение и случайна промяна на политиката.