Esa dirección de túnel es un par, no una subred que puedas explorar

Tu cliente se conecta y muestra un par de direcciones, o una sola dirección con una 255.255.255.255 máscara, y la primera reacción es que el servidor ha entregado algo roto. Nada está roto: una interfaz tunelada es un enlace punto a punto, y la máscara describe el extremo remoto de ese único enlace, no un rango de vecinos. Leer el par como local y par explica la máscara extraña, la ruta de un solo host junto a ella y la tabla de vecinos ausente. Lo que la misma lectura no excusa es un plan de direcciones que se solape con la red de la oficina.

Por qué la máscara parece incorrecta en un enlace tunelado

En una interfaz Ethernet, una dirección y una máscara afirman dos cosas: este host posee la dirección, y todo lo que hay dentro del prefijo es un vecino directo. El núcleo deriva una ruta en el enlace a partir de esos dos hechos y luego resuelve direcciones de enlace para los vecinos que cree presentes. Una interfaz punto a punto conserva la propiedad y descarta a los vecinos, así que la segunda dirección de la línea del cliente es el extremo remoto y no otro host en un segmento compartido. No hay direccionamiento de hardware, ni tráfico de resolución, ni dominio de difusión al que unirse, y por eso la interfaz se comporta como una tubería con exactamente un destino.

También por eso una ruta de un solo host junto a una máscara amplia es normal aquí y no un síntoma. La accesibilidad en este enlace significa una dirección, y el núcleo anota exactamente eso. Lee las dos direcciones juntas antes de decidir que la configuración es incorrecta, porque cualquiera de las dos por sí sola parece un error.

Dos topologías, dos formas de dirección

La topología punto a punto más antigua da a cada cliente un bloque pequeño y usa las dos direcciones centrales, así que la máscara parece un fragmento de una red y no un grupo. La topología de subred entrega una dirección del grupo con la máscara del grupo y nombra la dirección de túnel del servidor como el par. Ambas producen un enlace válido, y solo difieren en qué direcciones aparecen en el perfil y en la máscara que un usuario probablemente cuestionará.

Sea cual sea la fila que coincida con tu cliente, lee primero el par, porque nombra el extremo remoto y por tanto explica la máscara. Un perfil copiado entre servidores que usan topologías distintas mostrará la forma incorrecta para su nuevo hogar, y esa discrepancia se confunde fácilmente con un fallo del servidor.

Cuando el grupo y la red de la oficina reclaman los mismos bits

Como el enlace está enrutado, el grupo necesita un prefijo que no aparezca en ninguna de las redes que el servidor puede alcanzar. Comparte uno y el cliente tendrá una única ruta para un rango que significa dos lugares, y la ruta instalada más recientemente decide qué lugar gana. El fallo se presenta en el cliente aunque la decisión que hay detrás pertenezca al plan de direcciones. Lo que reportan los usuarios es que el router local desaparece cuando se levanta el túnel, o que solo responden algunos hosts de la oficina.

Los prefijos que solo se parecen son otro caso, y comparar octetos a ojo no es una comparación de prefijos. Escribe ambos y cuenta los bits enmascarados: 192.168.4.0/24 frente a 192.168.6.0/24 coinciden hasta el bit 22 y divergen en el bit 23, porque el tercer octeto se lee 00000100 frente a 00000110, así que esas dos redes son realmente separadas. Pon 10.8.0.0/24 junto a otra 10.8.0.0/24 y los 24 bits enmascarados coinciden, lo que significa que una ruta no puede expresar ambos lugares. La longitud de la máscara decide dónde se detiene la comparación, y la red instalada en segundo lugar es la que pierde.

Lo que un enlace enrutado no puede entregar

La difusión y el multicast no viajan por un enlace enrutado, y varias funciones conocidas se construyen sobre ellas. Las listas de exploración, los anuncios de nombres y el descubrimiento de servicios asumen un segmento compartido, así que un servidor de archivos puede responder cada petición por dirección y aun así no aparecer nunca en una lista. La resolución de nombres que depende de la difusión local del enlace falla por la misma razón, y ninguna edición del perfil cambia lo que el túnel puede transportar. Si eso importa es una cuestión de requisitos, no de enrutamiento.

Un cliente que realmente necesita esas entregas requiere una interfaz puente, que transporta tramas Ethernet y por tanto conserva el dominio de difusión. El coste es un enlace más ruidoso, la pérdida del direccionamiento limpio descrito arriba y una superficie de fallo mucho mayor en cuanto aparecen bucles. Justifica el requisito antes de cambiar, y prefiere un servicio de nombres que funcione sobre enlaces enrutados cuando el requisito solo trata de nombres.

Leer la interfaz antes de editar el perfil

Pregunta al núcleo qué ha instalado, no qué parece decir el perfil. La salida de direcciones muestra el par que explica la máscara, y la salida de rutas muestra si existe un camino hacia él. Ejecutar ambas contra el dispositivo de túnel lleva un momento y resuelve la cuestión.

ip -4 addr show dev tun0
ip route show dev tun0
ip route get 10.8.0.1

Si esos tres coinciden, el perfil hace lo que se configuró para hacer, y el problema restante está en otro sitio. Cambia la topología solo por un motivo que nombre una capacidad ausente, porque una máscara desconocida no lo es.