Error d’autenticació HMAC del paquet OpenVPN: quina capa?

Dues fallades es reporten amb el mateix vocabulari i gairebé no tenen res en comú. Una és un paquet l’etiqueta d’autenticació del qual no es va verificar; l’altra és una persona les credencials de la qual van ser rebutjades. Tractar la primera com la segona us envia a buscar una contrasenya que mai no era el problema.

El missatge anomena una capa, i la feina útil és decidir quina abans de substituir cap material. Comparar els candidats l’un al costat de l’altre és la manera més ràpida de veure la diferència.

Dues fallades que comparteixen una paraula

Un error d’autenticació de paquet s’aixeca mentre es processa trànsit: una etiqueta o un resum en un paquet rebut no coincidia amb el que el receptor havia calculat. Un rebuig de compte passa després d’analitzar un intercanvi d’inici de sessió, i anomena un usuari, no un paquet. Un tercer missatge, sobre no poder localitzar un HMAC en un paquet entrant, torna a ser diferent, perquè allà el paquet va arribar del tot sense l’element d’autenticació esperat. El prefix complet del registre us diu quin dels tres teniu, i el prefix sol ser la primera cosa que s’elimina quan un error s’enganxa en un tiquet.

La distinció canvia la reparació. Una demana una configuració de canal coincident, una altra l’estat del compte, i la tercera un perfil que no coincideix amb l’oient a què ha arribat.

Compareu què va carregar realment el procés en execució

Un fitxer correcte al disc no demostra res sobre un procés que es va iniciar abans que s’edités. Comproveu el perfil seleccionat, el punt final amb què va contactar i si el servei s’ha recarregat des del canvi. Confirmeu també que el punt final pertany al perfil, perquè una altra instància o un altre servei poden estar escoltant on el fitxer vell espera una altra cosa.

Reexportar un perfil admès des de la mateixa font és una comparació barata, perquè elimina la deriva entre el que creieu que està configurat i el que el client envia realment. Generar material de clau nou és un pas molt més gran, i només ajuda si tots dos costats l’adopten alhora. Substituir un costat localment torna a crear la discrepància que intentàveu eliminar.

Compareu el canal de control amb el canal de dades

Dos mecanismes autentiquen parts diferents d’una connexió i es configuren per separat, tal com la referència d’opcions 2.6 descriu. tls-auth afegeix un HMAC als paquets del canal de control i pren un argument de direcció que ha de ser oposat als dos parells, mentre que tls-crypt protegeix el canal de control amb una clau compartida en lloc d’això. Cap dels dos no és la comprovació d’integritat pròpia del canal de dades. Amb un xifratge de dades AEAD aquesta comprovació és dins del xifratge, així que el auth resum separat no s’usa com amb un xifratge que no és AEAD.

La qual cosa vol dir que una auth línia copiada d’un desplegament no AEAD que funciona pot ser irrellevant en un d’AEAD, i un desplegament AEAD encara pot fallar al canal de control si la tls-auth clau o la seva direcció són incorrectes. Compareu cada paràmetre amb el parell, no amb una configuració recordada.

Compareu la solució amb la propietat que cediu

Desactivar l’autenticació de paquets silencia l’avís i elimina la comprovació que va trobar la discrepància, cosa que no és el mateix que reparar el perfil. Pregunteu quina propietat esteu cedint i si el disseny aguanta sense ella.

Llegiu el primer esdeveniment rellevant als dos extrems abans de canviar res, i després canvieu només la discrepància que anomena.

Si el següent intent avança fins a un error de certificat o d’inici de sessió, això és progrés i no regressió: la capa de paquets ja hi està d’acord i la connexió ha seguit endavant. Anoteu la configuració que va produir el canvi, perquè la següent persona hereti una explicació en lloc d’un misteri.