Seu túnel dividido exclui o launcher, não o jogo

Você adiciona o launcher à lista de exclusões, o download passa de lento para rápido, e a partida ainda cai em um servidor distante. Nada está quebrado. O launcher e o jogo são dois processos com dois conjuntos de sockets, e excluir um não diz nada sobre o outro. O download ficou mais rápido porque o download era o tráfego do launcher; a partida é a conexão de outra pessoa, aberta por um executável que sua regra nunca viu.

Um instalador, muitos processos

O software de jogos moderno é uma pequena constelação. Há um cliente que faz login, um atualizador que baixa conteúdo, um launcher que inicia o jogo e um executável do jogo que pode ele mesmo gerar um segundo processo para o anti-cheat ou para a camada de matchmaking. Cada um deles pode manter as próprias conexões para os próprios destinos.

Uma regra de exclusão normalmente nomeia um deles. Qual nomeia depende inteiramente do identificador que o cliente VPN suporta, e essa é a parte que os usuários raramente verificam. Alguns clientes comparam um caminho de executável, outros um identificador de pacote ou bundle, e outros um nome de processo que dois binários não relacionados podem compartilhar. Leia a regra antes de ler a lista de processos, porque a regra limita até o que você pode expressar.

O sintoma, portanto, não é «o túnel dividido está quebrado». É «a regra cobre um processo que não é o que carrega o tráfego que me importa», o que é uma afirmação muito mais estreita e muito mais reparável. Quando você diz isso assim, o próximo passo deixa de ser adivinhação.

Encontre o processo que possui a conexão da partida

Inicie o jogo, entre em uma partida e veja quem possui os sockets em vez de ver o que está na tela. No Windows, a lista de processos mais uma consulta de sockets por processo respondem a isso em dois comandos:

Get-Process | Where-Object { $_.ProcessName -match 'launcher|game|client' } | Select-Object Id,ProcessName,Path
Get-NetTCPConnection -State Established | Select-Object OwningProcess,RemoteAddress,RemotePort | Sort-Object OwningProcess

O segundo comando imprime um ID de processo, não um nome, então junte as duas saídas pelo ID. A linha que você procura é a que tem o endereço remoto do serviço do jogo, e o processo que a possui é o executável que sua regra deve nomear.

No Linux, a mesma pergunta exige um comando por tipo de socket, e vale a pena verificar os dois, porque a conexão da partida pode ser UDP enquanto todo o resto é TCP:

ss -tunp state established | grep -i game
ss -tunp | awk 'NR==1 || /udp/'

Se o jogo roda em um contêiner ou em uma camada de compatibilidade, o processo que você encontra pode ser um shim em vez do binário que você instalou. Nesse caso, o identificador que importa é o que o cliente vê, que pode ser o caminho do shim, e nenhuma edição do arquivo original vai afetar isso.

Combine o identificador que seu cliente suporta

Leia a documentação do cliente sobre a regra de exclusão antes de adicionar qualquer coisa. Os três modelos comuns se comportam de forma diferente, e um deles é uma armadilha.

As regras de caminho são as mais precisas e as mais frágeis. Uma atualização do launcher que move o executável deixa a regra apontando para um arquivo que não roda mais, e o sintoma volta sem que nada mude de forma evidente. As regras de pacote sobrevivem a isso, e também podem cobrir silenciosamente processos auxiliares em que você nunca pensou, o que é conveniente ou alarmante dependendo do auxiliar.

Seja o que for que o cliente suporte, não adicione entradas para cada executável que encontrar. Uma lista montada por tentativa e erro até uma sessão funcionar não pode ser revisada, e vai acumular silenciosamente exceções para software não relacionado. Nomeie o processo que você encontrou e anote para que ele servia.

Teste na partida, não em um download

A velocidade de download do launcher é o pior teste possível, porque exercita exatamente o processo que já estava excluído. Use o que estava falhando e verifique o caminho em vez da tela de desempenho do próprio jogo:

ip route get 203.0.113.55
Get-NetTCPConnection -State Established | Where-Object RemotePort -eq 27015

O primeiro comando precisa do endereço para o qual o servidor da partida resolveu, que o log de conexões do jogo ou o seu cliente pode fornecer. Se a rota nomear a interface física, a regra está funcionando. O segundo mostra se existe uma sessão, o que separa «excluído, mas o servidor está fora do ar» de «não excluído».

Mantenha a região e a rede de acesso fixas durante o teste. Uma partida que cai em um data center diferente a cada tentativa produz endereços diferentes, e você vai acabar perseguindo um alvo móvel em vez de validar uma regra. Duas execuções com o mesmo endereço valem mais que dez com endereços diferentes.

Verifique novamente após a próxima atualização

Qualquer regra baseada em caminho tem uma vida útil medida em ciclos de patch. Quando o jogo parar de respeitar a exclusão um mês depois, a primeira coisa a verificar é se o executável mudou de lugar, e a segunda é se apareceu um novo processo auxiliar ao lado dele.

O modelo de exclusão de aplicativos documentado por um cliente é uma referência razoável para como essas regras são descritas, embora os detalhes variem entre produtos. Leia o seu, registre o identificador usado e anote a data. Esse registro é o que transforma um mistério em uma correção de cinco minutos na próxima vez que o launcher lançar uma atualização.

Se o cliente simplesmente não consegue expressar o limite de que você precisa, uma política mais ampla aprovada é melhor que um monte de exceções não documentadas. Amplo e compreendido vence estreito e errado, especialmente quando a versão estreita é o que todos acreditam estar em vigor.