Reclave, reconexión ou reautenticación: cal necesitas?

Unha sesión que leva horas activa non conservará as mesmas claves para sempre, e iso é intencionado. Tres sucesos distintos descríbense como rotación de claves: material de sesión novo baixo unha asociación existente, unha reconstrución completa da conexión e unha repetición da comprobación de identidade. Cada un ten un desencadeante, un custo e unha sinatura de fallo diferentes. Se escolle o equivocado, a solución ou non fai nada ou tira o túnel sen motivo.

A decisión depende de que capa caducou realmente.

Tres operacións ás que chaman rotación

Un reclave crea claves de tráfico novas dentro da relación de control existente, usando o mecanismo que define o protocolo. IKEv2 fáeo cunha nova asociación de seguridade filla, TLS 1.3 cunha mensaxe de actualización de clave e WireGuard cun handshake novo cando se acadan os seus límites de tempo ou de mensaxes. Os enderezos do túnel e a identidade autenticada quedan onde estaban.

Unha reconexión descarta a conexión e volve construíla desde o principio, o que repite a asignación de enderezos, a instalación de rutas e calquera negociación que fixese o primeiro intento.

A reautenticación repite a propia proba de identidade, que pode implicar unha credencial, un certificado ou un segundo factor. Pode ocorrer con ou sen reconexión, segundo o produto.

Que nota o usuario na renovación

Un reclave debería ser case invisible. Os identificadores de asociación cambian, os contadores poden reiniciarse e as aplicacións conservan os seus sockets; unha pausa breve nunha dirección é normal durante o intercambio. Ver un identificador novo nunha listaxe de estado non é proba dunha avaría. A liña de rexistro que segue o intercambio é a que che di se rematou.

Unha caída real na renovación apunta a un punto concreto. Un desaxuste de proposta, unha credencial caducada ou un cambio de ruta producen cada un unha liña de rexistro distinta, e só un deles se corrixe axustando as duracións.

Onde diverxen as tres na práctica

Se o único que caducou é o material de clave, reclava. Se o enderezo do par, a ruta ou a ligazón NAT cambiaron e os paquetes xa non chegan, reconecta. Se a organización esixe unha comprobación periódica de identidade, iso é reautenticación e ningún axuste de duracións a substitúe.

Os valores por defecto do protocolo adoitan conter a resposta correcta. WireGuard reclava tras un limiar de tempo e de volume de datos sen intervención do usuario; as duracións de IKEv2 négocianse por asociación filla; os túneles baseados en TLS rotan claves dentro da sesión existente. Subir as duracións para evitar un erro recorrente apraza o fallo e alonga a exposición se unha clave queda comprometida.

Unha advertencia importa para sesións longas: a frecuencia por si soa non crea segredo cara a adiante. A propiedade depende de como se relacionan as claves de sesión cos segredos a longo prazo e de se as claves antigas se destrúen, o que é unha cuestión de deseño e implementación, non un axuste.

Escolle os valores por defecto e despois rexistra a etapa

Mantén os valores por defecto do provedor salvo que un requisito documentado diga o contrario, e cambia as duracións en ambos os pares se as cambias. Despois rexistra a que etapa chegou cada suceso, para que a próxima ocorrencia se poida comprobar contra o mesmo punto do handshake.

swanctl --list-sas
ip xfrm state | grep -E 'proto|replay-window'
wg show
journalctl -u strongswan --since '1 hour ago' | grep -i -E 'rekey|rekeyed|child'

Tras unha corrección, fai unha renovación controlada e envía tráfico de aplicación novo pola asociación nova. Un túnel que se declara establecido pero non reenvía nada é o fallo que esta comprobación existe para atrapar.