Selhání HMAC autentizace paketu OpenVPN: která vrstva?

Dvě selhání se hlásí stejným slovníkem a nemají téměř nic společného. Jedno je paket, jehož autentizační značka se neověřila; druhé je člověk, jehož přihlašovací údaje byly odmítnuty. Když první považujete za druhé, hledáte heslo, které nikdy nebylo problémem.

Zpráva pojmenovává vrstvu a užitečná práce je rozhodnout kterou, než nahradíte jakýkoli materiál. Porovnání kandidátů vedle sebe je nejrychlejší způsob, jak rozdíl uvidět.

Dvě selhání, která sdílejí slovo

Chyba autentizace paketu vzniká při zpracování provozu: značka nebo otisk v přijatém paketu nesouhlasily s tím, co příjemce spočítal. Odmítnutí účtu přichází po zpracování přihlašovací výměny a jmenuje uživatele, nikoli paket. Třetí zpráva, o nemožnosti najít HMAC v příchozím paketu, je zase jiná, protože tam paket dorazil úplně bez očekávaného autentizačního prvku. Celá předpona záznamu vám řekne, který ze tří máte, a předpona bývá první věc, která se smaže, když se chyba vloží do tiketu.

Rozdíl mění opravu. Jedno volá po sladění nastavení kanálu, druhé po stavu účtu a třetí po profilu, který neodpovídá posluchači, k němuž se dostal.

Porovnejte, co běžící proces skutečně načetl

Správný soubor na disku nic nedokazuje o procesu, který začal před jeho úpravou. Zkontrolujte vybraný profil, koncový bod, se kterým se spojil, a zda byla služba od změny znovu načtena. Potvrďte také, že koncový bod patří profilu, protože jiná instance nebo jiná služba může naslouchat tam, kde starý soubor čeká něco jiného.

Opětovný export podporovaného profilu ze stejného zdroje je levné porovnání, protože odstraní rozdíl mezi tím, co považujete za nakonfigurované, a tím, co klient skutečně posílá. Generování nového klíčového materiálu je mnohem větší krok a pomůže jen tehdy, když ho obě strany přijmou společně. Nahrazení jedné strany lokálně znovu vytvoří neshodu, kterou jste se snažili odstranit.

Porovnejte řídicí kanál s datovým kanálem

Dva mechanismy autentizují různé části spojení a konfigurují se odděleně, jak reference voleb 2.6 popisuje. tls-auth přidává HMAC k paketům řídicího kanálu a přijímá argument směru, který musí být na obou protějšcích opačný, zatímco tls-crypt chrání řídicí kanál místo toho sdíleným klíčem. Ani jeden není vlastní kontrolou integrity datového kanálu. U AEAD šifry dat je tato kontrola vestavěná v šifře, takže samostatný auth otisk se nepoužívá tak jako u šifry, která AEAD není.

To znamená, že auth řádek zkopírovaný z funkčního nasazení bez AEAD může být v AEAD nasazení nepodstatný a AEAD nasazení může na řídicím kanálu stále selhat, pokud tls-auth je klíč nebo jeho směr špatný. Porovnávejte každé nastavení s protějškem, ne se zapamatovanou konfigurací.

Porovnejte opravu s vlastností, které se vzdáváte

Vypnutí autentizace paketů utiší varování a odstraní kontrolu, která neshodu našla, což není totéž jako opravit profil. Ptejte se, které vlastnosti se vzdáváte a zda návrh bez ní obstojí.

Přečtěte si první relevantní událost na obou koncích, než cokoli změníte, a pak změňte jen neshodu, kterou pojmenovává.

Pokud se další pokus posune k chybě certifikátu nebo přihlášení, je to pokrok, ne regrese: vrstva paketů už souhlasí a spojení postoupilo dál. Zapište nastavení, která změnu způsobila, aby další člověk zdědil vysvětlení místo záhady.