HMAC-verifiering av OpenVPN-paket misslyckades: vilket lager?

Två fel rapporteras med samma vokabulär och har nästan inget gemensamt. Det ena är ett paket vars autentiseringstagg inte verifierades; det andra är en person vars inloggningsuppgifter avvisades. Behandlar du det första som det andra letar du efter ett lösenord som aldrig var problemet.

Meddelandet namnger ett lager, och det användbara arbetet är att avgöra vilket lager det är innan du byter ut något material. Att jämföra kandidaterna sida vid sida är det snabbaste sättet att se skillnaden.

Två fel som delar ett ord

Ett paketautentiseringsfel uppstår under trafikbearbetning: en tagg eller sammanfattning på ett mottaget paket matchade inte det mottagaren beräknade. Ett kontoavslag inträffar efter att ett inloggningsutbyte har tolkats och namnger en användare i stället för ett paket. Ett tredje meddelande, om att en HMAC inte kan hittas i ett inkommande paket, är återigen annorlunda, eftersom paketet där kom helt utan det förväntade autentiseringselementet. Hela loggprefixet talar om vilket av de tre du har, och prefixet är oftast det första som tas bort när ett fel klistras in i ett ärende.

Åtskillnaden ändrar reparationen. Det ena kräver matchande kanalinställningar, det andra kontostatus och det tredje en profil som inte matchar den lyssnare den nådde.

Jämför vad den körande processen faktiskt laddade

En korrekt fil på disken bevisar ingenting om en process som startade innan den redigerades. Kontrollera den valda profilen, den slutpunkt den kontaktade och om tjänsten har laddats om sedan ändringen. Bekräfta också att slutpunkten tillhör profilen, eftersom en annan instans eller tjänst kan lyssna där den gamla filen förväntar sig något annat.

Att exportera om en profil som stöds från samma källa är en billig jämförelse, eftersom den tar bort glidningen mellan det du tror är konfigurerat och det klienten faktiskt skickar. Att generera nytt nyckelmaterial är ett mycket större steg och hjälper bara om båda sidor inför det tillsammans. Att byta ut en sida lokalt återskapar den missmatchning du försökte ta bort.

Jämför kontrollkanalen med datakanalen

Två mekanismer autentiserar olika delar av en anslutning och konfigureras separat, vilket alternativreferensen för 2.6 beskriver. tls-auth lägger till en HMAC på kontrollkanalens paket och tar ett riktningsargument som måste vara motsatt på de två parterna, medan tls-crypt skyddar kontrollkanalen med en delad nyckel i stället. Ingen av dem är datakanalens egen integritetskontroll. Med ett AEAD-datachiffer är den kontrollen inbyggd i chifferet, så den separata sammanfattningen auth används inte som med ett chiffer utan AEAD.

Det betyder att en auth-rad som kopierats från en fungerande installation utan AEAD kan vara irrelevant i en AEAD-installation, och en AEAD-installation kan fortfarande misslyckas på kontrollkanalen om nyckeln tls-auth eller dess riktning är fel. Jämför varje inställning mot motparten i stället för mot en ihågkommen konfiguration.

Jämför åtgärden med egenskapen du ger upp

Att stänga av paketautentisering tystar varningen och tar bort kontrollen som hittade missmatchningen, vilket inte är samma sak som att reparera profilen. Fråga vilken egenskap du avstår från och om konstruktionen fortfarande håller utan den.

Läs den första relevanta händelsen på båda sidor innan du ändrar något och ändra sedan bara den missmatchning den namnger.

Om nästa försök går vidare till ett certifikat- eller inloggningsfel är det framsteg och inte en regression: paketlagret stämmer nu och anslutningen har gått vidare. Anteckna inställningarna som gav ändringen, så att nästa person ärver en förklaring i stället för ett mysterium.