OpenVPN-pakke: HMAC-autentisering mislukkast – kva lag?

To feil vert rapporterte med same ordtilfang og har nesten ingenting til felles. Den eine er ein pakke der autentiseringsmerket ikkje vart verifisert; den andre er ein person som legitimasjonen hans vart avvist. Behandlar du den første som den andre, leitar du etter eit passord som aldri var problemet.

Meldinga nemner eit lag, og det nyttige arbeidet er å avgjere kva lag før du erstattar noko materiale. Å samanlikne kandidatane side om side er den raskaste måten å sjå skilnaden.

To feil som deler eitt ord

Ein pakkeautentiseringsfeil oppstår medan trafikk vert handsama: eit merke eller ein digest på ein motteken pakke stemde ikkje med det mottakaren hadde rekna ut. Ei kontoavvising skjer etter at ein innloggingsutveksling er analysert, og ho nemner ein brukar framfor ein pakke. Ei tredje melding, om at ein HMAC ikkje finst i ein innkomande pakke, er igjen annleis, fordi pakken der kom heilt utan det venta autentiseringselementet. Det fulle loggprefikset fortel deg kva av dei tre du har, og prefikset er vanlegvis det første som vert fjerna når ein feil vert lima inn i ei sak.

Skilnaden endrar reparasjonen. Den eine krev samsvarande kanalinnstillingar, den andre kontostatus, og den tredje ein profil som ikkje passar lyttaren han nådde.

Samanlikn kva den køyrande prosessen faktisk lasta

Ei korrekt fil på disken beviser ingenting om ein prosess som starta før ho vart redigert. Kontroller den valde profilen, endepunktet han kontakta, og om tenesta er lasta på nytt sidan endringa. Stadfest òg at endepunktet høyrer til profilen, sidan ein annan instans eller ei anna teneste kan lytte der den gamle fila ventar noko anna.

Å eksportere ein støtta profil på nytt frå same kjelde er ein billeg samanlikning, fordi han fjernar avviket mellom det du trur er konfigurert og det klienten faktisk sender. Å generere nytt nøkkelmateriale er eit mykje større steg, og det hjelper berre om begge endar tek det i bruk saman. Å erstatte éi side lokalt attopprettar nettopp avviket du prøvde å fjerne.

Samanlikn kontrollkanalen med datakanalen

To mekanismar autentiserer ulike delar av ei tilkopling og vert konfigurerte separat, slik 2.6-alternativreferansen skildrar. tls-auth legg til ein HMAC på kontrollkanalpakkar og tek eit retningsargument som må vere motsett på dei to partane, medan tls-crypt vernar kontrollkanalen med ein delt nøkkel i staden. Ingen av dei er datakanalens eigen integritetskontroll. Med eit AEAD-datasiffer er den kontrollen innebygd i sifferet, så den separate auth digesten vert ikkje brukt slik han vert brukt med eit siffer som ikkje er AEAD.

Noko som tyder at ein auth linje kopiert frå ein fungerande ikkje-AEAD-utrulling kan vere irrelevant i ei AEAD-utrulling, og ei AEAD-utrulling kan framleis feile på kontrollkanalen om tls-auth nøkkelen eller retninga hans er feil. Samanlikn kvar innstilling med motparten i staden for med ein hugsa konfigurasjon.

Samanlikn rettinga med eigenskapen du gir opp

Å slå av pakkeautentisering får åtvaringa til å teie og fjernar kontrollen som fann avviket, noko som ikkje er det same som å reparere profilen. Spør kva eigenskap du gir opp og om designet framleis held utan han.

Les den første relevante hendinga på begge endar før du endrar noko, og endre deretter berre avviket ho nemner.

Om neste forsøk kjem vidare til ein sertifikat- eller innloggingsfeil, er det framgang og ikkje tilbakegang: pakkelaget er no samd, og tilkoplinga har kome vidare. Noter innstillingane som skapte endringa, slik at neste person arvar ei forklaring i staden for ei gåte.