Autentificare HMAC a pachetului OpenVPN eșuată: care strat?

Două eșecuri sunt raportate cu același vocabular și nu au aproape nimic în comun. Unul este un pachet a cărui etichetă de autentificare nu a fost verificată; celălalt este o persoană căreia i-au fost refuzate credențialele. A trata primul ca pe al doilea vă trimite să căutați o parolă care nu a fost niciodată problema.

Mesajul numește un strat, iar munca utilă este să decideți care, înainte de a înlocui orice material. Compararea candidaților unul lângă altul este cea mai rapidă cale de a vedea diferența.

Două eșecuri care împart un cuvânt

O eroare de autentificare a pachetului apare în timpul procesării traficului: o etichetă sau un rezumat de pe un pachet primit nu corespundea cu ce calculase receptorul. O respingere de cont are loc după ce un schimb de autentificare este analizat și numește un utilizator, nu un pachet. Un al treilea mesaj, despre imposibilitatea de a găsi un HMAC într-un pachet de intrare, este din nou diferit, pentru că acolo pachetul a sosit complet fără elementul de autentificare așteptat. Prefixul complet al jurnalului vă spune care dintre cele trei îl aveți, iar prefixul este de obicei primul lucru eliminat când o eroare este lipită într-un tichet.

Distincția schimbă reparația. Unul cere setări de canal potrivite, altul starea contului, iar al treilea un profil care nu se potrivește cu ascultătorul atins.

Comparați ce a încărcat de fapt procesul care rulează

Un fișier corect pe disc nu demonstrează nimic despre un proces pornit înainte de editarea lui. Verificați profilul selectat, punctul final contactat și dacă serviciul a fost reîncărcat de la modificare. Confirmați și că punctul final aparține profilului, fiindcă o altă instanță sau alt serviciu poate asculta unde fișierul vechi așteaptă altceva.

Reexportarea unui profil acceptat din aceeași sursă este o comparație ieftină, pentru că elimină derivarea dintre ce credeți că este configurat și ce trimite clientul de fapt. Generarea de material nou de cheie este un pas mult mai mare și ajută doar dacă ambele capete îl adoptă împreună. Înlocuirea unei părți local recreează nepotrivirea pe care încercați să o eliminați.

Comparați canalul de control cu canalul de date

Două mecanisme autentifică părți diferite ale unei conexiuni și se configurează separat, așa cum referința opțiunilor 2.6 descrie. tls-auth adaugă un HMAC pachetelor canalului de control și preia un argument de direcție care trebuie să fie opus la cele două capete, în timp ce tls-crypt protejează canalul de control cu o cheie partajată în schimb. Niciunul nu este verificarea de integritate proprie a canalului de date. Cu un cifru de date AEAD, acea verificare este inclusă în cifru, așa că auth rezumatul separat nu este folosit cum se folosește cu un cifru care nu este AEAD.

Ceea ce înseamnă că o linie auth copiată dintr-o implementare non-AEAD care funcționează poate fi irelevantă într-una AEAD, iar o implementare AEAD poate eșua în continuare pe canalul de control dacă tls-auth cheia sau direcția ei sunt greșite. Comparați fiecare setare cu partenerul, nu cu o configurație ținută minte.

Comparați remedierea cu proprietatea de care renunțați

Dezactivarea autentificării pachetelor liniștește avertismentul și elimină verificarea care a găsit nepotrivirea, ceea ce nu este același lucru cu repararea profilului. Întrebați de ce proprietate renunțați și dacă proiectarea mai rezistă fără ea.

Citiți primul eveniment relevant la ambele capete înainte de a schimba ceva, apoi schimbați doar nepotrivirea pe care o numește.

Dacă următoarea încercare ajunge la o eroare de certificat sau de autentificare, acesta este progres și nu regres: stratul de pachete este acum de acord, iar conexiunea a mers mai departe. Notați setările care au produs schimbarea, ca următoarea persoană să moștenească o explicație, nu un mister.