Как OpenVPN data-ciphers избира шифъра на канала за данни

Тунелът се вдига, журналът показва шифър и прегледът на профила продължава. После при партньор пристига актуализация и същият профил се проваля със съобщение за липса на споделен шифър, което изпраща хората да търсят директива за изтриване. Полезното за разбиране е, че data-ciphers описва преговори, а не настройка. Едната страна предлага списък, другата избира от него, а резултатът е един алгоритъм, който и двете поддържат. Четенето на тази размяна обяснява повечето от тези откази, преди да промените ред.

Два канала, две конфигурации

Една OpenVPN сесия има контролен канал и канал за данни. Контролният канал изпълнява TLS ръкостискането, което удостоверява партньорите и договаря ключове. Каналът за данни криптира пакетите, които пренасят трафика ви.

data-ciphers конфигурира втория. Контролният канал има свои опции, а проверките на идентичността на профила са трето, отделно нещо. Промяната на едното не поправя другото, затова профилът може да изглежда правилен и въпреки това да се провали на определен етап.

Дръжте трите в отделни кутии, когато четете конфигурационен файл.

Прочетете преговорите от журнала

Журналът на клиента назовава двата резултата, когато връзката успее. Един ред съобщава за контролния канал и неговите TLS подробности, а друг — за избрания шифър на канала за данни.

Прочетете и двата, защото отговарят на различни въпроси. Отказ на контролния канал спира връзката, преди някой шифър за данни да стане важен. Несъответствие на канала за данни се появява след успешно ръкостискане, със съобщение за липса на споделен шифър.

След това сравнете предложените списъци от двете страни. Име, което версията на единия партньор или неговата криптографска основа не предоставя, не може да бъде избрано, без значение колко рано се появява в списъка на другия партньор.

Как всъщност става изборът

Сървърът изтласква своя списък data-ciphers към клиента по време на ръкостискането, а клиентът избира първия запис в този списък, който и той поддържа. Следователно редът принадлежи на конфигурацията на сървъра, а не на клиента.

Тази подробност обяснява клас объркващи резултати. Пренареждането на списъка на клиента не променя нищо, докато решава списъкът на сървъра. Добавянето на шифър, който клиентът не може да предостави, също не променя нищо, защото клиентът трябва да може да използва избрания запис.

По-новите издания промениха списъка по подразбиране и преименуваха опцията, която го държеше, така че двама партньори на различни версии могат да не се съгласят, без никой да редактира профил. Проверете версията от всяка страна, преди да предположите печатна грешка.

Списъкът не е класация на сила в абстрактния смисъл. Той е набор от кандидати, а избраният е първият взаимно поддържан запис в реда на сървъра. Затова два списъка, които изглеждат различни, могат да договорят един и същ шифър. Затова и два списъка, които изглеждат еднакви, могат да се провалят.

По-старите партньори се нуждаят от умишлен резервен вариант

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

Това не е същото като включването на всеки стар шифър, за да изчезне съобщение. Широкият списък отслабва сесията за всеки партньор, включително за тези, които биха договорили нещо силно.

Координирайте двете страни, вместо да редактирате несвързани имена на алгоритми. Ако актуализация на сървъра е премахнала стара опция, корекцията принадлежи на плана за версии, а не на бързане при клиента.

Запазете проверката непокътната

Несъответствието на канала за данни не е причина да приемете непроверен сървър. Проверката на сертификата, очакваното име на сървъра и настройките за защита на контролния канал са отделни от избора на шифър и трябва да оцелеят при всяка промяна на съвместимостта.

Запишете заедно договорения шифър за данни, версията на клиента и версията на сървъра, така че следващото сравнение да започне от факти, а не от файла на профила.

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

Ако тунелът се установи, а сайтовете все още не работят, шифърът вече не е заподозреният. Продължете с маршрутизацията и DNS. Ред на работа: прочетете двата реда в журнала, сравнете двата списъка, проверете версиите, добавете резервен вариант само за партньор, който се нуждае от него, и след това тествайте отново пътя за подновяване.