Cinco papeles de la dirección en un perfil IPsec y cuál está mal

Cinco tareas distintas reciben una dirección en una definición de conexión típica, y no tienen por qué coincidir entre sí. Los administradores se atascan porque un instinto razonable, hacer que todos los campos apunten al mismo host, es erróneo para al menos tres de ellos. La salida consiste en nombrar primero el síntoma y luego mirar el campo o los dos campos que podrían producirlo.

Las cinco tareas, en el orden en que importan

El punto final de transporte es donde se entrega el intercambio IKE. La identidad autenticada es el nombre que demuestra cada lado, y se comprueba contra la política, no contra una tabla de enrutamiento. Las subredes protegidas son los selectores que deciden qué tráfico interno pertenece al túnel. Luego está el origen que se usa cuando la propia puerta de enlace inicia una conversación y, por último, el siguiente salto de la capa inferior para alcanzar al par.

Las etiquetas de participante como left y right son convenciones para los dos lados de una conexión, no sinónimos de local y remoto. Lea el manual de la implementación que realmente está instalada antes de suponer que una clave significa lo que otro producto entendía por ella.

Decisión uno: no se establece nada

Cuando no aparece ningún intercambio en los registros, el punto final es el primer sospechoso: una dirección equivocada, una ruta filtrada o una interfaz en la que el demonio no escucha. Pase a los campos de identidad solo cuando el handshake sea visible, porque la identidad se juzga dentro del intercambio, no antes. Una ruta filtrada y una dirección equivocada se ven idénticas desde el cliente, así que revise el lado que escucha antes de editar nada. Confirme que el demonio está ligado a la interfaz que espera, porque un servicio que escucha en una dirección se ve exactamente como una ruta bloqueada.

Una dirección pública observada a través de la traducción no es lo mismo que la identidad que demuestra un par. Cambiar una dirección para que coincida con lo que muestra una captura de paquetes en el extremo lejano es una corrección habitual y equivocada.

Decisión dos: el túnel está levantado y el tráfico muere

Los selectores deciden qué entra en el túnel, y una discrepancia aquí produce una conexión que negocia con éxito mientras la aplicación sigue fallando. El lado lejano tiene que nombrar su rango protegido como su rango remoto, y es exactamente ahí donde se cuelan los valores invertidos.

Lea ambas configuraciones una al lado de la otra antes de editar. El rango local de un host es el rango remoto del otro, y un solo par intercambiado explica un túnel que no transporta nada. Estreche el par antes de tocar las claves: una subred dentro del túnel y otra fuera le dicen si la culpa es del selector o del enrutamiento.

Decisión tres: solo falla el tráfico propio de la puerta de enlace

El tráfico reenviado para clientes puede funcionar perfectamente mientras falla una petición que la propia puerta de enlace inicia, porque ese flujo no tiene un origen de cliente que heredar. El ajuste de origen preferido existe para este caso, y no es traducción de origen: elige una dirección de origen en lugar de reescribir una.

Una aplicación que liga explícitamente otra dirección puede imponerse a la preferencia, así que confirme el origen real del paquete antes de concluir que el ajuste se ignora. Capture en la interfaz propia de la puerta de enlace en lugar de confiar en la intención de la configuración.

El siguiente salto es una instrucción local

El siguiente salto de la capa inferior dice a este host cómo llegar al par, y el lado lejano no necesita el mismo valor. Tratarlo como un ajuste compartido o codificar de forma fija una puerta de enlace predeterminada se rompe en el momento en que cambia la ruta o aparece un segundo camino.

Algunas implementaciones ofrecen valores especiales aquí. Lo que el manual enumera para la versión instalada es la única respuesta segura, y la tabla de enrutamiento local es la prueba de que funcionó. Cuando un par es alcanzable por nombre pero no por dirección, esa discrepancia es el hallazgo, no un detalle que sortear.

Lea el perfil desde ambos extremos

Invertir los papeles sobre el papel es la revisión más rápida que existe: intercambie los rangos protegidos, mantenga el siguiente salto propio de cada lado y la identidad propia de cada lado. Todo lo que no sobrevive al intercambio probablemente está asignado a la tarea equivocada.

Después pruebe un flujo por papel: alcanzabilidad entre pares, un flujo de cliente interno y una petición originada en la puerta de enlace. Tres pruebas le dicen qué tarea está mal asignada sin volver a abrir la configuración. Añada el resultado al tique junto al campo que cambió, porque el siguiente ingeniero se encontrará el mismo perfil.