Executando verificação de segurança...
2

Pitch: Chega de dor de cabeça pra configurar rotas manuais na sua VPN split tunnel

VPNs, full/split tunnel e o pesadelo que muitos enfrentam

Numa VPN "normal", o comportamento mais comum é o full tunnel: você conecta, e todo o tráfego da máquina passa a sair por aquele túnel. Isso resolve o problema de forma bruta. Tudo vai pelo mesmo caminho e pronto. Já no split tunnel, a ideia é outra: só uma parte do tráfego deve passar pela VPN, enquanto o resto continua saindo pela rota normal. E é justamente aí que começa o problema.

No dia a dia, o split tunnel pode ser uma boa ideia, mas quase sempre vira uma confusão no final das contas. Você não quer que a máquina inteira entre na VPN, você quer só um navegador, só um terminal, só um SSHzinho, só aquele acesso a uma subnet específica da empresa, o restante do seu trabalho deveria continuar usando a rede padrão, sem interferência.

Na prática, isso normalmente vira um "é só mais uma rotinha", no fim, você acaba precisando confirmar se o tráfego realmente saiu por onde deveria, ai precisa corrigir quando uma mudança afeta outra coisa que já estava funcionando e quando menos vê, já é uma confusão só, se tem mais de uma VPN envolvida ainda ou precisa alternar entre redes diferentes, ai já era 💀💀

Para solução desse problema, lhes apresento, NetLeak

WireGuard OpenVPN strongSwan SoftEther

A ideia dele é bem mais simples do que a forma como esse problema costuma ser resolvido: em vez de reconfigurar a rede da máquina toda vez que você quer usar uma interface específica, você escolhe a interface no momento em que executa o processo. Em vez de pensar "como eu altero a tabela de rotas para acomodar essa nova rede", a lógica vira, "só executa ai", onde tudo vira: esse processo aqui deve sair por esse caminho, enquanto o resto continua exatamente como está.

Pensa num caso bem comum, você está trabalhando normalmente no Chrome por exemplo, com um ticket aberto, dashboards abertas, documentação, fazendo um download pesado, tudo na sua conexão normal, derrepente, precisa abrir um Firefox para acessar um recurso interno da empresa que só responde por uma VPN específica, o que você quer não é mudar a máquina inteira para dentro da VPN. O que você quer é abrir só aquele Firefox pela interface certa e seguir trabalhando normalmente no resto.

Ou então um cenário ainda mais cotidiano para quem trabalha com rede, infra ou backend. Você precisa fazer SSH para vários servidores diferentes em subnets diferentes, um ambiente está acessível por uma VPN, outro por outra, apartir dai, é muito fácil esse tipo de fluxo virar uma mistura de rota estática, exceção manual e tentativa e erro. O NetLeak veio justamente para fugir disso.

Exemplos de uso

Confirmando a saída pela interface certa:

# Saindo pela sua rota padrão
curl ifconfig.me
# Agora confirmando a saída pela VPN sem alterar nada
sudo netleak ppp0 curl ifconfig.me

Logando um servidor SSH com IP privado pela VPN

# SSH sem alterar nenhuma rota, com split tunnel
sudo netleak wg0 ssh user@servidor-privado

Outros casos de uso

# Acessar alguns sites da empresa pela VPN sem alterar rotas
sudo netleak en firefox
# Abrir um shell inteiro saindo pela sua 2° interface de rede
sudo netleak eno2 bash

A partir daí, o problema deixa de ser "como eu mexo nas rotas para suportar esse novo cenário" e passa a ser só "qual interface esse processo deve usar". Para mim, esse era o pedaço que sempre faltava quando eu pensava em split tunnel no Linux, menos configuração e mais controle localizado (por processo :)

Caso alguém se interesse em testar o projeto com suas múltiplas VPNs e interfaces de rede, ele é completamente open source feito pela comunidade para a comunidade. E não se esqueça de dar o feedback se gostar projeto. Até mais!

Carregando publicação patrocinada...