Alguien te envía un requisito que dice IKEv2, ESP y MODP3072, y la consola no tiene ningún campo con ese nombre. El error es ponerse a buscar uno. IKEv2 es una versión de negociación, ESP es el protocolo que transporta tu tráfico protegido, y MODP3072 es un grupo de intercambio de claves, es decir, el grupo 15 de IANA. Esos tres hechos viven en tres lugares distintos, y el grupo aparece dos veces.

La frase no es un único ajuste

Convierte el requisito en listas de opciones antes de tocar nada. La tabla de abajo es todo el mapeo.

Agreed requirementAWS option to reviewStill a separate decision
IKEv2Allowed IKE versionsEncryption, integrity, key-exchange choices
MODP3072 for the IKE exchangePhase 1 DH groups, group 15Phase 2 key-exchange and PFS policy
MODP3072 for the protected-traffic exchangePhase 2 DH groups, group 15The initial IKE exchange group
A named encryption algorithmThat phase's encryption listIntegrity and DH-group agreement

MODP3072 es el grupo 15, y AWS acepta actualmente 15 tanto en la lista de grupos DH de Phase 1 como en la de Phase 2. Aceptarlo en ambos lugares no es lo mismo que exigirlo en ambos, y desde luego no significa que tu socio se refiriera a los dos.

Phase 1 y Phase 2 negocian cosas distintas

Phase 1 construye la asociación de seguridad IKE: cómo se autentican las dos pasarelas, acuerdan las claves y protegen su propia conversación. Phase 2 construye la CHILD SA que transporta el tráfico real, y su intercambio de claves puede ser nuevo en lugar de heredado.

Esa separación es la razón por la que importa que un socio hable de perfect forward secrecy. PFS es una propiedad de Phase 2, y un grupo de la lista de Phase 1 no la proporciona. Pregunta a qué intercambio se aplica cada requisito, junto con el modo de cifrado, si la integridad la aporta un cifrado AEAD y qué se espera del rekey en ambos lados.

No deduzcas un conjunto aceptable completo de la palabra AES ni de un solo número DH. Una política montada con dos mitades de dos conversaciones es como un túnel acaba proponiendo algo con lo que ningún equipo estuvo de acuerdo.

Una lista permitida no es un resultado de negociación

Las listas de opciones describen qué está dispuesto a aceptar cada lado. No informan de qué se eligió. Lee las propuestas IKE y CHILD-SA realmente seleccionadas para una conexión nueva y luego confirma que el requisito se cumple, no solo que está permitido. Una opción potente dentro de una lista solo demuestra que estaba disponible.

Vigila también la renovación. La primera CHILD SA de IKEv2 y un intercambio CHILD posterior con PFS pueden mostrar condiciones de compatibilidad distintas, porque el segundo intercambio crea material de clave nuevo con el grupo PFS en juego. Si tu prueba de aceptación solo cubre el primer minuto de un túnel, no ha probado la parte que le importa a tu socio.

La referencia de opciones de túnel de AWS enumera Phase 1 y Phase 2 por separado, y esa es la estructura que conviene interiorizar antes de que llegue el próximo requisito.

Cambia el túnel que de verdad quieres decir

Una conexión VPN Site-to-Site tiene dos túneles con sus propias opciones y su propio estado. Antes de revisar o editar nada, haz coincidir la dirección exterior del túnel de AWS con el par de la pasarela de cliente y no des por hecho que un solo guardado actualiza ambos.

Un cambio aprobado necesita que el lado de la pasarela de cliente esté preparado para la misma política y una ventana para la interrupción que se llevará el túnel elegido. Si el par no está listo para el grupo 15 en la fase que estás cambiando, el túnel simplemente dejará de levantarse, y la consola no te dirá qué lado se negó.

Registra la política acordada como fase, versión de protocolo, cifrado, integridad y grupo DH, y luego confírmala en los intercambios que debe proteger. El enrutamiento, los selectores de tráfico y los permisos de aplicaciones quedan aparte; este mapeo no es una configuración completa de la pasarela y no es una recomendación de activar algoritmos adicionales por variedad.

Artículos relacionados