Corrigir roteamento dividido de VPN ignorando rotas após suspensão no Windows 11

Solução rápida: Após suspender, a tabela de rotas do Windows é parcialmente reconstruída — às vezes perdendo as rotas de split tunneling adicionadas via route add. Restabeleça a conexão VPN ou crie uma tarefa no Agendador de Tarefas acionada ao “acordar” que execute novamente seu script de roteamento automaticamente.

Seu cliente VPN usa split tunneling: apenas sub-redes específicas passam pela VPN, todo o resto roteia normalmente. Antes da suspensão, a configuração estava correta — route print mostrava as rotas VPN para sua sub-rede corporativa, e o restante do tráfego ia direto. Após acordar da suspensão, essas rotas VPN desapareceram. O tráfego que deveria passar pela VPN agora tenta alcançar a sub-rede corporativa diretamente e falha.

Por que as rotas de split tunneling desaparecem

Quando o Windows suspende, o adaptador de rede frequentemente se desassocia — especialmente em laptops onde o Wi-Fi é desabilitado para economizar energia. Ao acordar, o adaptador reconecta e o Windows reconstrói a tabela de roteamento a partir da configuração base DHCP/estática. As rotas injetadas pela VPN que foram adicionadas via route add após o túnel VPN ser estabelecido não estão na configuração base; elas são perdidas. O túnel VPN geralmente reconecta, mas as rotas que direcionavam o tráfego para ele não.

A maioria dos clientes VPN lida com isso usando seu próprio watchdog: detectam mudanças no estado do adaptador e readicionam as rotas. O problema surge com VPNs que não fazem isso (ou com configurações manuais de route add).

Método 1: Restabeleça a VPN para repovoar as rotas

1. Desconecte a VPN pela interface do cliente.
2. Reconecte.
3. Abra o Prompt de Comando como administrador e execute route print. Confirme se as rotas da sua sub-rede VPN voltaram.
4. Teste pingando um IP interno — deve funcionar.

Esta é a solução rápida para toda vez. O cliente VPN executa novamente seu script pós-conexão que adiciona as rotas. Muitos usuários fazem isso rotineiramente após cada suspensão; os próximos métodos automatizam isso.

Método 2: Configure uma tarefa agendada ao acordar da suspensão

Automatize a correção das rotas acionando um script ao acordar o sistema.

1. Crie seu script de rotas C:\Scripts\vpn-rotas.cmd:

   @echo off

   route add 10.0.0.0 mask 255.255.0.0 10.99.99.1 if X

   route add 172.16.0.0 mask 255.240.0.0 10.99.99.1 if X

   (Substitua 10.0.0.0, 10.99.99.1 (gateway VPN) e X (índice da interface) pelos seus valores. Obtenha o índice da interface com route print.)

2. Abra o Agendador de Tarefas. Crie uma nova tarefa.
3. Em Gatilhos, clique em Novo. Defina iniciar tarefa como Em um evento. Log: System; Origem: Power-Troubleshooter; ID do evento: 1. Isso dispara quando o sistema retoma da suspensão.
4. Em Ações, clique em Novo. Ação: Iniciar um programa. Programa: C:\Scripts\vpn-rotas.cmd.
5. Em Geral, marque Executar com privilégios mais altos.
6. Salve e teste suspendendo e acordando o laptop.

O script é executado imediatamente após acordar. Se sua VPN reconectar automaticamente, as rotas são adicionadas sobre isso — a tabela de roteamento fica idêntica à de antes da suspensão em segundos.

Método 3: Configure o comportamento de reconexão do cliente VPN

Diferentes clientes VPN lidam com a suspensão de maneiras distintas. Otimize o que você usa.

1. OpenVPN GUI: edite seu arquivo .ovpn e adicione persist-tun, persist-key e resolv-retry infinite. Defina --script-security 2 e use o hook --up para adicionar rotas — isso é executado em cada reconexão, inclusive após suspensão.
2. WireGuard: as rotas adicionadas via AllowedIPs persistem através do ciclo de vida da interface — geralmente nenhuma configuração extra é necessária. Se as rotas ainda desaparecerem, configure a interface para reconectar automaticamente ao acordar (clique com o botão direito no túnel na interface do WireGuard → Ativar Ativação sob Demanda).
3. Cisco AnyConnect: ative a configuração de perfil “VPN Automática” e configure a detecção de rede confiável para que o cliente restabeleça imediatamente.
4. VPN nativa do Windows: configure a reconexão automática via PowerShell: Set-VpnConnection -Name “SuaVPN” -RememberCredential $True -AutoTriggerEnabled $True.

A configuração correta no lado do cliente elimina a etapa manual. Configure uma vez e esqueça.

Como verificar se a correção funcionou

• Execute route print antes de suspender. Anote suas rotas VPN.
• Suspenda por 5 minutos e depois acorde.
• Aguarde 10 segundos para a reconexão ser concluída.
• Execute route print novamente. As mesmas rotas VPN devem estar presentes.
• Pingue um IP interno. Deve funcionar.
• Repita com uma suspensão mais longa (30+ minutos) e verifique se as rotas ainda retornam.

Se nenhum desses funcionar

Se as rotas não forem readicionadas mesmo com o Método 2 em vigor, o gatilho do Agendador de Tarefas pode não estar disparando — verifique Agendador de Tarefas → guia Histórico para sua tarefa. Se nenhum evento de histórico aparecer, o gatilho não está correspondendo ao evento real. Tente um gatilho mais amplo como “Ao fazer logon” combinado com um atraso. Para configurações de VPN corporativas onde o cliente VPN do departamento de TI deveria lidar com isso automaticamente, encaminhe para a TI — eles podem ter um perfil mal configurado. Para OpenVPN especificamente, verifique o arquivo de log em busca de erros “route add” que sugiram que a rota não foi adicionada porque a interface ainda não está pronta — adicione um atraso (sleep) antes dos comandos de rota no script --up.

Conclusão: As rotas de split tunneling desaparecem porque a tabela de roteamento é reconstruída ao acordar. Restabeleça a VPN manualmente, automatize via Agendador de Tarefas no evento de acordar ou configure o cliente VPN para lidar com isso. A abordagem do Agendador de Tarefas é a correção mais universal.