El adaptador VPN muestra /32: no significa un solo destino
Una máscara 255.255.255.255 en un adaptador VPN es la dirección del propio cliente, no un límite de hosts alcanzables. Lee las rutas, el alcance de la puerta de enlace y el camino de vuelta por separado.
Los adaptadores muestran 255.255.255.255, y a menudo se concluye que la VPN alcanza exactamente una dirección. Esa lectura confunde la dirección del propio cliente con el conjunto de destinos que se enrutan por el túnel. En una interfaz punto a punto o enrutada, las dos cosas son objetos distintos, y solo una de ellas limita la alcanzabilidad. El mito sobrevive porque la máscara se parece a la máscara de subred que la gente aprendió en Ethernet.
El mito: una máscara de host significa un solo host alcanzable
Una asignación /32 le dice a la interfaz qué dirección pertenece a este extremo del enlace, y en un enlace punto a punto eso es todo lo que significa. La dirección del par es un campo aparte, y las rutas que dicen qué hay más allá del par son otra cosa. Nada en la máscara describe la red remota, porque la máscara no es el lugar donde se describen las redes remotas. Leerla como un límite de alcance es como leer el número de tu propia casa como una lista de todas las direcciones que puedes visitar.
La confusión tiene una raíz real: en Ethernet, una máscara de host sí significaría una sola dirección en ese segmento. Un túnel no es un segmento Ethernet, y es la tabla de rutas del cliente, no la máscara, la que decide qué pasa por él. Por eso la misma /32 puede estar delante de un centro de datos entero.
Lee la dirección y las rutas como objetos separados
Imprime la interfaz y la tabla juntas, y después léelas como dos respuestas a dos preguntas. La dirección responde quién es este extremo; las rutas responden a dónde puede ir el tráfico. Una tercera pregunta, qué destinos permite la puerta de enlace, no se ve en absoluto en el cliente. La referencia de direcciones de iproute2 describe por separado los campos de dirección local, par y ruta de prefijo justo por eso.
ip addr show tun0
ip route show
ip route get 10.60.5.10
En Windows existe la misma separación entre la lista de direcciones y la tabla de rutas, y el comando de consulta es la forma más rápida de ver cuál gana para un destino concreto. Si la consulta devuelve la interfaz del túnel, el cliente enviará el paquete allí. Si devuelve el adaptador físico, el cliente nunca pregunta a la VPN, y ningún permiso del servidor cambiará eso. Comprueba el destino que realmente necesitas, no una dirección pública genérica.
Get-NetIPAddress -InterfaceAlias "VPN"
Find-NetRoute -RemoteIPAddress 10.60.5.10
Detente si la consulta apunta a la interfaz equivocada. Eso es un problema de enrutamiento del cliente, y se corrige en el cliente.
Por qué ensanchar la máscara suele empeorarlo
Cambiar la asignación a una /24 para que se parezca a la LAN de la oficina puede crear un prefijo en el enlace: el núcleo ahora cree que toda la /24 está conectada directamente a la interfaz del túnel. El tráfico hacia direcciones que deberían enrutarse por la puerta de enlace se envía entonces como si un vecino estuviera en el enlace. El resultado es un agujero negro que parece una caída del servidor.
También oculta el problema real, que es una ruta que falta o un permiso que falta en la puerta de enlace. Ninguna de las dos cosas la crea una máscara más ancha, y ambas sobreviven al cambio. Si el diseño necesita un prefijo mayor en la interfaz, esa es una decisión para el modelo de interfaz que se usa, tomada con la documentación en la mano. Copiar una máscara de las capturas de otro producto no es esa decisión.
Si falta la ruta del prefijo remoto, corrige su aprovisionamiento. Si está presente y la conexión sigue rechazándose, la máscara nunca fue el diagnóstico.
Cuando la ruta es correcta y el flujo sigue fallando
Una ruta correcta solo demuestra que el cliente enviará el paquete. La puerta de enlace todavía tiene que aceptar el destino, el camino de vuelta tiene que existir para la dirección asignada, y el servicio tiene que permitir el flujo. Prueba esas tres cosas por separado: la consulta en el cliente, el alcance permitido de la puerta de enlace y una petición a un servidor necesario. Que la autenticación tenga éxito antes de que las tres estén en su sitio es normal, y por eso un cliente conectado todavía puede no alcanzar nada.
ping -c1 10.60.5.10
traceroute -n 10.60.5.10
curl -sv https://app.internal.example/ -o /dev/null
Mantén los objetos de red y los permisos de grupo con su propietario en un servicio gestionado por un dispositivo. Lo que se le dice al cliente que alcance y lo que se le permite usar son ajustes distintos, a menudo en pantallas distintas. Cambiar uno y probar el otro es cómo un tique rebota entre dos equipos.
El mito que hay que jubilar es que la máscara sea un límite de alcance. Lee la dirección, las rutas y la política de la puerta de enlace como tres hechos separados, y una /32 deja de parecer una restricción y empieza a parecer una asignación normal de túnel.