As claves de 8192 bits atascan o aperto de mans; o DH de 1024 bits rexéitase

Un servidor ten clientes que se quedan colgados un anaco e logo se reconectan, e outro rexeita as conexións de inmediato cunha mensaxe sobre o tamaño da clave. Parecen erros distintos e son o mesmo erro apuntando en direccións opostas. A criptografía do aperto de mans ten un custo que medra co tamaño dos parámetros, e tamén ten un chan por debaixo do cal as bibliotecas modernas non baixan. Dimensionar o material é a lista de comprobación, e o primeiro punto é decidir cal dos dous fallos ten realmente.

Lea o fallo antes de rexenerar nada

O tempo diille a maior parte. Un aperto que consume varios segundos e logo morre adoita significar que o cálculo superou a paciencia do par, o que apunta a parámetros demasiado grandes para o hardware ou para o tempo de espera. Un rexeitamento inmediato que nomea un tamaño de clave ou de grupo apunta ao outro lado, a material que a biblioteca non aceptará de ningún xeito.

Eses dous necesitan correccións opostas, e aquí é onde fallan a maioría dos intentos. Rexenerar parámetros de 8192 bits nun cliente que xa rexeitou un grupo pequeno empeora o caso lento sen facer nada polo rápido. Anote que síntoma observou antes de tocar un ficheiro.

Despois comprobe que se lle pide ao par. Un servidor configurado para un grupo grande de campo finito obriga a cada cliente a gastar o mesmo tempo de CPU en cada renegociación, non só ao conectar. Se o problema aparece a un intervalo regular en lugar de ao arrincar, ese intervalo é unha pista forte de que axuste é caro. A renegociación repite todo o cálculo, así que un atasco que reaparece cada hora adoita ser o mesmo custo pagado outra vez.

O caso lento: material que o hardware non pode costear

O traballo de Diffie-Hellman e RSA medra rápido co tamaño da clave, e todo iso ocorre antes de que flúa ningún tráfico polo túnel. Nun router pequeno ou un cliente de baixa potencia, un grupo o bastante grande pode empurrar o intercambio máis alá do tempo de espera do outro lado, de modo que a conexión reintenta ou simplemente parece colgada sen ningún erro.

A solución é baixar a un tamaño que todos os pares admitan e que cada dispositivo poida calcular con comodidade. Unha clave RSA de 2048 bits e un grupo de 2048 bits seguen sendo unha base amplamente compatible; ir máis alá só axuda cando todos os pares están de acordo e a CPU pode pagalo en cada renegociación. Todo o que supera esa base é un intercambio deliberado, non unha mellora.

O tamaño non é unha puntuación, e o número máis grande dunha táboa comparativa non é automaticamente a opción correcta. Escolla o valor máis pequeno que a súa política permita e que todos os pares acepten, e logo mida o aperto en lugar de supor que mellorou. Un grupo máis pequeno que aínda esgota o tempo dille que o tamaño nunca foi toda a historia.

O caso rápido: un grupo que a biblioteca rexeita

As compilacións modernas de OpenSSL rexeitan de plano os grupos de campo finito máis pequenos, e un nivel de seguridade elevado empurra o chan aínda máis arriba. O firmware de router que inclúe un ficheiro de parámetros de hai décadas é a fonte habitual, e o síntoma é unha conexión que falla de inmediato cunha mensaxe que nomea o grupo ou o tamaño da clave. Nada dese fallo é intermitente, e iso é o que o fai fácil de recoñecer.

Substitúa o ficheiro en lugar de editar a configuración para saltar a comprobación. Xere un grupo actual, valídeo e logo instáleo onde o demo o le de verdade. Conserve o ficheiro antigo ata que un cliente se conecte con éxito co novo:

openssl dhparam -out /etc/openvpn/ffdhe2048.pem 2048
openssl dhparam -in /etc/openvpn/ffdhe2048.pem -check -noout
ls -l /etc/openvpn/ffdhe2048.pem

A orde de comprobación valida o ficheiro e non imprime nada útil cando pasa; a listaxe confirma que substituíu o ficheiro que carga o servizo e non unha copia vella ao lado. Apunte a configuración a esa ruta, reinicie o demo e confirme que un cliente que antes fallaba agora completa o aperto.

Se o servidor tamén fixa un nivel de seguridade ou un perfil de certificado, leaos antes de concluír que o grupo era incorrecto. Un perfil que esixe unha clase máis estrita pode rexeitar material que o valor por defecto aceptaría, e quitar ese axuste é un cambio máis estreito que desactivar a comprobación globalmente.

Escolla un tamaño para o par e o hardware

Averigüe que pode soportar o extremo remoto antes de xerar algo exótico. Un dispositivo demasiado vello para un grupo de 2048 bits é un dispositivo que hai que substituír, xa que apuntar o servidor a un grupo máis feble só converte unha queixa de compatibilidade nunha caída. As solucións duradeiras van cara a software máis novo, non cara a parámetros máis vellos. Cada excepción temporal neste eido ten a costume de converterse na configuración permanente.

Onde a CPU do servidor é o límite, cambie o algoritmo en lugar de baixar por debaixo da política. Un intercambio de claves de curva elíptica como X25519 é moito máis barato que un grupo grande de campo finito e ten amplo soporte, o que o converte na mellor resposta a unha queixa de rendemento que un módulo RSA máis pequeno.

Escolla o que escolla, probeo cunha conexión real e observe canto tarda o aperto, non só se ao final conecta. Unha conexión que ten éxito en doce segundos ten a mesma causa raíz que unha que falla aos quince.

Anote a decisión para que unha reconstrución non a desfaga

Manteña o ficheiro de parámetros baixo xestión de configuración e escriba ao lado o tamaño, o motivo e a data. Un servidor reconstruído que xera en silencio os seus propios valores por defecto é a forma en que o mesmo fallo volve seis meses despois sen que ninguén poida explicar a decisión orixinal.

Anote a mesma información xunto ao endpoint e ao perfil, para que unha revisión non teña que reconstruíla a partir do tamaño dun ficheiro. Cando a próxima conexión se ataque, esa nota é a diferenza entre unha comprobación de cinco minutos e unha investigación nova. Tamén evita que o seguinte enxeñeiro resolva o caso lento cunha solución pensada para o rápido.