El túnel s'aixeca, el registre mostra un xifratge i la revisió del perfil continua. Després arriba una actualització en un parell i el mateix perfil falla amb un missatge sobre cap xifratge compartit, cosa que fa que la gent busqui una directiva per eliminar. La cosa útil d'entendre és que data-ciphers descriu una negociació, no un paràmetre. Una part ofereix una llista, l'altra tria d'ella, i el resultat és un sol algorisme que totes dues admeten. Llegir aquest intercanvi explica la majoria d'aquestes fallades abans que canvieu una línia.

Dos canals, dues configuracions

Una OpenVPN sessió té un canal de control i un canal de dades. El canal de control executa l'apretada de mans TLS que autentica els parells i negocia les claus. El canal de dades xifra els paquets que porten el vostre trànsit.

data-ciphers configura el segon. El canal de control té les seves pròpies opcions, i les comprovacions d'identitat del perfil són una tercera qüestió, separada. Un canvi en un no arregla l'altre, i per això un perfil pot semblar correcte i fallar igualment en una etapa concreta.

Manteniu els tres en caixes separades quan llegiu un fitxer de configuració.

Llegiu la negociació al registre

El registre del client anomena tots dos resultats quan la connexió té èxit. Una línia informa del canal de control i els seus detalls TLS, i una altra informa del xifratge del canal de dades que s'ha seleccionat.

Llegiu tots dos, perquè responen preguntes diferents. Una fallada del canal de control atura la connexió abans que cap xifratge de dades sigui rellevant. Una discrepància del canal de dades apareix després d'una apretada de mans correcta, amb un missatge sobre cap xifratge compartit.

Després compareu les llistes ofertes a banda i banda. Un nom que la versió d'un parell o el seu rerefons criptogràfic no proporciona no es pot seleccionar, per molt aviat que aparegui a la llista de l'altre parell.

Com passa realment la selecció

El servidor envia la seva llista data-ciphers al client durant l'apretada de mans, i el client selecciona la primera entrada d'aquesta llista que també admet. L'ordre, per tant, pertany a la configuració del servidor, no a la del client.

Aquest detall explica una classe de resultats confusos. Reordenar la llista del client no canvia res mentre decideix la llista del servidor. Afegir un xifratge que el client no pot proporcionar tampoc no canvia res, perquè el client ha de poder utilitzar l'entrada que tria.

Les versions més noves van canviar la llista per defecte i van canviar el nom de l'opció que la contenia, de manera que dos parells en versions diferents poden discrepar sense que ningú editi un perfil. Comproveu la versió a cada banda abans de suposar una errata.

Una llista no és una classificació de força en abstracte. És un conjunt de candidats, i el seleccionat és la primera entrada mútuament admesa en l'ordre del servidor. És per això que dues llistes que semblen diferents poden negociar el mateix xifratge. També és per això que dues llistes que semblen idèntiques poden fallar.

Els parells més antics necessiten una reserva deliberada

Un parell que no pot negociar gens, perquè és anterior al mecanisme o el té desactivat, necessita un acord de compatibilitat documentat. L'opció de reserva existeix exactament per a aquest cas i s'aplica als parells que no participen en la negociació.

Això no és el mateix que habilitar tots els xifratges heredats per fer desaparèixer un missatge. Una llista àmplia debilita la sessió per a cada parell, inclosos els que haurien negociat alguna cosa forta.

Coordineu les dues bandes en lloc d'editar noms d'algorisme no relacionats. Si una actualització del servidor ha eliminat una opció antiga, la correcció pertany al pla de versions, no a una cursa al client.

Manteniu la verificació intacta

Una discrepància del canal de dades no és un motiu per acceptar un servidor no verificat. La verificació del certificat, el nom del servidor esperat i els paràmetres de protecció del canal de control són independents de la selecció del xifratge i haurien de sobreviure a qualsevol canvi de compatibilitat.

Registreu junts el xifratge de dades negociat, la versió del client i la versió del servidor, perquè la propera comparació comenci a partir de fets i no del fitxer de perfil.

Després d'una correcció admesa, proveu la connexió inicial i una renegociació, perquè una sessió que s'estableix una vegada encara pot fallar quan es renoven les claus.

Si el túnel s'estableix i els llocs encara fallen, el xifratge ja no és el sospitós. Continueu amb l'encaminament i el DNS. Ordre de treball: llegiu les dues línies del registre, compareu les dues llistes, comproveu les versions, afegiu una reserva només per a un parell que la necessiti i torneu a provar el camí de renovació.

Articles relacionats