Os clientes VPN de RRAS necesitan o seu propio grupo IPv4 e un camiño de volta

O cliente VPN conéctase e recibe un enderezo, pero o equipo da LAN que necesita segue sen poder responderlle. En Windows Routing and Remote Access, o enderezo interno dos clientes VPN procede dun grupo configurado por separado do adaptador de LAN do servidor, e o lado da LAN necesita unha ruta de volta a ese grupo. Dous cambios, non un, e fallan de maneiras distintas. Fágaos en orde para que o plan de enderezos e o camiño de volta queden demostrados antes de retirar os rangos antigos.

Reserve o rango antes de abrir a consola

Escolla un prefixo que non se solape coa LAN, con outros rangos VPN nin con nada que se encamine cara ao sitio. Un /24 é un tamaño cómodo para unha proba, e a primeira parte utilizábel pódese entregar aos clientes mentres o resto queda libre para o crecemento. Anóteo co seu propósito e responsábel antes de escribilo nunha consola. Deixe espazo nos dous extremos do bloque para que unha división posterior non obrigue a renumerar.

Un plan de enderezos que só vive nunha consola está a unha reconstrución dunha colisión. Tamén tende a medrar: alguén engade un segundo rango máis adiante e ninguén comproba o primeiro. Garde o plan xunto á documentación do servidor, non nun fío de chat.

O adaptador de LAN do servidor non define este grupo. Cambiar o oínte público ou engadir un adaptador á LAN fai algo completamente distinto. Por iso os clientes poden conectarse e aínda así recibir un enderezo do lugar equivocado. O grupo vive nas propiedades IPv4 do servidor, non na lista de adaptadores.

Cambiar o método non é engadir un rango

RRAS ten un método de asignación e un conxunto de rangos. Pasar de DHCP a un grupo estático é un cambio de método. Engadir outro bloque mentres o grupo estático xa está activo é un cambio de rango.

Previsualice ambas as operacións antes de executar calquera, e lea cal coincide co estado actual do 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

O segundo cmdlet falla ou produce un grupo inservíbel se o servidor segue en asignación DHCP. O primeiro substitúe o método en lugar de ampliar un grupo existente. Ningunha das dúas previsualizacións aplica nada, así que execute a que coincida e despois confirme o grupo resultante na consola. Se non está seguro do estado do servidor, lea o método de asignación na páxina de propiedades IPv4 e enumere os rangos configurados:

Get-VpnIPAddressRange

Un método DHCP cunha lista de rangos baleira significa que se aplica a primeira previsualización. Un grupo de enderezos estático cun rango existente significa que se aplica a segunda.

Conte co reinicio do servizo que o axuste poida requirir, e non dea por feito que os clientes conectados se renumeran de inmediato. Un cliente que conserva o seu enderezo antigo ata reconectarse compórtase con normalidade. Planifique o cambio para unha xanela na que unha reconexión sexa aceptábel.

A LAN necesita unha ruta de volta

Supoña que a LAN é 10.60.0.0/24 e que o servidor RRAS é 10.60.0.10 nela. Un equipo desa LAN que responde a un cliente de 10.250.50.0/24 necesita un camiño cara ao grupo a través do servidor RRAS. Sen ese camiño a petición chega e a resposta morre.

Se a pasarela predeterminada do equipo é outro encamiñador, ese encamiñador necesita a ruta de volta para o prefixo VPN. Unha ruta estática no servidor RRAS non axuda aquí; o camiño de volta debe existir no dispositivo que posúe a pasarela da LAN, así que engádao á táboa de encamiñamento ou ao proceso de encamiñamento dinámico, segundo o que use o sitio.

Comprobe tamén a devasa do equipo e calquera regra de acceso á rede fronte ao novo rango de orixe. As regras escritas para o rango antigo de clientes rexeitan o novo aínda que a asignación funcionase. As rutas do cliente cara á LAN e a resolución DNS son requisitos separados, e ambos poden fallar mentres o túnel parece san. Probe cada un por separado.

Demostre o grupo novo nun só dispositivo antes de retirar o antigo

Colla unha autorización que controle, reconéctese e lea o enderezo de grupo que recibiu o cliente. Ese único número separa a asignación do encamiñamento. Despois exercite unha aplicación concreta, observe o tráfico de volta e probe un destino que deba seguir denegado. Tres observacións, tres modos de fallo distintos.

A resolución de nomes merece a súa propia proba: o acceso por IP pode funcionar mentres o DNS do cliente segue apuntando a un resolutor ao que non pode chegar. Un servidor DNS na LAN só é accesíbel se o cliente ten unha ruta cara a el e o servidor acepta consultas do novo rango. Ambos son fallos habituais cando se move o grupo.

Retire os rangos antigos e as súas excepcións só despois de ter en conta as sesións activas e o proceso de mantemento. Un cliente conectado cun enderezo novo demostra a asignación, non a política de acceso. Manteña documentado o rango antigo ata que caducase a última sesión que o usou.

Comprobe o resultado con tres observacións

A aceptación esixe tres feitos: o cliente ten un enderezo do grupo novo, un equipo da LAN pode alcanzalo e obter resposta, e un destino denegado segue denegado. Cada un ten a súa propia comprobación, así que un fallo apunta á asignación, ao encamiñamento ou á política. Execúteas nesa orde.

Desde o cliente, confirme o enderezo e a ruta a un equipo da LAN:

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

Desde o equipo da LAN, confirme o camiño de resposta e a política nunha soa pasada. Se ping falla pero a aplicación funciona, a peza que falta é probabelmente unha regra ICMP e non a ruta. Se fallan ambos, lea a ruta no equipo antes de editar a VPN. Anote os tres resultados no tícket de cambio para que a seguinte persoa comece con probas.