Os clientes VPN do RRAS precisam do próprio conjunto IPv4 e de um caminho de volta

O cliente VPN liga-se e recebe um endereço, mas o host da LAN de que precisa continua sem lhe conseguir responder. No Windows Routing and Remote Access, o endereço interno dos clientes VPN vem de um conjunto configurado separadamente do adaptador de LAN do servidor, e o lado da LAN precisa de uma rota de volta para esse conjunto. Duas mudanças, não uma, e falham de formas diferentes. Faça-as por ordem para que o plano de endereços e o caminho de volta fiquem provados antes de retirar os intervalos antigos.

Reserve o intervalo antes de abrir a consola

Escolha um prefixo que não se sobreponha à LAN, a outros intervalos VPN nem a nada que seja encaminhado para o site. Um /24 é um tamanho cómodo para um teste, e a primeira parte utilizável pode ser entregue aos clientes enquanto o resto fica livre para crescimento. Anote-o com o propósito e o responsável antes de o escrever numa consola. Deixe espaço nas duas pontas do bloco para que uma divisão posterior não obrigue a renumerar.

Um plano de endereços que só vive numa consola está a uma reconstrução de uma colisão. Também tende a crescer: alguém acrescenta um segundo intervalo mais tarde e ninguém verifica o primeiro. Guarde o plano junto da documentação do servidor, não num fio de conversa.

O adaptador de LAN do servidor não define este conjunto. Alterar o ouvinte público ou acrescentar um adaptador à LAN faz algo completamente diferente. É por isso que os clientes se podem ligar e ainda assim receber um endereço do sítio errado. O conjunto vive nas propriedades IPv4 do servidor, não na lista de adaptadores.

Mudar o método não é acrescentar um intervalo

O RRAS tem um método de atribuição e um conjunto de intervalos. Passar de DHCP para um conjunto estático é uma mudança de método. Acrescentar outro bloco enquanto o conjunto estático já está ativo é uma mudança de intervalo.

Pré-visualize as duas operações antes de executar qualquer uma, e leia qual corresponde ao estado atual 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 falha ou produz um conjunto inutilizável se o servidor ainda estiver em atribuição DHCP. O primeiro substitui o método em vez de ampliar um conjunto existente. Nenhuma das pré-visualizações aplica nada, por isso execute a que corresponde e depois confirme o conjunto resultante na consola. Se não tiver a certeza do estado do servidor, leia o método de atribuição na página de propriedades IPv4 e liste os intervalos configurados:

Get-VpnIPAddressRange

Um método DHCP com uma lista de intervalos vazia significa que se aplica a primeira pré-visualização. Um conjunto de endereços estático com um intervalo existente significa que se aplica a segunda.

Conte com o reinício do serviço que a definição possa exigir, e não assuma que os clientes ligados são renumerados de imediato. Um cliente que mantém o endereço antigo até se voltar a ligar comporta-se normalmente. Planeie a mudança para uma janela em que uma nova ligação seja aceitável.

A LAN precisa de uma rota de volta

Suponha que a LAN é 10.60.0.0/24 e que o servidor RRAS é 10.60.0.10 nela. Um host dessa LAN que responde a um cliente em 10.250.50.0/24 precisa de um caminho para o conjunto através do servidor RRAS. Sem esse caminho o pedido chega e a resposta morre.

Se a porta de ligação predefinida do host for outro router, esse router precisa da rota de volta para o prefixo VPN. Uma rota estática no servidor RRAS não ajuda aqui; o caminho de volta tem de existir no dispositivo que possui a porta de ligação da LAN, por isso acrescente-o à tabela de encaminhamento ou ao processo de encaminhamento dinâmico, conforme o que o site usar.

Verifique também a firewall do host e quaisquer regras de acesso à rede face ao novo intervalo de origem. As regras escritas para o intervalo antigo de clientes rejeitam o novo mesmo que a atribuição tenha funcionado. As rotas do cliente para a LAN e a resolução DNS são requisitos separados, e ambos podem falhar enquanto o túnel parece saudável. Teste cada um em separado.

Prove o novo conjunto num único dispositivo antes de retirar o antigo

Pegue numa autorização que controle, volte a ligar e leia o endereço de conjunto que o cliente recebeu. Esse único número separa a atribuição do encaminhamento. Depois exercite uma aplicação concreta, observe o tráfego de volta e experimente um destino que deva continuar negado. Três observações, três modos de falha diferentes.

A resolução de nomes merece um teste próprio: o acesso por IP pode funcionar enquanto o DNS do cliente ainda aponta para um resolvedor que não alcança. Um servidor DNS na LAN só é acessível se o cliente tiver uma rota até ele e o servidor aceitar consultas do novo intervalo. Ambos são falhas comuns quando o conjunto se desloca.

Retire os intervalos antigos e as suas exceções apenas depois de ter em conta as sessões ativas e o processo de manutenção. Um cliente ligado com um endereço novo prova a atribuição, não a política de acesso. Mantenha o intervalo antigo documentado até a última sessão que o usou ter expirado.

Verifique o resultado com três observações

A aceitação exige três factos: o cliente tem um endereço do novo conjunto, um host da LAN consegue alcançá-lo e obter resposta, e um destino negado continua negado. Cada um tem a sua verificação, por isso uma falha aponta para atribuição, encaminhamento ou política. Execute-as nessa ordem.

Do cliente, confirme o endereço e a rota para um host da LAN:

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

Do host da LAN, confirme o caminho de resposta e a política numa só passagem. Se o ping falhar mas a aplicação funcionar, a peça em falta é provavelmente uma regra ICMP e não a rota. Se ambos falharem, leia a rota no host antes de editar a VPN. Registe os três resultados no ticket de mudança para que a próxima pessoa comece pelas provas.