OpenVPN-pakke: HMAC-godkendelse mislykkedes – hvilket lag?

To fejl rapporteres med samme ordforråd og har næsten intet til fælles. Den ene er en pakke, hvis godkendelsestag ikke blev verificeret; den anden er en person, hvis legitimationsoplysninger blev afvist. Behandler du den første som den anden, leder du efter en adgangskode, der aldrig var problemet.

Beskeden navngiver et lag, og det nyttige arbejde er at afgøre hvilket, før du udskifter noget materiale. At sammenligne kandidaterne side om side er den hurtigste måde at se forskellen.

To fejl, der deler et ord

En pakkegodkendelsesfejl opstår, mens trafik behandles: et tag eller digest på en modtaget pakke stemte ikke med det, modtageren havde beregnet. En kontoafvisning sker, efter at en logindudveksling er parset, og den navngiver en bruger frem for en pakke. En tredje besked, om ikke at kunne finde en HMAC i en indgående pakke, er igen anderledes, fordi pakken der ankom helt uden det forventede godkendelseselement. Det fulde logpræfiks fortæller, hvilken af de tre du har, og præfikset er normalt det første, der fjernes, når en fejl indsættes i en ticket.

Forskellen ændrer reparationen. Den ene kræver matchende kanalindstillinger, den anden kontostatus, og den tredje en profil, der ikke matcher den lytter, den nåede.

Sammenlign, hvad den kørende proces faktisk indlæste

En korrekt fil på disken beviser intet om en proces, der startede, før den blev redigeret. Kontrollér den valgte profil, det endepunkt den kontaktede, og om tjenesten er genindlæst siden ændringen. Bekræft også, at endepunktet hører til profilen, da en anden instans eller en anden tjeneste kan lytte, hvor den gamle fil forventer noget andet.

At gen-eksportere en understøttet profil fra samme kilde er en billig sammenligning, fordi den fjerner afvigelsen mellem det, du tror er konfigureret, og det, klienten faktisk sender. At generere nyt nøglemateriale er et meget større skridt, og det hjælper kun, hvis begge ender tager det til sig sammen. At udskifte den ene side lokalt genskaber netop den uoverensstemmelse, du forsøgte at fjerne.

Sammenlign kontrolkanalen med datakanalen

To mekanismer godkender forskellige dele af en forbindelse og konfigureres separat, som 2.6-valgreferencen beskriver. tls-auth tilføjer en HMAC til kontrolkanalens pakker og tager et retningsargument, der skal være modsat på de to peers, mens tls-crypt beskytter kontrolkanalen med en delt nøgle i stedet. Ingen af dem er datakanalens egen integritetskontrol. Med et AEAD-datacipher er den kontrol indbygget i cipheren, så det separate auth digest bruges ikke, som det gør med et ikke-AEAD-cipher.

Hvilket betyder, at en auth linje kopieret fra en fungerende ikke-AEAD-opsætning kan være irrelevant i en AEAD-opsætning, og en AEAD-opsætning kan stadig fejle på kontrolkanalen, hvis tls-auth nøglen eller dens retning er forkert. Sammenlign hver indstilling med peeren i stedet for med en husket konfiguration.

Sammenlign rettelsen med den egenskab, du giver afkald på

Deaktivering af pakkegodkendelse bringer advarslen til tavshed og fjerner den kontrol, der fandt uoverensstemmelsen, hvilket ikke er det samme som at reparere profilen. Spørg, hvilken egenskab du opgiver, og om designet stadig holder uden den.

Læs den første relevante hændelse på begge ender, før du ændrer noget, og ændr derefter kun den uoverensstemmelse, den navngiver.

Hvis næste forsøg kommer videre til en certifikat- eller loginfelj, er det fremskridt og ikke tilbagegang: pakkelaget er nu enigt, og forbindelsen er kommet videre. Notér de indstillinger, der skabte ændringen, så den næste person arver en forklaring i stedet for en gåde.