Acionador de VPN por aplicação no Windows vs túnel dividido: o que isola

Duas configurações do Windows parecem iguais em Definições e não se comportam nada do mesmo modo. Uma é um perfil VPN copiado com um acionador de aplicação, pelo que iniciar um executável levanta o túnel. A outra é um perfil de túnel dividido cuja lista de rotas abrange, por acaso, aquilo com que essa aplicação fala. A primeira responde a quando o túnel existe. A segunda responde a que pacotes entram nele, e só a segunda deixa o resto da máquina no link físico enquanto a aplicação continua ligada.

O acionador é uma regra de ciclo de vida, não uma regra de encaminhamento

Add-VpnConnectionTriggerApplication liga um caminho executável a um nome de perfil. Quando esse processo arranca, o Gestor de Ligações de Acesso Remoto marca o perfil, e quando a condição do acionador termina, a ligação pode cair. Nada nessa troca inspeciona sockets. O cmdlet exige uma shell elevada, o caminho completo para o binário e -Force quando substitui uma entrada existente. Confirme que a associação sobreviveu com Get-VpnConnectionTrigger em vez de confiar na mensagem; a referência de Add-VpnConnectionTriggerApplication lista os parâmetros e os exemplos.

Dois limites explicam a maioria dos relatos de que «o acionador não faz nada». Os acionadores assentam em perfis para todos os utilizadores, por isso o âmbito do perfil é a primeira coisa a resolver, e o caminho da aplicação tem de corresponder ao binário que realmente corre, não a um atalho nem a um lançador que gera um segundo processo. O outro limite é intencional: numa rede que o Windows classifica como fidedigna, o acionador fica inativo, porque o perfil destina-se a funcionar fora do escritório.

Add-VpnConnectionTriggerApplication -Name "APP_VPN" -ApplicationID "C:\Program Files\Vendor\app.exe" -Force
Get-VpnConnectionTrigger -Name "APP_VPN" | Format-List *
Get-VpnConnection -Name "APP_VPN" | Format-List Name,ConnectionStatus,SplitTunneling,AllUserConnection

O túnel dividido decide o que atravessa o túnel

Com o túnel dividido desligado, o Windows instala uma rota predefinida baseada na classe com uma métrica baixa na interface VPN. Todos os sockets a seguem, incluindo o navegador e o serviço de atualizações, pelo que um acionador nessa configuração move a máquina inteira enquanto o perfil estiver ligado. O acionador continua a ser apenas uma regra de ciclo de vida; o raio de impacto veio da rota.

Com o túnel dividido ligado, o perfil leva apenas os prefixos que a gateway empurra ou que acrescenta à interface VPN. Tudo o resto continua a usar a rota predefinida física. É a disposição que as pessoas costumam querer dizer com «uma aplicação por uma saída separada», e é uma decisão de encaminhamento de princípio a fim.

Set-VpnConnection -Name "APP_VPN" -SplitTunneling $true
Get-VpnConnection -Name "APP_VPN" | Select-Object SplitTunneling
Get-NetRoute -InterfaceAlias "APP_VPN" | Sort-Object DestinationPrefix

Onde um túnel dividido encaminhado deixa de isolar a sua aplicação

A falha comum é um destino que nunca aparece na lista de rotas do túnel. Uma aplicação que inicia sessão contra um endereço e depois faz streaming de um CDN, ou que resolve uma dúzia de pontos finais rotativos, coloca algumas ligações na interface VPN e o resto no Wi-Fi. O IPv6 é uma tabela separada, pelo que um perfil que só empurra prefixos IPv4 pode parecer correto enquanto o tráfego IPv6 da aplicação fica local.

Dois efeitos mais pequenos contam tanto como estes. Ganha a correspondência de prefixo mais longa, pelo que uma rota on-link mais específica, um /32 empurrado para um anfitrião de gestão ou a sub-rede de um segundo adaptador podem superar o túnel exatamente para o endereço que lhe interessa. A resolução também acontece antes do encaminhamento: a menos que os servidores DNS do perfil ou uma regra NRPT cubram o nome, a aplicação pode resolver pelo adaptador físico e depois marcar um endereço que nunca esteve dentro dos prefixos tunelados.

Três formas, e o que cada uma compra

A tabela é a parte que colaria na parede, porque a decisão é sobre o raio de impacto e não sobre funcionalidades. Se os destinos da aplicação forem prefixos estáveis que consegue listar, o túnel dividido encaminhado dá isolamento com a menor pegada. Se não forem, um perfil de rota predefinida atrás de uma VM ou de um segundo dispositivo mantém a separação honesta ao custo de mover mais do que um processo.

O que nenhuma destas opções oferece é ligação ao nível do socket no anfitrião. O cliente VPN clássico do Windows não tem nenhuma regra que diga que este processo tem de usar aquele adaptador; os acionadores e os filtros de rotas vivem em camadas diferentes, e a camada que escolhe uma interface é a tabela de rotas. Se um guia prometer aplicação por aplicação apenas a partir de um perfil copiado, pergunte que rota ou que filtro faz o trabalho.

Verifique o par numa só passagem

Teste o ciclo de vida e o encaminhamento em separado, nessa ordem. Feche a aplicação, confirme que o perfil indica Disconnected, depois inicie a aplicação e verifique se o estado mudou. Só depois de o túnel estar levantado deve perguntar para onde vai um destino concreto, e deve usar o endereço que a aplicação marca de facto em vez de uma suposição.

$app = Get-Process app | Select-Object -First 1
Get-VpnConnection -Name "APP_VPN" | Select-Object ConnectionStatus
Get-NetTCPConnection -OwningProcess $app.Id -State Established | Select-Object RemoteAddress,RemotePort
Find-NetRoute -RemoteIPAddress 203.0.113.10

Find-NetRoute nomeia a interface e o próximo salto que levariam esse destino. Um alias físico aí significa que o túnel está levantado e é irrelevante para esse fluxo: verifique os prefixos empurrados, depois as rotas mais específicas, depois o IPv6. Se o estado nunca mudar, o acionador não disparou, e o caminho do executável, o âmbito do perfil e o registo operacional do cliente VPN são os três sítios onde olhar.

Desfaça com limpeza para que o próximo teste seja honesto

Remova na ordem inversa à que construiu: primeiro o acionador da aplicação, depois o perfil. Apagar o perfil com o acionador ainda presente deixa uma associação pendente que torna confusa a tentativa seguinte, e Remove-VpnConnection -Force nem sempre limpa uma entrada da lista telefónica criada fora dos cmdlets.

As entradas por utilizador vivem no rasphone.pbk do utilizador, no perfil Roaming; as entradas para todos os utilizadores vivem em ProgramData. Verifique o armazenamento que corresponde ao âmbito do perfil, volte a ligar o perfil que guardou e confirme que as suas rotas e o DNS continuam a comportar-se, para que um teste posterior meça a alteração feita e não o estado remanescente.

• O túnel arranca no início do processo, não no início de sessão.
• Só os prefixos previstos aparecem na interface VPN.
• O endereço remoto real da aplicação resolve-se no alias da VPN.
• Não fica nenhum acionador pendente depois de remover o perfil.