El VPN de Windows muestra 255.255.255.255: ¿está mal la máscara?

El túnel se conecta, abres los detalles del adaptador y la máscara indica 255.255.255.255. Comparada con la 255.255.255.0 de la LAN de la oficina parece rota, y ahí suele empezar el error. En un enlace punto a punto una máscara de equipo es la descripción correcta del extremo local, y las redes remotas llegan como rutas en lugar de como una subred conectada. El procedimiento siguiente separa las dos preguntas para que no reconstruyas un ámbito DHCP que funciona solo para arreglar un valor mostrado.

Un enlace punto a punto no es un segmento Ethernet

Una interfaz Ethernet necesita una máscara de subred porque cada dirección de ese rango es potencialmente alcanzable en el mismo cable. Un túnel de tipo PPP tiene exactamente un par en el otro extremo. No hay dominio de difusión, ni ARP, ni motivo para que la dirección local describa un rango.

La negociación de direccionamiento para ese modelo se define en RFC 1332, que cubre cómo acuerdan sus direcciones los dos extremos. Lo que no hace es entregar al cliente la LAN de la oficina como una red directamente conectada. El cliente aprende dónde está la oficina instalando rutas a través del enlace, y esas rutas son las que deciden realmente la accesibilidad.

Esto no es afirmar que toda máscara que veas sea correcta. Un cliente mal configurado también puede producir un direccionamiento extraño. El punto es más concreto: una máscara de equipo en este tipo de adaptador es lo esperado, así que por sí sola no es prueba de un fallo.

Paso 1: confirma el modelo de interfaz

Mira qué es el adaptador antes de juzgar lo que dice. La cadena de descripción identifica el controlador, y la longitud de prefijo de la dirección asignada confirma lo que negoció el cliente:

Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetIPAddress -InterfaceAlias 'Corp VPN' | Select-Object IPAddress,PrefixLength,PrefixOrigin
Get-NetIPInterface -InterfaceAlias 'Corp VPN' | Select-Object AddressFamily,ConnectionState,NlMtu

El tercer comando es el que zanja la mayoría de las discusiones. Una unidad máxima de transmisión baja es característica de un enlace encapsulado, mientras que un valor similar al de Ethernet sugiere un modelo de adaptador virtual distinto. Si la descripción nombra un controlador PPP o RAS y el prefijo es 32, estás ante exactamente el diseño descrito arriba y puedes dejar de preocuparte por la máscara.

Paso 2: lee la ruta del destino que falla

La accesibilidad se decide por destino, y una sola interfaz conectada no te dice nada al respecto. Pregunta directamente a la tabla de rutas por la dirección a la que el usuario intenta llegar:

Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4

Find-NetRoute es la respuesta directa: nombra la interfaz y la dirección de origen que el sistema usaría para ese destino. Si devuelve el túnel, el tráfico hacia ese host pasa por el túnel y la máscara nunca fue el problema.

Si devuelve el adaptador físico, compara las dos rutas candidatas y sus métricas. Una ruta local más específica, una entrada sobrante de otro cliente o una métrica más baja en la ruta física ganarán todas a una ruta de túnel amplia. El resultado visible son unos recursos inaccesibles mientras todo lo demás funciona. Los prefijos más largos siempre ganan, así que el vencedor suele ser una ruta de host que alguien añadió hace meses y olvidó.

Comprueba también ambas direcciones mientras estás aquí. Una ruta hacia el lado del servidor es necesaria pero no suficiente, porque la respuesta tiene que volver por el túnel igualmente. Cuando un host interno funciona y otro no, la diferencia suele estar en esta tabla y no en la configuración del adaptador.

Paso 3: separa la resolución de nombres del acceso al servicio

Una aplicación que no abre un recurso compartido puede estar fallando en una de dos etapas muy distintas. Resuelve el nombre y luego alcanza la dirección. Si lo primero falla y lo segundo funciona, el túnel está bien y el resolutor no:

Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445

Una prueba de dirección correcta junto con una prueba de nombre fallida localiza el problema en la resolución, y el segundo comando muestra si la interfaz del túnel recibió algún servidor. Muchos clientes envían DNS como parte de la configuración del túnel, y un perfil que ignora esas opciones recibidas dejará la máquina usando un resolutor que no ve la zona privada.

No tomes una dirección que funciona como la solución permanente. Conectarse por dirección omite la resolución de nombres y puede anular la comprobación de identidad del servidor que la aplicación haría de otro modo. Eso es una regresión de seguridad disfrazada de solución temporal. Úsala para localizar el fallo y después repara la resolución.

Reversión: no reconstruyas DHCP por un valor mostrado

Si ya has empezado a cambiar el servicio de direccionamiento, detente y comprueba si algo de lo que cambiaste es esencial. Recrear un ámbito, reemitir concesiones o mover el grupo cambia un estado del que dependen otros clientes, y nada de eso está justificado por una máscara de equipo en un adaptador punto a punto.

Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445

Ejecuta estos tres después de cualquier cambio puntual y compáralos con la ejecución anterior. El resultado útil es una ruta documentada hacia el recurso, no un adaptador cuya máscara se parezca a la LAN de la oficina.

Después anota qué significaba realmente la máscara, porque la siguiente persona abrirá el mismo diálogo y llegará a la misma conclusión equivocada. Una frase en las notas del perfil, diciendo que el túnel es punto a punto y que las subredes remotas llegan como rutas, ahorra toda la investigación la próxima vez.