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, и токму кон тоа упатуваа трите услови цело време.