Un usuario llega a la intranet en la red de la oficina y no a través del túnel, mientras que Ajustes sigue mostrando la VPN como conectada. Editar la tabla de rutas en ese momento corre el riesgo de cortar la sesión remota que usas para diagnosticar. Pregunta al núcleo qué ruta elegiría para el host que falla. La utilidad route de macOS tiene una operación get que responde exactamente a eso, para un destino, sin cambiar nada.

Consulta el host que falla, no la ruta predeterminada

Una captura de la ruta predeterminada dice muy poco en un Mac moderno, porque un destino más específico o una política limitada pueden imponerse sobre lo que la ruta predeterminada parece decir. El túnel puede estar activo, la ruta predeterminada puede parecer correcta y, aun así, el único host que necesitas puede estar enrutado a otro lugar. Consulta la dirección que falla y deja que el núcleo nombre la ruta que eligió.

La forma es route -n get seguido de la dirección: route -n get 203.0.113.10, donde la dirección de documentación representa tu objetivo. Usa el destino autorizado y la familia de direcciones correspondiente, porque una respuesta IPv4 no dice nada sobre un recurso solo IPv6. La documentación de la utilidad route describe la operación get y los campos que imprime.

Lee la interfaz y la puerta de enlace como evidencia

Ejecuta la consulta antes de conectar la VPN y luego otra vez después, y compara las líneas de interfaz y de puerta de enlace. La diferencia entre esas dos respuestas es lo que el túnel cambió realmente, y es mucho más útil que volcar la tabla entera. Si la interfaz es idéntica en ambas ejecuciones, la ruta nunca fue el problema y puedes dejar de mirar el enrutamiento.

Anota el destino, la interfaz, la puerta de enlace y la hora de la consulta antes de sacar una conclusión. La salida es evidencia, no un diagnóstico: la misma interfaz puede ser correcta para un host y equivocada para otro cuando hay un túnel dividido de por medio.

Una ruta correcta no es una petición que funciona

Una ruta te dice qué interfaz usaría el núcleo, nada más. El DNS, un cortafuegos del host y la autorización de la aplicación se sitúan por encima de esa decisión, y la petición puede fallar después de que el enrutamiento tenga éxito. Conserva el síntoma exacto antes de seguir, porque "no se puede conectar" y "se conecta pero devuelve un error" son investigaciones distintas con pasos siguientes distintos. La vista del resolutor y la vista de la interfaz complementan la consulta de destino en lugar de sustituirla.

Un listado de la tabla de enrutamiento aún tiene su lugar: así es como notas una ruta predeterminada inesperada. Una ruta predeterminada ordinaria que queda no demuestra que la VPN no se use, porque las entradas más específicas ganan sobre ella.

Mantén el punto final y el recurso separados

Hay dos búsquedas y responden preguntas distintas. Llegar al punto final es un viaje exterior por la red física. Llegar a la aplicación ocurre dentro del túnel, en una dirección que solo existe en el lado privado. Confundir las dos produce el clásico bucle falso, en el que el punto final parece enrutarse por el túnel que termina. Consulta las dos direcciones por separado, etiqueta cada resultado y la confusión desaparece.

La superposición de prefijos es el otro caso que conviene conocer. Cuando los rangos local y remoto se superponen, decide la coincidencia del prefijo más largo, así que una subred local superpuesta puede hacer sombra a la dirección remota que esperabas. Entonces el destino privado parece idéntico a uno local, y la corrección pertenece al plan de direcciones y no a la tabla de rutas. La consulta get muestra qué interfaz ganó, y ese es el hecho que necesitas antes de cambiar nada.

Primero lee, después cambia

Mantén route add y route delete fuera de la primera pasada. En un Mac que administras en remoto, una edición descuidada de la tabla puede llevarse precisamente el camino de vuelta a la máquina y dejar a nadie capaz de terminar el diagnóstico. Decide cuál es la ruta correcta, anota cómo deshacer el cambio y solo entonces ejecútalo. La inspección no tiene esa cola.

La misma precaución se aplica a vaciar cachés y reiniciar servicios de red como primer movimiento, porque ambos destruyen la evidencia que estabas a punto de leer. Las comprobaciones de solo lectura son baratas, repetibles y seguras en cualquier orden. Hazlas el paso predeterminado y recurre a un cambio solo cuando la evidencia apunte a uno.

Artículos relacionados