Always On VPN não é acesso à LAN: lista de verificação de recursos
O Always On descreve um ciclo de vida de ligação, não uma concessão de recursos. Verifique o papel do túnel, as rotas, o DNS privado e os filtros de tráfego face à aplicação de que precisa.
O Always On é um ciclo de vida de ligação: o perfil liga-se no início de sessão ou antes e volta a ligar-se sem que o utilizador carregue em nada. Isso não significa que todos os destinos privados, protocolos e utilizadores estejam autorizados. A questão prática é que recursos o perfil implementado entrega realmente, e essa resposta exige uma verificação por recurso, não um olhar para o distintivo Connected.
Passo 1: registe o recurso antes de o testar
Comece com uma ficha curta por aplicação, retirada do ambiente real: nome, prefixo de destino, serviço e porta, papel do túnel, grupo de identidade e caminho do resolvedor.
Name: portal.corp.example
Destination: 10.20.5.0/24
Service: HTTPS 443
Tunnel role: user access after sign-in
Identity: assigned employee group
Resolver: corporate private DNSA ficha obriga a quatro perguntas separadas. A rota decide para onde vai o endereço; a política de DNS decide como o cliente aprende o endereço; o filtro de tráfego decide se esse tráfego pode usar a ligação; a firewall e as permissões da aplicação de destino decidem se o pedido é aceite. Nenhuma das quatro decorre de um túnel ligado.
Passo 2: determine que túnel o deve transportar
O Windows Always On VPN tem um túnel de dispositivo e um túnel de utilizador, configurados como perfis separados com certificados e âmbitos separados. O túnel de dispositivo transporta normalmente apenas a infraestrutura necessária antes do início de sessão, como gestão e serviços de domínio; o acesso amplo dos colaboradores às aplicações pertence ao túnel de utilizador.
Os filtros de tráfego são uma funcionalidade do túnel de dispositivo, e é por isso que o exemplo da Microsoft os usa para tráfego de gestão. Copiar esse exemplo para um perfil genérico de recursos dá um túnel que liga mas transporta o conjunto errado. Confirme a ligação ativa com Get-VpnConnection e teste nessa ligação.
Passo 3: verifique a rota para o endereço real
Resolva o nome uma vez e depois verifique a rota: Find-NetRoute -RemoteIPAddress 10.20.5.10 indica a interface escolhida, o próximo salto e o endereço de origem. Se a interface for o adaptador físico, o prefixo não está no conjunto de rotas do túnel ou o cliente excluiu-o com túnel dividido. Compare com a definição do perfil em vez de acrescentar uma rota local.
Um route add local pode fazer passar o teste e desaparecer na atualização de política seguinte, por isso a alteração pertence ao perfil gerido. Verifique o prefixo nos perfis de utilizador e de dispositivo e a definição de túnel dividido: o túnel completo não precisa de rota por prefixo, o dividido precisa de uma por cada prefixo privado que transporta.
Passo 4: teste a resolução de nomes privados em separado
Os nomes privados têm o seu próprio caminho de política. O perfil pode fornecer regras NRPT e uma lista de pesquisa de sufixos DNS, válidas enquanto o túnel está ativo. Leia com Get-DnsClientNrptPolicy o que o cliente recebeu realmente e teste um nome e um endereço na mesma sessão. Se os nomes falharem e os endereços funcionarem, é o resolvedor; se ambos falharem, é a rota.
Um nome também pode resolver para um endereço fora das rotas do túnel, o que mistura sucesso com tempo esgotado. Compare o endereço devolvido com o prefixo da ficha; se diferirem, a zona privada responde com um endereço público ou alternativo e a rota que coincidiu não é a desenhada.
Passo 5: verifique filtros, identidade e a porta da própria aplicação
Os filtros de tráfego limitam que protocolos e portas podem usar o túnel de dispositivo, e um conjunto estreito pode bloquear um recurso que a rota transportaria. O perfil atribui a ligação a um grupo, mas o recurso tem a sua própria autorização: um utilizador que consegue ligar-se não é aceite automaticamente pelo servidor de ficheiros.
Altere o perfil gerido através do proprietário, seja Intune, uma implementação ProfileXML ou um script de operações, e volte a testar após uma reconexão normal e após um reinício: a falha habitual é uma rota local desatualizada ou um perfil aplicado uma só vez. Guarde a versão do perfil ao lado do resultado do teste.