Dos cambios distintos producen el mismo síntoma cuando un túnel de sitio a sitio de Check Point deja de levantarse: el par ve una dirección externa diferente o rechaza la identidad IKE que ahora recibe. En una captura tomada desde un solo lado, ambos parecen idénticos. Decidir cuál de los dos tiene exige tres comprobaciones, y ninguna de ellas es el panel de selección de enlace.

Si se equivoca en el orden, ajusta la selección de origen para corregir un desajuste de identidad. Así es como el mismo túnel se arregla dos veces y se vuelve a romper tras el siguiente cambio de ruta.

Tres condiciones que separan los dos casos

Condición primera: ¿el extremo configurado del par coincide con la dirección que realmente llega? Si los paquetes alcanzan la pasarela remota desde una dirección que esta no asocia con su objeto de par, la negociación falla antes de que se intercambie cualquier identidad. Condición segunda: ¿la identidad IKE de la propuesta coincide con el valor que espera el par? Eso es autenticación, no transporte. Condición tercera: ¿la opción que quiere cambiar está admitida para este sistema virtual en esta versión? Ningún ajuste visible responde a estas preguntas.

Si falla la primera condición, tiene un problema de enrutamiento o de traducción. Si falla la segunda, tiene un problema de contrato con el par. Si la tercera es desconocida, deje de configurar.

Construya primero el registro del par externo

Anote el sistema virtual, la versión del software y el nivel de actualización instalado antes de tocar nada. Después registre las interfaces externas, la ruta hacia el par remoto, las direcciones de origen esperadas antes y después del NAT y el extremo configurado del par remoto.

Mantenga los prefijos protegidos internos en una parte separada de ese registro. Cambiar un origen externo y cambiar una dirección de LAN protegida son operaciones distintas que casualmente viven en la misma política.

Añada la dirección a cada captura que conserve. Una negociación iniciada localmente y una respuesta al par remoto pueden seleccionar de forma distinta, así que una captura sin etiquetar es una prueba débil. Etiquete el archivo con el sistema virtual y el iniciador.

Lea qué separa realmente la selección de enlace

La guía de Check Point sobre la selección de enlace en R81.20 separa tres cosas que la gente fusiona en una: cómo resuelve el par remoto una dirección de pasarela, qué ruta transporta el tráfico saliente y qué IP de origen se utiliza. Cada una responde a una pregunta distinta. Ninguna de ellas cambia la identidad que autentica el par.

Esa separación explica por qué un cambio de ruta puede alterar la dirección externa visible sin tocar la identidad IKE, y por qué un cambio de identidad puede romper un túnel cuyo enrutamiento es perfecto.

El RFC 7296 traza la misma línea para el propio IKE: la carga de identificación no es la dirección de transporte. Los fabricantes implementan esa separación, no la redefinen.

Decida con pruebas, no con el panel de ajustes

Si el par informa de una identidad desconocida o que no coincide, corrija el objeto de par o la configuración de identidad, no la selección de origen. Si el par no informa nada y su captura muestra paquetes que salen de una dirección inesperada, corrija primero el enrutamiento o la traducción. Si ambos parecen correctos y el túnel sigue fallando, capture en el lado remoto y compare qué recibió. Solo cuando la dirección y la identidad coinciden y el camino sigue siendo incorrecto, una opción de selección de enlace pasa a ser candidata.

Antes de configurar esa opción en VSX, obtenga la guía de funciones admitidas de la versión correspondiente o una declaración explícita del fabricante para el contexto del sistema virtual. Un informe antiguo de que una función no estaba disponible es historia, no una prohibición vigente, y un panel de ajustes no es una declaración de soporte.

Concilié ambos extremos y conserve el registro

Cuando tenga un diseño admitido, revise el alcance externo, la configuración del extremo del par y el acuerdo de identidad juntos, como un solo contrato. Después planifique la aceptación para tres casos: la conexión inicial, la conexión iniciada por el lado remoto y el fallo que espera cuando se rompe el camino.

Guarde las direcciones externas observadas junto al contexto del sistema virtual activo. Así, el siguiente cambio de ruta se compara con un contrato documentado en lugar de con el recuerdo que alguien tenga del valor por defecto.

Artículos relacionados