Ninguna ruta arregla un grupo VPN que se solapa con tu LAN

La aplicación afirma que el túnel está sano y, sin embargo, la mitad de los destinos que necesitas nunca responden. El reflejo es añadir una ruta o bajar una métrica, y ese reflejo es el mito que conviene matar primero. Cuando la LAN propia del cliente y el grupo del túnel reclaman el mismo prefijo, la tabla de rutas sostiene dos hechos incompatibles, y ni una ruta por defecto ni una métrica los resuelve. La reparación es una decisión de direccionamiento, y ninguna edición de rutas la sustituye.

Por qué una ruta extra no puede dividir un solo prefijo

Una ruta no puede separar dos reclamaciones sobre un prefijo, por eso lo sensato es dejar de buscar la línea de ruta correcta. La pila no colocará un prefijo idéntico delante de la ruta conectada, y una entrada más específica sí captura la dirección, pero deja inalcanzable el host local que la posee. Lo que parece un problema de enrutamiento es una colisión de direccionamiento, y ambas reparaciones cambian direcciones en lugar de rutas. Pon a prueba la afirmación en tu propia máquina antes de aceptarla.

ip route get 192.168.1.50
route -n get 192.168.1.50
Find-NetRoute -RemoteIPAddress 192.168.1.50

Pregunta al sistema por una sola dirección y fíjate en qué interfaz nombra. Linux, macOS y Windows responden con una consulta de solo lectura que informa de la interfaz elegida y del siguiente salto sin transmitir nada. Cuando la respuesta apunta al adaptador físico mientras el túnel está activo, el núcleo trata la dirección como on-link y no como algo que el túnel pudiera transportar.

Pon el prefijo que concedió el proveedor junto al que sirve el router de casa y compáralos como cadenas. La coincidencia exacta es el caso claro, y un grupo más amplio del proveedor que contenga la subred doméstica falla igual, aunque es más fácil pasarlo por alto. Dos prefijos que solo se parecen no son una colisión, así que anota ambos antes de cambiar nada.

Lee el grupo que el cliente recibió de verdad

Lee lo que recibió el cliente, no la página de marketing del proveedor. Sube el detalle del registro de un cliente OpenVPN y las rutas que empuja el servidor aparecerán en él, revelando los prefijos del túnel; en otros lugares el grupo sale en los detalles de la conexión o en el propio adaptador. Pide al proveedor la lista completa de rangos privados que usa, porque un solo /24 hoy puede ser dos mañana. Evitar los bloques RFC 1918 habituales no es lo mismo que evitar la asignación que realmente te han dado.

Un grupo también puede encogerse o mudarse entre regiones, así que la lista necesita una fecha y un responsable. Trata cualquier respuesta del proveedor más antigua que tu último cambio de plan como una conjetura, no como un hecho. Vuelve a preguntar antes de comprometerte con un rango, y guarda la respuesta con las notas de red para que la siguiente persona herede la prueba.

La renumeración es la reparación que puedes hacer

Si el servidor VPN no es tuyo para cambiarlo, mover la LAN doméstica es la única reparación disponible, y esa es la situación habitual con un proveedor comercial. Elige un rango fuera del grupo del proveedor y fuera de los rangos que puedas necesitar más adelante, y compruébalo contra cada otro sitio al que llegas por un túnel. Espera una interrupción corta y una cola más larga de dispositivos olvidados: uno que aún conserva la dirección antigua parece funcionar hasta que necesita la puerta de enlace.

1. Primero el inventario: la dirección del propio router, el ámbito DHCP, las reservas, las redirecciones de puerto y cualquier dispositivo cuya dirección se escribiera a mano.
2. Después cambia el prefijo LAN del router y el ámbito DHCP a la vez dentro de una ventana de mantenimiento, y renueva los contratos por cable antes que los inalámbricos.
3. A continuación corrige las direcciones estáticas: impresoras, almacenamiento en red, cualquier cosa con una puerta de enlace codificada.
4. Por último, reconecta el cliente VPN y confirma que la dirección del túnel ya no choca con la LAN.

Recorre las direcciones en ese orden y no todas a la vez, y deja el rango antiguo documentado un tiempo para que un dispositivo obsoleto sea reconocible en lugar de misterioso. Un dispositivo que nunca renueva se anuncia fallando al llegar a la puerta de enlace, lo que es una pista mucho mejor que una llamada al soporte. Si el router entrega contratos de más de un día, acórtalos durante la ventana.

Qué puede y qué no puede hacer un alias

Cuando el servidor es tuyo, traducir direcciones en el cliente puede exponer el prefijo remoto dentro de un rango local libre, de modo que el mismo host responde en una segunda dirección. El OpenVPN comunitario lo hace con client-nat, y esa directiva es específica de ese cliente, ausente en los clientes comerciales y móviles con los que la gente suele compararla. El montaje necesita una ruta que coincida con la traducción, un rango libre para el alias y un servidor dispuesto a responder a la dirección no traducida del cliente. Nada de eso ayuda cuando el cliente pertenece a un proveedor gestionado que no puedes configurar.

Cuando el cambio entre en vigor, llega a un host local y a uno remoto primero por dirección y luego por nombre, anotando la ruta que el sistema elige cada vez. Un nombre todavía puede resolverse en el rango antiguo, así que direcciones y nombres merecen comprobaciones independientes. Reinicia un cliente y un dispositivo del lado del servidor si alguno siguió encendido durante el cambio, porque las entradas de vecino en caché sobreviven a la edición.

Escribe los prefijos en los que te quedaste donde la gente mira de verdad: las notas de red, el campo de comentarios del router, la página de bienvenida. Alguien volverá a elegir 192.168.1.0/24, y la colisión volverá con él.