OpenVPN-pakke: HMAC-autentisering mislyktes – hvilket lag?

To feil rapporteres med samme ordforråd og har nesten ingenting til felles. Den ene er en pakke der autentiseringsmerket ikke ble verifisert; den andre er en person hvis legitimasjon ble avvist. Behandler du den første som den andre, leter du etter et passord som aldri var problemet.

Meldingen navngir et lag, og det nyttige arbeidet er å avgjøre hvilket før du erstatter noe materiale. Å sammenligne kandidatene side om side er den raskeste måten å se forskjellen.

To feil som deler ett ord

En pakkeautentiseringsfeil oppstår mens trafikk behandles: et merke eller en digest på en mottatt pakke stemte ikke med det mottakeren hadde beregnet. En kontoavvisning skjer etter at en innloggingsutveksling er analysert, og den navngir en bruker fremfor en pakke. En tredje melding, om at en HMAC ikke finnes i en innkommende pakke, er igjen annerledes, fordi pakken der kom helt uten det forventede autentiseringselementet. Det fulle loggprefikset forteller deg hvilken av de tre du har, og prefikset er vanligvis det første som fjernes når en feil limes inn i en sak.

Forskjellen endrer reparasjonen. Den ene krever samsvarende kanalinnstillinger, den andre kontostatus, og den tredje en profil som ikke passer lytteren den nådde.

Sammenlign hva den kjørende prosessen faktisk lastet

En korrekt fil på disken beviser ingenting om en prosess som startet før den ble redigert. Kontroller den valgte profilen, endepunktet den kontaktet, og om tjenesten er lastet på nytt siden endringen. Bekreft også at endepunktet tilhører profilen, siden en annen instans eller en annen tjeneste kan lytte der den gamle filen forventer noe annet.

Å eksportere en støttet profil på nytt fra samme kilde er en billig sammenligning, fordi den fjerner avviket mellom det du tror er konfigurert og det klienten faktisk sender. Å generere nytt nøkkelmateriale er et mye større skritt, og det hjelper bare hvis begge ender tar det i bruk sammen. Å erstatte én side lokalt gjenoppretter nettopp avviket du forsøkte å fjerne.

Sammenlign kontrollkanalen med datakanalen

To mekanismer autentiserer ulike deler av en forbindelse og konfigureres separat, slik 2.6-alternativreferansen beskriver. tls-auth legger til en HMAC på kontrollkanalpakker og tar et retningsargument som må være motsatt på de to partene, mens tls-crypt beskytter kontrollkanalen med en delt nøkkel i stedet. Ingen av dem er datakanalens egen integritetskontroll. Med et AEAD-datachiffer er den kontrollen innebygd i chifferen, så den separate auth digesten brukes ikke slik den brukes med et chiffer som ikke er AEAD.

Noe som betyr at en auth linje kopiert fra en fungerende ikke-AEAD-utrulling kan være irrelevant i en AEAD-utrulling, og en AEAD-utrulling kan fortsatt feile på kontrollkanalen hvis tls-auth nøkkelen eller retningen er feil. Sammenlign hver innstilling med motparten i stedet for med en husket konfigurasjon.

Sammenlign rettelsen med egenskapen du gir opp

Å deaktivere pakkeautentisering stilner advarselen og fjerner kontrollen som fant avviket, noe som ikke er det samme som å reparere profilen. Spør hvilken egenskap du gir opp og om designet fortsatt holder uten den.

Les den første relevante hendelsen på begge ender før du endrer noe, og endre deretter bare avviket den navngir.

Hvis neste forsøk kommer videre til en sertifikat- eller innloggingsfeil, er det fremgang og ikke tilbakegang: pakkelaget er nå enig, og forbindelsen har kommet videre. Noter innstillingene som skapte endringen, slik at neste person arver en forklaring i stedet for en gåte.