¿Conviene apilar dos capas de VPN? Tres condiciones que comprobar

Antes de añadir una segunda capa de cifrado a una VPN, responda con honestidad una pregunta: ¿qué conserva todavía el observador cuando ambas capas han hecho su trabajo? Si la respuesta es el texto cifrado interno, sin cambios, entonces el anidamiento compró tiempo y nada más. Lo que sigue es un procedimiento de decisión, no una recomendación. El mismo diagrama es CPU desperdiciada en un despliegue y la respuesta correcta en otro, y solo tres condiciones separan ambos casos.

Anote qué conserva el observador

Registre el objeto que un adversario puede almacenar hoy y luego la secuencia de retiradas que acabaría exponiendo el texto claro. Un túnel exterior produce texto cifrado; cuando termina su protección, lo que queda es el texto cifrado del túnel interior, todavía sellado. Retirar una envoltura no es descifrar. Esa frase describe el anidamiento, y solo es cierta mientras la clave interna sobrevive. En el momento en que las dos capas comparten algo, la línea temporal se colapsa en un único suceso.

Así que el artefacto útil es una línea temporal, no un diagrama de cajas. Para cada capa, anote el extremo, el propietario de la clave, la comprobación de identidad y el año en que se espera que falle el supuesto.

Una forma práctica de probar su propia afirmación: suponga que el observador lo registra todo y nunca se rinde. Bajo ese supuesto, ¿el diseño sigue protegiendo la carga útil durante su vida útil requerida? Si la respuesta depende de que el observador elija no almacenar tráfico, el diseño no tiene respuesta.

Condición primera: ¿terminan las capas en lugares distintos?

El anidamiento compensa cuando las dos capas terminan en dominios de confianza distintos, por ejemplo una pasarela IPsec gestionada por el proveedor delante de un túnel de nivel de aplicación que termina dentro de su propia red. Entonces, romper la capa exterior produce texto cifrado que solo su host puede abrir, y el proveedor nunca ve texto claro. Ponga ambas capas en la misma pasarela y esa propiedad desaparece. Quien compromete la caja lee el tráfico entre las dos operaciones de descifrado, por muchas envolturas que muestre el diagrama.

Compruébelo con el estado instalado y no con el diseño. En Linux, ip xfrm state lista cada asociación de seguridad y sus extremos, lo que determina dónde se detiene realmente cada capa.

Condición segunda: ¿es realmente independiente el material de claves?

Dos capas construidas con un solo certificado, una sola clave precompartida o una sola biblioteca de proveedor son una capa con pasos extra. Entonces una sola credencial comprometida abre ambas, y un solo fallo de implementación elimina ambas a la vez. La independencia debe ser visible en la configuración, no afirmada en una diapositiva.

Aquí el establecimiento híbrido de claves supera al apilamiento de túneles. IKEv2 puede transportar varios intercambios de claves en una sola negociación, de modo que un grupo clásico y un KEM poscuántico pueden alimentar las mismas claves de sesión en lugar de envolverse uno a otro. El resultado es una sola asociación de seguridad cuyas claves dependen de ambos secretos, y el atacante tiene que romper los dos. Se trata de una construcción documentada con una composición definida, cosa que no es un apilado casero de dos productos VPN. En strongSwan, swanctl --list-sas imprime la propuesta negociada de cada SA, y así confirma qué se ejecutó y no qué configuró.

Condición tercera: ¿sobreviven los datos al supuesto exterior?

Una capa que debe durar veinte años necesita un argumento de veinte años. Registrar ahora y descifrar después es barato, y por eso una capa exterior clásica no puede tratarse como una envoltura temporal alrededor de algo más fuerte.

Pregunte cuándo se vuelve recuperable cada clave, no si el cifrado está roto hoy. Un intercambio de claves estático sin secreto hacia adelante falla retroactivamente el día en que cae la clave privada. El acuerdo de claves efímero falla solo en las sesiones que un adversario puede atacar mientras están vivas, o cuando el propio algoritmo se debilita. Esa diferencia decide si una capa interna aún ayuda en 2040. También decide si la capa exterior cambia algo, porque una capa exterior con la vida de clave más débil simplemente se convierte en el punto más temprano de la línea temporal.

Qué construir en su lugar cuando la respuesta es no

Si falla cualquiera de las tres condiciones, abandone el anidamiento y gaste el esfuerzo en la capa que realmente soporta el requisito de vida útil. Configure un intercambio híbrido de claves en el protocolo que ya ejecuta, mantenga la implementación al día y anote la composición en la que confía. Nombrar ML-KEM en un documento de diseño no es una propiedad de seguridad, y FIPS 203 define el mecanismo de encapsulación de claves, no su túnel.

Donde una segunda capa se gana de verdad su lugar, descríbala como defensa en profundidad y no como prueba. Después verifique la composición: qué extremo guarda qué clave, qué identidad comprueba cada lado y qué puede leer un operador con acceso a la consola. Un diseño que sobrevive a esas tres preguntas merece la CPU extra. Uno que no lo hace es un diagrama.

Antes de la ventana de cambio, capture la tabla SA actual y las propuestas negociadas, y después capturelas de nuevo y compare, porque la única evidencia que importa es aquello a lo que los dispositivos aceptaron realmente.