Неуспешна HMAC автентикация на пакет в OpenVPN: кой слой?

Два отказа се съобщават с една и съща лексика и почти нямат нищо общо. Единият е пакет, чийто етикет за автентикация не се е потвърдил; другият е човек, чиито идентификационни данни са били отказани. Ако третирате първия като втория, ще търсите парола, която никога не е била проблемът.

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

Два отказа, които делят една дума

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

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

Сравнете какво действително е заредил работещият процес

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

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

Сравнете контролния канал с канала за данни

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

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

Сравнете поправката със свойството, от което се отказвате

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

Прочетете първото значимо събитие от двете страни, преди да промените каквото и да е, после променете само несъответствието, което то назовава.

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