Cuando las rutas del túnel dividido se superponen: qué prefijo gana

Dos perfiles de túnel dividido, dos prefijos privados y un host que ambos reclaman. El síntoma rara vez es un fallo limpio: un servicio funciona el lunes, deja de responder tras reconectarse el segundo cliente y vuelve a funcionar después de reiniciar. El orden en que conectó los clientes no decide el resultado, ni tampoco el orden de las filas en la interfaz del cliente. Ejecute estas comprobaciones en orden y deténgase en la primera que no se cumpla, porque las posteriores solo tienen sentido cuando las anteriores son ciertas.

1. Anote el destino y el origen

Empiece por la dirección exacta a la que va la petición que falla, no por el nombre del host ni por el nombre de la aplicación. Resuelva el nombre una vez, anote cada respuesta y elija la que el flujo que falla utiliza realmente. Después anote la dirección local del mismo flujo, porque la dirección de origen puede cambiar qué regla de política coincide y, por tanto, qué tabla se consulta.

Una petición a uno de varios registros A puede fallar mientras una dirección hermana tiene éxito, lo que parece un túnel inestable y en realidad son dos caminos distintos. Si el destino es un nombre con varias respuestas, pruebe cada respuesta por separado antes de cambiar algo.

2. Pregunte al núcleo qué ruta eligió

No lea la tabla de rutas y deduzca la respuesta. Haga la misma pregunta que hace la pila, con la misma dirección de origen: ip route get 10.20.4.10 from 10.8.0.2 en Linux, o Find-NetRoute -RemoteIPAddress 10.20.4.10 en PowerShell. La salida nombra la ruta que se usaría realmente, que a menudo no es la que esperaba al leer la tabla.

Entre las rutas que coinciden, normalmente gana el prefijo más específico: un /24 vence a un /16 para una dirección dentro de ambos. Entre coincidencias de la misma longitud gana la métrica más baja, y una ruta instalada en un enlace caído se omite. Dos túneles que anuncian el mismo /24 con la misma métrica son un caso distinto: el núcleo conserva ambas rutas y elige entre ellas, así que el resultado puede alternar en lugar de seguir el orden en que se conectaron los clientes. Esa es exactamente la situación que produce el patrón de lunes funciona y martes falla, y reconectar en otro orden no lo cambia.

3. Compruebe si una regla de política redirigió la consulta

Antes de consultar la tabla de rutas, el núcleo recorre sus reglas de política. Una regla puede enviar el tráfico de un origen, usuario o marca de cortafuegos determinados a una tabla completamente distinta, así que el prefijo ganador de la tabla principal puede no consultarse nunca para ese flujo. ip rule show las enumera en orden de evaluación, y ip route show table 100 muestra qué contiene realmente la tabla seleccionada.

Aquí acechan dos trampas. Una regla que apunta a una tabla vacía produce una consulta que cae a la regla siguiente, así que la regla parece no hacer nada. La otra es el propio número de prioridad: las reglas se leen en orden ascendente, y los valores integrados son 0 local, 32766 main y 32767 default. Una regla con un número inferior a 32767 se consulta antes de la regla predeterminada que lo captura todo. Una regla con un número superior a 32767 queda detrás de ella y solo se alcanza cuando ninguna tabla anterior responde, algo que una ruta predeterminada normal en main impide, así que en la práctica nunca se alcanza y no hace nada en silencio mientras parece instalada. Si el cliente escribió una regla y una ruta, compruebe ambas y vuelva a comprobarlas tras una reconexión, porque un perfil reescrito puede añadir una segunda regla con otra prioridad.

4. Separe un empate de enrutamiento de un plan de direcciones duplicado

A veces el prefijo no es el problema en absoluto. Dos sedes que usan ambas 192.168.1.0/24 significan que la misma dirección identifica dos hosts distintos y ninguna ruta puede distinguirlos. Una ruta de host hacia una de las dos respuestas solo funciona hasta que la otra sede responde al mismo nombre, y entonces la excepción se convierte en silencio en el fallo.

La pista es que la dirección de destino es idéntica en ambos caminos y solo difiere el propietario previsto. Eso es una decisión de plan de direcciones, no un ajuste de enrutamiento: renumere un lado, coloque un lado detrás de una puerta de enlace que traduzca, o llegue a la segunda sede mediante un proxy que resuelva sus propios nombres. Bajar una ruta predeterminada o acumular excepciones de host solo traslada la colisión a otro sitio.

5. Confirme que el resolutor coincide con la ruta

Un nombre que se resuelve a la dirección privada equivocada produce todos los síntomas de un conflicto de enrutamiento y ninguna de sus causas. Compare la respuesta que recibe el host con la dirección que el destino usa realmente, y compruebe qué resolutor respondió. Si el túnel empuja un resolutor, el cliente debería instalarlo para los flujos que usan el túnel; si no lo hace, el host sigue preguntando al resolutor local, que puede responder desde un dominio de búsqueda o desde un registro en caché.

Consulte el resolutor directamente y anote el servidor que respondió. Una respuesta en caché con un TTL corto también puede explicar por qué la primera petición tras una reconexión se comporta de forma distinta a la quinta.

6. Reconecte, inspeccione el estado aplicado y después pruebe ambos flujos

Tras una corrección, reconecte e inspeccione qué instaló realmente el cliente en lugar de confiar en el editor de perfiles. Vuelva a leer las reglas, las tablas y la respuesta de ip route get resultante. Un segundo cliente puede reinstalar su propia ruta al conectarse y recrear el conflicto, por lo que la comprobación de estado debe ocurrir después de que se conecte el último cliente, no antes.

Pruebe dos flujos, no uno: la petición que antes fallaba y un recurso que debe usar el otro túnel. Mover todo el tráfico privado a una sola conexión hará que la primera prueba pase mientras rompe la segunda, y solo una prueba emparejada lo detecta. Anote cada excepción que conserve, con el destino y el motivo, para que la siguiente persona pueda distinguir una ruta de host deliberada de una sobrante.