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

Две грешки се пријавуваат со иста терминологија и речиси немаат ништо заедничко. Едната е пакет чија автентикациска ознака не се потврди; другата е лице чии акредитиви беа одбиени. Третирањето на првата како втора ве праќа да барате лозинка што никогаш не била проблем.

Пораката именува слој, а корисната работа е да одлучите кој пред да замените каков било материјал. Споредувањето на кандидатите еден покрај друг е најбрзиот начин да ја видите разликата.

Две грешки што делат еден збор

Грешка во автентикацијата на пакет се јавува при обработка на сообраќај: ознака или дигест на примен пакет не одговараше на она што го пресметал примачот. Одбивање на сметка се случува откако ќе се анализира размената за најава и именува корисник, а не пакет. Трета порака, за неможноста да се најде HMAC во дојдовен пакет, повторно е друга, бидејќи таму пакетот пристигна сосема без очекуваниот автентикациски елемент. Целосниот префикс на дневникот ви кажува кој од трите го имате, а префиксот обично е првото нешто што се отстранува кога грешката се лепи во тикет.

Разликата ја менува поправката. Едната бара усогласени поставки на каналот, другата состојба на сметката, а третата профил што не одговара на слушателот до кој стигна.

Споредете што навистина вчита процесот што работи

Точна датотека на дискот не докажува ништо за процес што започнал пред да биде уредена. Проверете го избраниот профил, крајната точка со која се поврза и дали услугата е повторно вчитана по промената. Потврдете и дека крајната точка му припаѓа на профилот, бидејќи друга инстанца или друга услуга може да слуша таму каде старата датотека очекува нешто друго.

Повторното извезување на поддржан профил од истиот извор е евтина споредба, бидејќи ја отстранува разликата меѓу она што мислите дека е конфигурирано и она што клиентот навистина го праќа. Генерирањето нов клучен материјал е многу поголем чекор и помага само ако двете страни го прифатат заедно. Замената на една страна локално повторно ја создава неусогласеноста што се обидовте да ја отстраните.

Споредете го контролниот канал со податочниот канал

Два механизми автентицираат различни делови од врската и се конфигурираат одделно, како што референцата за опции 2.6 опишува. tls-auth додава HMAC на пакетите на контролниот канал и прима аргумент за насока што мора да биде спротивен кај двата партнера, додека tls-crypt контролниот канал наместо тоа го штити со заеднички клуч. Ниту едно не е сопствената проверка на интегритетот на податочниот канал. Со AEAD шифра за податоци таа проверка е вградена во шифрата, па одделниот auth дигест не се користи како со шифра што не е AEAD.

Што значи дека auth ред копиран од работно не-AEAD распоредување може да биде неважен во AEAD распоредување, а AEAD распоредувањето сепак може да не успее на контролниот канал ако tls-auth клучот или неговата насока е погрешен. Споредете ја секоја поставка со партнерот, а не со запаметена конфигурација.

Споредете ја поправката со својството од кое се откажувате

Исклучувањето на автентикацијата на пакети го замолчува предупредувањето и ја отстранува проверката што ја најде неусогласеноста, што не е исто како поправка на профилот. Прашајте од кое својство се откажувате и дали дизајнот издржува без него.

Прочитајте го првиот релевантен настан на двата краја пред да промените нешто, потоа сменете ја само неусогласеноста што ја именува.

Ако следниот обид стигне до грешка со сертификат или најава, тоа е напредок, а не регрес: слојот на пакети сега се согласува и врската продолжи. Запишете ги поставките што ја предизвикаа промената, за да наследи следната личност објаснување наместо загатка.