Como OpenVPN data-ciphers escolle o cifrado da canle de datos

O túnel levanta, o rexistro mostra un cifrado e a revisión do perfil continúa. Despois chega unha actualización a un par e o mesmo perfil falla cunha mensaxe sobre ningún cifrado compartido, o que manda a xente buscar unha directiva que borrar. O útil que hai que entender é que data-ciphers describe unha negociación, non un axuste. Un lado ofrece unha lista, o outro escolle dela, e o resultado é un único algoritmo que ambos admiten. Ler ese intercambio explica a maioría destes fallos antes de que cambie unha liña.

Dúas canles, dúas configuracións

Unha OpenVPN sesión ten unha canle de control e unha canle de datos. A canle de control executa o apretón de mans TLS que autentica os pares e negocia as claves. A canle de datos cifra os paquetes que levan o seu tráfico.

data-ciphers configura a segunda. A canle de control ten as súas propias opcións, e as comprobacións de identidade do perfil son un terceiro asunto, separado. Un cambio nunha non arranxa a outra, por iso un perfil pode parecer correcto e fallar igualmente nunha etapa concreta.

Manteña os tres en caixas separadas cando lea un ficheiro de configuración.

Lea a negociación no rexistro

O rexistro do cliente nomea ambos os resultados cando a conexión ten éxito. Unha liña informa da canle de control e dos seus detalles TLS, e outra informa do cifrado da canle de datos que se seleccionou.

Lea ambos, porque responden preguntas distintas. Un fallo da canle de control detén a conexión antes de que importe ningún cifrado de datos. Unha discrepancia da canle de datos aparece tras un apretón de mans correcto, cunha mensaxe sobre ningún cifrado compartido.

Despois compare as listas ofrecidas en ambos os lados. Un nome que a versión dun par ou o seu back-end criptográfico non proporciona non se pode seleccionar, por moi cedo que apareza na lista do outro par.

Como ocorre realmente a selección

O servidor empuxa a súa lista data-ciphers ao cliente durante o apretón de mans, e o cliente selecciona a primeira entrada desa lista que tamén admite. A orde pertence, xa que logo, á configuración do servidor, non á do cliente.

Ese detalle explica unha clase de resultados confusos. Reordenar a lista do cliente non cambia nada mentres decide a lista do servidor. Engadir un cifrado que o cliente non pode proporcionar tampouco cambia nada, porque o cliente ten que poder usar a entrada que escolle.

As versións máis recentes cambiaron a lista predeterminada e renomearon a opción que a adoitaba conter, así que dous pares en versións distintas poden discrepar sen que ninguén edite un perfil. Comprobe a versión en cada lado antes de supoñer unha errata.

Unha lista non é unha clasificación de forza en abstracto. É un conxunto de candidatos, e o seleccionado é a primeira entrada mutuamente admitida na orde do servidor. Por iso dúas listas que parecen distintas poden negociar o mesmo cifrado. Tamén por iso dúas listas que parecen idénticas poden fallar.

Os pares máis antigos necesitan unha reserva deliberada

Un par que non pode negociar en absoluto, porque é anterior ao mecanismo ou o ten desactivado, necesita un acordo de compatibilidade documentado. A opción de reserva existe exactamente para ese caso e aplícase aos pares que non participan na negociación.

Iso non é o mesmo que habilitar todos os cifrados herdados para facer desaparecer unha mensaxe. Unha lista ampla debilita a sesión para cada par, incluídos os que terían negociado algo forte.

Coordine os dous lados en lugar de editar nomes de algoritmos non relacionados. Se unha actualización do servidor eliminou unha opción antiga, a corrección pertence ao plan de versións, non a unha carreira no cliente.

Manteña a verificación intacta

Unha discrepancia da canle de datos non é motivo para aceptar un servidor non verificado. A verificación do certificado, o nome de servidor esperado e os axustes de protección da canle de control son independentes da selección do cifrado e deberían sobrevivir a calquera cambio de compatibilidade.

Rexiste xuntos o cifrado de datos negociado, a versión do cliente e a versión do servidor, para que a próxima comparación parta de feitos e non do ficheiro de perfil.

Tras unha corrección admitida, probe a conexión inicial e unha renegociación, porque unha sesión que se establece unha vez aínda pode fallar cando se renovan as claves.

Se o túnel se establece e os sitios seguen fallando, o cifrado xa non é o sospeitoso. Continúe co encamiñamento e o DNS. Orde de traballo: lea as dúas liñas do rexistro, compare as dúas listas, comprobe as versións, engada unha reserva só para un par que a necesite e volva probar a ruta de renovación.