Los clientes VPN de RRAS necesitan su propio grupo IPv4 y una vía de vuelta

El cliente VPN se conecta y recibe una dirección, pero el equipo de la LAN que necesita sigue sin poder responderle. En Windows Routing and Remote Access, la dirección interna de los clientes VPN procede de un grupo configurado por separado del adaptador de LAN del servidor, y el lado de la LAN necesita una ruta de vuelta a ese grupo. Dos cambios, no uno, y fallan de maneras distintas. Hágalos en orden para que el plan de direcciones y la vía de vuelta queden demostrados antes de retirar los rangos antiguos.

Reserve el rango antes de abrir la consola

Elija un prefijo que no se solape con la LAN, con otros rangos VPN ni con nada que se enrute hacia el sitio. Un /24 es un tamaño cómodo para una prueba, y la primera parte utilizable se puede entregar a los clientes mientras el resto queda libre para crecer. Anótelo con su propósito y responsable antes de escribirlo en una consola. Deje espacio en ambos extremos del bloque para que una división posterior no obligue a renumerar.

Un plan de direcciones que solo vive en una consola está a una reconstrucción de una colisión. También tiende a crecer: alguien añade un segundo rango más adelante y nadie comprueba el primero. Guarde el plan junto a la documentación del servidor, no en un hilo de chat.

El adaptador de LAN del servidor no define este grupo. Cambiar el escucha público o añadir un adaptador a la LAN hace algo completamente distinto. Por eso los clientes pueden conectarse y aun así recibir una dirección del lugar equivocado. El grupo vive en las propiedades IPv4 del servidor, no en la lista de adaptadores.

Cambiar el método no es añadir un rango

RRAS tiene un método de asignación y un conjunto de rangos. Pasar de DHCP a un grupo estático es un cambio de método. Añadir otro bloque mientras el grupo estático ya está activo es un cambio de rango.

Previsualice ambas operaciones antes de ejecutar cualquiera, y lea cuál coincide con el estado actual del servidor:

Set-VpnIPAddressAssignment -IPAssignmentMethod StaticPool -IPAddressRange '10.250.50.10','10.250.50.100' -WhatIf
Add-VpnIPAddressRange -IPAddressRange '10.250.50.110','10.250.50.150' -WhatIf

El segundo cmdlet falla o produce un grupo inservible si el servidor sigue en asignación DHCP. El primero sustituye el método en lugar de ampliar un grupo existente. Ninguna de las dos previsualizaciones aplica nada, así que ejecute la que coincida y luego confirme el grupo resultante en la consola. Si no está seguro del estado del servidor, lea el método de asignación en la página de propiedades IPv4 y enumere los rangos configurados:

Get-VpnIPAddressRange

Un método DHCP con una lista de rangos vacía significa que se aplica la primera previsualización. Un grupo de direcciones estáticas con un rango existente significa que se aplica la segunda.

Cuente con el reinicio del servicio que el ajuste pueda requerir, y no dé por hecho que los clientes conectados se renumeren de inmediato. Un cliente que conserva su dirección antigua hasta reconectarse se comporta con normalidad. Planifique el cambio para una ventana en la que una reconexión sea aceptable.

La LAN necesita una ruta de vuelta

Suponga que la LAN es 10.60.0.0/24 y que el servidor RRAS es 10.60.0.10 en ella. Un equipo de esa LAN que responde a un cliente de 10.250.50.0/24 necesita una vía hacia el grupo a través del servidor RRAS. Sin esa vía, la petición llega y la respuesta muere.

Si la puerta de enlace predeterminada del equipo es otro router, ese router necesita la ruta de vuelta para el prefijo VPN. Una ruta estática en el servidor RRAS no ayuda aquí; la vía de vuelta debe existir en el dispositivo que posee la puerta de enlace de la LAN, así que añádala a la tabla de enrutamiento o al proceso de enrutamiento dinámico, según lo que use el sitio.

Compruebe también el cortafuegos del equipo y cualquier regla de acceso a la red frente al nuevo rango de origen. Las reglas escritas para el rango antiguo de clientes rechazan el nuevo aunque la asignación haya funcionado. Las rutas del cliente hacia la LAN y la resolución DNS son requisitos separados, y ambos pueden fallar mientras el túnel parece sano. Pruebe cada uno por separado.

Demuestre el grupo nuevo en un solo dispositivo antes de retirar el antiguo

Tome una autorización que controle, reconéctese y lea la dirección de grupo que recibió el cliente. Ese único número separa la asignación del enrutamiento. Luego ejercite una aplicación concreta, observe el tráfico de vuelta y pruebe un destino que deba seguir denegado. Tres observaciones, tres modos de fallo distintos.

La resolución de nombres merece su propia prueba: el acceso por IP puede funcionar mientras el DNS del cliente sigue apuntando a un resolutor al que no puede llegar. Un servidor DNS en la LAN solo es accesible si el cliente tiene una ruta hacia él y el servidor acepta consultas del nuevo rango. Ambos son fallos habituales cuando se mueve el grupo.

Retire los rangos antiguos y sus excepciones solo después de tener en cuenta las sesiones activas y el proceso de mantenimiento. Un cliente conectado con una dirección nueva demuestra la asignación, no la política de acceso. Mantenga documentado el rango antiguo hasta que haya caducado la última sesión que lo usó.

Compruebe el resultado con tres observaciones

La aceptación exige tres hechos: el cliente tiene una dirección del grupo nuevo, un equipo de la LAN puede alcanzarlo y obtener respuesta, y un destino denegado sigue denegado. Cada uno tiene su propia comprobación, así que un fallo apunta a la asignación, al enrutamiento o a la política. Ejecútelas en ese orden.

Desde el cliente, confirme la dirección y la ruta a un equipo de la LAN:

ipconfig | findstr /i "IPv4"
route print -4

Desde el equipo de la LAN, confirme la vía de respuesta y la política en una sola pasada. Si ping falla pero la aplicación funciona, la pieza que falta es probablemente una regla ICMP y no la ruta. Si fallan ambos, lea la ruta en el equipo antes de editar la VPN. Anote los tres resultados en el tique de cambio para que la siguiente persona empiece con pruebas.