A VPN do Windows mostra 255.255.255.255: a máscara está errada?

O túnel liga-se, você abre os detalhes do adaptador e a máscara mostra 255.255.255.255. Comparada com a 255.255.255.0 da LAN do escritório, parece avariada, e é aí que normalmente começa o erro. Num enlace ponto a ponto, uma máscara de host é a descrição correta do extremo local, e as redes remotas chegam como rotas em vez de como uma sub-rede ligada. O procedimento abaixo separa as duas perguntas para que não reconstrua um âmbito DHCP que funciona só para corrigir um valor mostrado.

Um enlace ponto a ponto não é um segmento Ethernet

Uma interface Ethernet precisa de uma máscara de sub-rede porque cada endereço dessa faixa é potencialmente alcançável no mesmo cabo. Um túnel do tipo PPP tem exatamente um par na outra ponta. Não há domínio de difusão, nem ARP, nem razão para o endereço local descrever uma faixa.

A negociação de endereçamento para esse modelo está definida em RFC 1332, que cobre como as duas pontas acordam os seus endereços. O que ela não faz é entregar ao cliente a LAN do escritório como uma rede diretamente ligada. O cliente aprende onde está o escritório instalando rotas através do enlace, e são essas rotas que decidem realmente a acessibilidade.

Isto não é afirmar que toda a máscara que vê é correta. Um cliente mal configurado também pode produzir endereçamento estranho. O ponto é mais restrito: uma máscara de host neste tipo de adaptador é o esperado, por isso não é, por si só, prova de falha.

Passo 1: confirme o modelo da interface

Veja o que é o adaptador antes de julgar o que ele diz. A cadeia de descrição identifica o controlador, e o comprimento do prefixo no endereço atribuído confirma o que o cliente negociou:

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

O terceiro comando é o que resolve a maioria das discussões. Uma unidade máxima de transmissão baixa é típica de um enlace encapsulado, enquanto um valor semelhante ao de Ethernet sugere um modelo de adaptador virtual diferente. Se a descrição nomear um controlador PPP ou RAS e o prefixo for 32, está exatamente perante o desenho descrito acima e pode parar de se preocupar com a máscara.

Passo 2: leia a rota do destino que falha

A acessibilidade decide-se por destino, e uma única interface ligada não lhe diz nada sobre isso. Pergunte diretamente à tabela de rotas pelo endereço a que o utilizador está a tentar chegar:

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

Find-NetRoute é a resposta direta: indica a interface e o endereço de origem que o sistema usaria para esse destino. Se devolver o túnel, o tráfego para esse host passa pelo túnel e a máscara nunca foi o problema.

Se devolver o adaptador físico, compare as duas rotas candidatas e as suas métricas. Uma rota local mais específica, uma entrada deixada por outro cliente ou uma métrica mais baixa no caminho físico vencem todas uma rota de túnel ampla. O resultado visível são recursos inacessíveis enquanto tudo o resto funciona. Os prefixos mais longos vencem sempre, por isso o vencedor é muitas vezes uma rota de host que alguém acrescentou há meses e esqueceu.

Verifique também os dois sentidos enquanto está aqui. Uma rota para o lado do servidor é necessária mas não suficiente, porque a resposta tem de voltar pelo túnel. Quando um host interno funciona e outro não, a diferença está normalmente nesta tabela e não na configuração do adaptador.

Passo 3: separe a resolução de nomes do acesso ao serviço

Uma aplicação que não abre uma partilha pode estar a falhar numa de duas fases muito diferentes. Resolva o nome e depois alcance o endereço. Se a primeira falhar e a segunda funcionar, o túnel está bem e o resolvedor não:

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

Um teste de endereço bem-sucedido com um teste de nome falhado localiza o problema na resolução, e o segundo comando mostra se a interface do túnel recebeu algum servidor. Muitos clientes enviam o DNS como parte da configuração do túnel, e um perfil que ignore essas opções enviadas deixa a máquina a usar um resolvedor que não vê a zona privada.

Não trate um endereço funcional como a correção permanente. Ligar por endereço contorna a resolução de nomes e pode anular a verificação de identidade do servidor que a aplicação faria de outro modo. É uma regressão de segurança disfarçada de solução alternativa. Use-a para localizar a falha e depois repare a resolução.

Reversão: não reconstrua o DHCP por causa de um valor mostrado

Se já começou a alterar o serviço de endereçamento, pare e verifique se algo do que alterou é essencial. Recriar um âmbito, reemitir concessões ou mover o conjunto altera estado de que outros clientes dependem, e nada disso se justifica por uma máscara de host num adaptador ponto a ponto.

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

Execute estes três depois de qualquer alteração pontual e compare com a execução anterior. O resultado útil é um caminho documentado para o recurso, não um adaptador cuja máscara se pareça com a LAN do escritório.

Depois escreva o que a máscara significava realmente, porque a próxima pessoa abrirá o mesmo diálogo e chegará à mesma conclusão errada. Uma frase nas notas do perfil, a dizer que o túnel é ponto a ponto e que as sub-redes remotas chegam como rotas, poupa toda a investigação da próxima vez.