DH файл или tls-auth ключ? Как да различим два файла на OpenVPN

Два файла, две директиви и навикът и двата да се именуват по онова, което настройват. Така dh.pem се озовава на ред tls-auth и клиентът се проваля със съобщение за неочакван формат на ключа. Решението пред вас не е кой файл е по-силен. А коя роля е действително нужна на внедряването, и три условия го решават: какъв обмен на ключове ще договори вашият TLS стек, дали изобщо искате удостоверяване на контролния канал и дали материалът трябва да остане таен.

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

Прочетете етикета преди името на файла

Първият ред на файла е по-информативен от името му, защото името е човешка конвенция, а етикетът се създава от инструмента. Параметрите на Diffie-Hellman носят PEM етикет BEGIN DH PARAMETERS. Статичният ключ на OpenVPN е съвсем различна структура, със свой хедър и шестнадесетичен полезен товар.

Преименуването не преобразува нищо. Файл с параметри, наречен ta.key, пак е параметри, а статичен ключ, наречен dh.pem, пак е статичен ключ; парсерът чете съдържанието и отхвърля несъответствието. Проверете, преди да редактирате профила:

head -n 1 dh.pem
head -n 1 ta.key

Три условия, които решават кой файл ви трябва

Първото условие е обменът. Ръкостискането Diffie-Hellman в крайно поле се нуждае от група и директивата dh е мястото, където сървърът именува параметрите за нея. Ръкостискането по елиптична крива изобщо не се нуждае от този файл, защото кривата е наборът от параметри. Ако вашият сървър договаря само ECDHE пакети, DH файлът е мъртва тежест, а не допълнителна сила.

Второто условие е удостоверяването на контролния канал — отделна функция със собствен материал. Файлът tls-auth е споделен статичен ключ, който държат и двете страни, използван за подписване на пакетите на контролния канал, така че неудостоверен партньор дори да не може да завърши ръкостискането. Той съществува независимо дали използвате DH в крайно поле, и няма нищо общо с параметрите на групата.

Третото условие е тайната и разпространението. DH параметрите могат да се публикуват, без това да отслабва сесията, защото тайните стойности се генерират за всяко ръкостискане и никога не напускат партньорите. Статичен ключ не бива да се публикува: това са едни и същи байтове от двете страни, той не се сменя сам и всеки, който го държи, може да създава валидни подписи на контролния канал. Тези два отговора водят до напълно различни правила за работа, затова единият файл може да стои в хранилище, а другият — не.

Създайте правилния материал за всяка роля

Използвайте инструмента, който произвежда формата, очакван от директивата, вместо да преобразувате между тях. За споделения ключ в OpenVPN 2.6 типизираната форма на генератора изрично посочва предназначението.

openvpn --genkey tls-auth ta.key

Тази команда създава нов таен материал; тя не поправя и не проверява съществуващ ключ, а повторното ѝ пускане ви дава различен ключ, който другите партньори не притежават. Копирайте получения файл до партньорите, които се нуждаят от него, по канал, който бихте използвали за всяка споделена тайна, и поддържайте конвенцията за посока последователна: с tls-auth едната страна използва key-direction 0, а другата — key-direction 1.

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

Какво означава dh none и какво не

dh none е истинска директива с тесен смисъл: няма да се зарежда файл с параметри в крайно поле, защото ръкостискането използва Diffie-Hellman по елиптична крива. Тя не е съкращение за „пропусни стъпката DH“ в смисъл на отслабване на нещо и със сигурност не казва на OpenVPN да приеме друг файл като заместител.

Две грешки следват от погрешното ѝ четене. Първата е да се предполага, че dh none премахва нуждата от tls-auth, докато двете управляват различни неща. Втората е да се държи остарял ред dh до конфигурация само с крива и после да се чудим кой файл сървърът всъщност използва; ако директивата присъства, файлът се чете и счупен път там проваля стартирането по причина, несвързана с обмена, който ще бъде договорен.

Ако грешният файл вече е внедрен

Възстановете предвидената тайна от собственика на профила и не пипайте проверката на сертификата, докато го правите. Провалът е несъответствие във формата, а не провал в доверието, и изключването на проверката, за да се прескочи грешката, заменя проблем при стартирането с тих проблем.

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

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