O tunelamento completo é mais simples do que uma lista longa de tunelamento dividido?

Uma lista de tunelamento dividido começa com três aplicativos e acaba cobrindo a maior parte da máquina, e cada nova linha é a exceção de alguém. Nesse ponto a lista já se tornou, sem alarde, um padrão com etapas extras. O tunelamento completo inverte o arranjo: tudo entra no túnel, a menos que uma exclusão documentada diga o contrário. Se isso é mais simples depende do gateway e dos serviços locais que você quebraria.

Comece contando as regras que você mantém

Conte as entradas e depois conte quantas têm um responsável nomeado e uma data da última verificação. O segundo número é o que importa, porque uma exceção sem dono não pode ser avaliada quando o software a que ela se refere é renomeado ou substituído. Regras atreladas ao caminho de um executável falham silenciosamente após uma atualização, e a falha parece um VPN instável em vez de uma regra desatualizada. Anote a lista antes de ter uma opinião sobre ela.

Cada entrada deveria responder a três perguntas: o que quebra sem ela, quem decidiu isso e como você perceberia se o motivo tivesse expirado. Entradas que não respondem às três são candidatas à remoção, não à migração, e removê-las primeiro torna a comparação posterior honesta.

Se a maioria das entradas encaminha uma grande fatia do tráfego, você já opera um túnel completo com uma carga de manutenção embutida. A decisão passa a ser onde o padrão mora, não se deve existir um.

Verifique se o gateway consegue carregar o padrão

O tunelamento completo leva cada pacote a um único dispositivo, o que altera ao mesmo tempo a carga de CPU, a tabela conntrack, a tradução de endereços e a necessidade de banda de upstream desse dispositivo. Um gateway que atendia com folga algumas sub-redes internas pode não ter sido dimensionado para toda a navegação de um usuário. Olhe para o maior número de sessões simultâneas que você espera, não para a média, porque o pico é o que quebra primeiro.

ip -s link show dev tun0
conntrack -C
ss -s

Meça a mesma carga antes e depois da mudança em vez de raciocinar a partir de especificações. Uma única tarde de uso comum em uma máquina mostrará se o gateway está perto de um limite, e isso não custa nada comparado a descobrir numa manhã de segunda-feira.

Verifique também a MTU do caminho de ponta a ponta, porque um padrão completo expõe cada aplicativo ao tamanho máximo de pacote do túnel. Aplicativos que funcionavam fora do túnel podem agora depender de um comportamento de fragmentação que você nunca precisou considerar.

Confirme que os serviços locais e o DNS privado ainda funcionam

Enumere o que precisa ficar local por protocolo, e não por nome de aplicativo: protocolos de descoberta de impressoras e telas, uma ponte de casa inteligente, a página de administração de um roteador, um servidor de desenvolvimento local alcançado por um nome que só resolve na LAN. Essas coisas quebram quando a rota padrão começa a apontar para dentro de um túnel, e quebram em silêncio porque nada registra erro no cliente.

O DNS privado é a outra dependência. Se os nomes internos eram resolvidos pelo resolver do túnel antes, nada muda; se eram resolvidos localmente, um padrão completo precisa levá-los a um resolver que conheça as zonas. Teste um nome interno e um nome público depois da mudança em vez de supor que a lista de resolvers sobreviveu.

Escreva as exceções locais no perfil que é dono delas. Uma exceção guardada apenas na memória de alguém é a primeira coisa que a próxima migração perde.

Migre um perfil e verifique as fronteiras

Altere o perfil pela configuração que o possui, em vez de sobrepor um novo padrão a rotas manuais deixadas por experimentos anteriores. Essas rotas remanescentes são a causa usual de uma migração que parece funcionar e se comporta de forma inconsistente um dia depois. Mantenha o perfil antigo disponível para que reverter seja uma escolha e não uma reconstrução.

Depois verifique duas fronteiras separadamente: que destinos públicos e privados funcionam, e que o tráfego indesejado não sai fora do túnel. Um carregamento de página bem-sucedido prova a primeira e não diz nada sobre a segunda.

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

Repita a checagem após uma reconexão e após uma queda, porque um kill switch que bloqueia tráfego durante uma interrupção é uma propriedade diferente de uma rota que se restaura corretamente depois. O desenho mais simples é aquele cuja cobertura real você ainda consegue explicar depois que um aplicativo ou uma rede muda.