TCP funciona y UDP llega a otro servidor en el mismo puerto

Un perfil funciona por TCP y falla por UDP con una advertencia de certificado. La lectura intuitiva es que la ruta UDP rompió la confianza, y la solución intuitiva es aceptar el certificado. Ambas suposiciones pasan por alto una posibilidad que explica el síntoma por completo: los dos transportes llegaron a máquinas distintas. Una regla de reenvío se aplica por protocolo, y nada obliga a que las mitades TCP y UDP de un mismo número de puerto apunten al mismo host.

Un número de puerto, dos reglas independientes

El reenvío es una consulta de tabla indexada por protocolo, dirección de destino y puerto. Una puerta de enlace con una regla para TCP 1194 y una regla para UDP 1194 expresa dos decisiones independientes, y estas pueden nombrar hosts internos distintos. El número compartido es una comodidad para las personas, no una propiedad que imponga la red. Trate el número de puerto como una etiqueta y no como una definición de servicio.

Mire las reglas efectivas en lugar de las previstas. La dirección de destino, el puerto traducido y la interfaz de entrada participan todos, y una regla sobrante de una migración anterior suele ser la razón de que las dos mitades no coincidan.

Escriba ambas asignaciones antes de cambiar cualquier otra cosa. El par de líneas es toda la hipótesis.

Lo que el cliente verificó realmente

Durante el handshake el cliente comprueba el certificado contra su confianza configurada y contra el nombre que espera. Un certificado inesperado es una verificación correcta que falló la comprobación de identidad, que es el resultado adecuado cuando el par no es el que quería alcanzar. Rechazarlo es prueba de que el cliente funciona, no de que el transporte esté roto. Lea el nombre informado antes que la cadena informada, porque el nombre es lo que el cliente comparó.

La distinción importa porque los dos fallos llevan a arreglos distintos. Un problema de confianza necesita un arreglo de confianza, mientras que un par inesperado necesita un arreglo de enrutamiento o de reenvío.

Anote qué identidad informó el cliente. Ese nombre es la pista más fuerte sobre qué máquina respondió.

Correlacionar el intento con un servidor

Registre el perfil, la dirección pública, el transporte y el puerto que usó el cliente. Después coteje la hora del intento con el registro del servidor al que quería llegar. Su ausencia es una pista y no una prueba de un descarte del firewall, porque los niveles de registro varían entre despliegues. Una marca de tiempo junto con una dirección de origen acota más que cualquiera de las dos por separado.

Compare la identidad del certificado que encontró con la identidad esperada por un canal administrativo. Esa comparación fuera de banda es lo que mantiene fiable la comprobación.

Revise reglas de reenvío antiguas, escuchadores alternativos y cualquier ruta de balanceo de carga antes de concluir que ambos transportes comparten un backend. Cada uno de ellos puede redirigir un flujo sin tocar el otro transporte.

No ajustar la confianza a un par equivocado

Importar la CA inesperada hace desaparecer el síntoma y cambia en quién confía el cliente. Es un estado peor que una conexión fallida, porque oculta la discrepancia en lugar de resolverla. Lo mismo vale para desactivar la verificación solo para ver si el túnel levanta.

Si el par resulta legítimo pero no deseado, la acción correcta es retirarlo o apuntar la regla al host correcto. El almacén de confianza no es el lugar para conciliar un error de inventario.

Conserve el texto del rechazo. Es el único registro de lo que vio el cliente.

Tras el arreglo, probar un flujo nuevo

Corrija la asignación y luego conéctese con una sesión de cliente nueva. La traducción con estado puede mantener un flujo existente apuntado al destino antiguo, así que una conexión establecida puede sobrevivir al cambio y engañarle. Inicie una nueva y confirme en el registro del servidor previsto que atendió el intento.

Si ambos transportes llegan de forma demostrable al mismo servidor y aun así se comportan distinto, la diferencia restante son los escuchadores y la configuración propios de ese servidor. La comparación de transportes solo significa algo una vez fijada la identidad del extremo.