Clave estática ou TLS para unha ligazón OpenVPN entre dous pares?

Dúas máquinas que só falan entre si poden conservar esa topoloxía e aínda así obter claves de tráfico negociadas. A forma da rede e o modo de protección son decisións independentes, e confundilas é o que leva a xente a tentar rotar un segredo estático cambiando un ficheiro mentres ambos os daemons seguen en execución. Cambiar o ficheiro de claves baixo unha parella en funcionamento non rota nada. O modo de clave estática, que OpenVPN 2.6 marca como obsoleto, mantén unha soa clave durante toda a vida do túnel, así que o ficheiro no disco e a clave en memoria só volven coincidir despois de que ambos os extremos se reinicien. Se o requisito é a renovación automática, o modo de protección ten que cambiar.

O que o modo de clave estática non pode facer

En modo segredo, ambos os pares comparten unha clave precompartida que cifra e autentica o túnel directamente. Non hai aperta de mans, así que non hai mecanismo para que ningún lado propoña material de clave novo, demostre unha identidade ou se recupere dunha discrepancia sen intervención do operador. Ambas as propiedades derivan da ausencia dunha canle de control e non dunha opción que falte, e ningunha opción de configuración engade unha a este modo.

O manual de OpenVPN 2.6 é explícito en que a clave persiste ata que se xera unha nova. Iso é aceptable para unha ligazón de laboratorio ou unha parella fixa de dispositivos cun procedemento de rotación documentado, e é inaceptable onde un segredo de longa duración sexa un risco real. Cambiar un ficheiro non crea unha clave nova para unha parella en funcionamento; crea dous pares que non coinciden. Substituír o ficheiro, polo tanto, engade unha interrupción sen engadir rotación.

Tampouco existe noción de identidade de par máis aló da posesión do ficheiro. Quen teña a clave é un par, e nada no túnel rexistra que lado é cal, así que a revogación é todo ou nada.

Pasar a TLS sen redeseñar a ligazón

O modo TLS engade unha canle de control e, con ela, a capacidade de negociar claves da canle de datos. Nun despregamento punto a punto, un lado asume o papel de servidor e o outro o de cliente, pero a topoloxía segue sendo unha ligazón entre dous pares: cada lado coñece o extremo do outro e non aparece ningún grupo nin servizo multiusuario. Os papeis son un detalle da aperta de mans, non unha arquitectura nova.

Déalle a cada máquina a súa propia identidade. Cada lado necesita un certificado e unha clave privada, a áncora de confianza que valida o outro e unha regra de verificación de par que nomee a quen se espera. Non reutilice a clave privada dun par no outro para aforrar tempo; iso converte dúas identidades nunha e elimina a capacidade de revogar calquera dos lados por separado. A inscrición é o lugar para facelo ben, porque corrixilo despois significa reemitir certificados.

Manteña o contrato de rede sen cambios mentres cambia a protección. As mesmas direccións de túnel, rutas e servizos permitidos deberían aplicarse antes e despois, de xeito que un fallo durante a migración sexa un problema de protección e non unha sorpresa de encamiñamento disfrazada. Anote as direccións e as rutas antes do cambio; comparalas despois é máis rápido que reconstruílas de memoria.

Algúns despregamentos tamén protexen a canle de control coa súa propia clave estática, que non rota coa canle de datos. Esa clave garda a aperta de mans e non a carga útil, así que comprometela expón a negociación e non o tráfico. Gárdea aparte do material da canle de datos e dálle unha data de substitución da que sexa responsable unha persoa concreta. Rotarla significa reiniciar ambos os pares nunha xanela coordinada, polo que merece unha entrada no calendario e non un recordo.

Quen renova que, e cando

En modo TLS, a renovación réxese por límites configurados: un intervalo de tempo, un reconto de bytes ou un reconto de paquetes. O control de tempo documentado é no que se apoia a maioría dos despregamentos, e o valor efectivo máis baixo entre ambos os pares pode iniciar a substitución, así que subilo só nun lado non freará o evento. Os límites por volume existen porque unha ligazón ocupada pode esgotar unha clave moito antes de que o faga o reloxo. Ningún dos límites é unha comprobación de saúde e ningún lle di que unha renovación tivese éxito.

Por iso diagnosticar unha renegociación recorrente a partir dun só ficheiro de configuración é enganoso. Lea os axustes en ambos os pares e despois mire a transición no rexistro en lugar de supoñer unha avaría. Unha renovación que se completa limpiamente parece unha ráfaga curta de tráfico da canle de control, non unha desconexión.

Manteña os obxectos separados na súa cabeza. O certificado demostra identidade a longo prazo e substitúese segundo un calendario que vostede controla. A clave da canle de datos actualízase automaticamente, e un intercambio de autenticación separado, se o despregamento o require, segue a política da conta e pode necesitar os seus propios arranxos para intercambios posteriores.

Desactivar a renovación por completo, poñendo o intervalo a cero, non é unha solución para un rexistro ruidoso. Converte un evento san do ciclo de vida nunha clave permanente, o que lle devolve á propiedade da que intentaba saír.

Aceptar o cambio

Constrúa a configuración nova a partir do exemplo admitido da versión instalada, non dun fragmento mínimo antigo cuxos algoritmos e rutas de ficheiro se herdaron doutro sitio. Coordine o cambio para que ambos os pares se modifiquen xuntos e manteña unha ruta de recuperación aprobada por se un lado non arrinca. Baixe a ligazón deliberadamente en lugar de esperar unha interrupción para probar a reversión. Unha reversión que ensaiou vale máis que unha reversión que describiu.

Probe tres cousas: a verificación inicial de identidade ten éxito, o fluxo de aplicación previsto funciona e unha renovación controlada ocorre sen perder tráfico. Despois lea a transición no rexistro polo que demostra realmente: un identificador de clave novo significa que os pares completaron unha substitución, non que o túnel se reconectase. Tráteo como evidencia dun paso e revise os contadores de tráfico antes de dar a migración por terminada.

O que unha promesa de cero interrupcións ocultaría é o fallo que aínda non viu. Unha renovación que falla, un certificado que caduca ou un defecto de ruta aínda poden perturbar a ligazón, e ningún queda descartado por unha proba limpa. A propiedade pola que paga a pena deseñar é máis estreita e máis útil: a substitución rutineira de claves deixa de ser un cambio manual de ficheiro.