Повечето спорове за хешовете на OpenVPN започват от грешния пакет. Да се чете auth SHA256 като „приемай само партньори, които предлагат SHA256“ е първото, което трябва да отучите. Опцията назовава хеш за определени пакети и кои са тези пакети зависи от канала и от това дали този канал е AEAD. Преминете през четирите въпроса по-долу по ред; всеки стеснява какво може да означава настройката в разгръщането ви.

Назовете канала, който настройката трябва да защитава

OpenVPN има контролен канал, който носи трафика на TLS ръкостискането, и канал за данни, който носи полезния товар на тунела. Хешът auth има роля и в двата, но не еднаква, и профилът рядко прави разликата видима. Запишете кой от двата се опитвате да ограничите, преди да пипнете конфигурационен файл.

Таблицата по-долу е кратката версия на това как същата опция попада във всеки контекст.

ContextWhat the auth digest does
Data channel without AEADSelects the HMAC digest that authenticates each data packet
Data channel with AEAD, such as GCMUnused for the data channel; the cipher authenticates its own packets
Control channel protected by tls-authSelects the HMAC digest for that protection, even when data is AEAD

Проверете дали каналът за данни е AEAD, преди да разчитате на него

Ако договореният шифър за данни е AES-GCM или CHACHA20-POLY1305, каналът за данни сам се удостоверява и отделният хеш не върши работата, която може би си представяте. И двете са AEAD конструкции, така че цялостта се създава от същата операция, която шифрова товара. Това не е понижение, но означава, че политика, обоснована като „всеки пакет с данни е HMAC-SHA256“, е фактически грешна за този тунел. Потвърдете договорената стойност в журнала на сървъра или в изхода за състоянието на клиента, преди да пренапишете политиката.

Проверявайте шифъра, който действително е договорен, а не списъка в профила, защото договарянето може да попадне на друг член от набора. data-ciphers AES-256-GCM:AES-128-GCM е списък за договаряне и двата записа са AEAD, така че нито един от тях не изразходва хеша auth за защита на товара.

Третирайте защитата на контролния канал като самостоятелно решение

tls-auth добавя HMAC към пакетите на контролния канал и взема хеша си от настройката auth, затова един AEAD тунел все още може да има смислен хеш. tls-crypt е различна подредба със собствена фиксирана защита, така че не предполагайте, че наследява всички свойства на tls-auth. Четете документацията за механизма, който сте избрали, вместо да прехвърляте предположения между тях.

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

Дръжте auth отделно от договарянето на шифри и сертификатите

Три настройки постоянно се бъркат: хешът auth, списъкът с шифри за данни и алгоритъмът за подпис на сертификата. Промяната на първата не преиздава сертификат, не избира неговия хеш за подпис и не създава метод с потребител и парола. Дефинициите на протоколните опции в източниците на OpenVPN 2.6 описват всяка в свой раздел, което е полезно напомняне, че те са независими копчета.

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

Запишете политиката и я сравнете с работещите конфигурации

Изявление на ниво флот трябва да назовава разрешените режими на канала за данни и избраната защита на контролния канал изрично, в едно изречение. Това изречение е проверимо; „използваме SHA256“ не е. След това го сравнете с действителните профили на сървъра и клиента, а не с шаблон в хранилище.

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

Подобни статии