O que é um túnel VPN e onde a proteção termina

O cliente diz ligado, o cadeado está fechado e um site ainda registra o endereço do teu apartamento. Nada falhou. Um túnel não substitui a tua Wi-Fi nem a ligação móvel; coloca um segundo envelope à volta de determinados pacotes e envia esse envelope pela rede que já tinhas. Compreender o truque passa sobretudo por seguir um pedido e notar onde o envelope é aberto, porque quase todos os sintomas confusos, desde um endereço de casa que escapa até um grande download encravado, vêm dessa fronteira.

Dois envelopes, uma ligação física

O teu portátil mantém a ligação normal ao router, e o router mantém a ligação normal ao fornecedor. Nada nesse caminho muda quando um túnel sobe. O que muda é que determinados pacotes são entregues a uma interface virtual, embrulhados num pacote novo endereçado ao par de VPN e enviados como tráfego comum pela ligação física.

A extremidade recetora é um dispositivo que abre o envelope e reencaminha o pacote original para o seu destino. Entre as duas extremidades, um observador vê o cabeçalho exterior e nada sobre o interior, a menos que o protocolo o cifre, o que a maioria dos protocolos de consumo faz e a técnica geral não exige.

Por isso a interface virtual é simultaneamente real e enganadora. Existe como objeto do núcleo com um endereço e uma unidade máxima de transmissão, e o sistema operativo encaminha tráfego para ela como para qualquer outra interface. Não é um cabo, e a sua existência prova apenas que um componente está instalado. Se o teu navegador a usa é decidido pelas rotas, não pelo facto de a interface estar ativa.

Observa um pedido em viagem

Escolhe um destino e pergunta ao núcleo que interface vai usar. Este único comando resolve a maioria das discussões sobre se o túnel faz alguma coisa:

ip route get 203.0.113.7
ip -brief addr show
ip -4 addr show dev wg0

Se a saída da rota nomear a interface do túnel, o pacote será embrulhado. Se nomear a interface física, não será, e nenhum reinício do cliente muda isso. O segundo comando mostra as duas interfaces lado a lado, e é assim que detetas um túnel que subiu sem endereço ou com um endereço da família errada.

Depois olha para o primeiro salto a partir de dentro do envelope e compara-o com o primeiro salto de fora:

traceroute -n -m 3 203.0.113.7
sudo tcpdump -ni wg0 -c 5

Dentro do túnel o primeiro salto é o endereço interior do par, não o teu router. A captura na interface do túnel mostra os pacotes interiores, ou seja, o tráfego que a aplicação julga estar a enviar. Capturar ao mesmo tempo na interface física mostra os pacotes exteriores, e as duas coisas juntas são a demonstração mais clara do que um túnel faz realmente.

Três endereços, e o site vê apenas um

As pessoas confundem-nos constantemente, e a confusão produz relatórios de fuga falsos. São campos diferentes em cabeçalhos diferentes com vidas diferentes.

O número ao lado do adaptador virtual é a segunda linha. Não é o endereço que um site registra, e citá-lo como o teu IP público é simplesmente errado. O endereço que um site vê é atribuído pela saída, e num túnel de rede privada pode não haver qualquer saída pública, porque o destino vive dentro da organização e não na internet.

Um túnel entre locais é o mesmo mecanismo com outras extremidades. Dois routers embrulham tráfego entre redes, e nenhum dispositivo individual tem um cliente instalado. O envelope é idêntico em princípio, a fronteira administrativa não.

Onde o envelope é aberto e o que sobrevive a ele

O túnel termina no seu par. Se a cifragem da própria aplicação for mais longe, sobrevive a essa fronteira, que é o caso normal do HTTPS: a sessão do navegador termina no site, por isso a saída reencaminha texto cifrado que não consegue ler.

Nada mais sobrevive por predefinição. Um pedido não cifrado é legível na saída exatamente como era legível na Wi-Fi do café, e o túnel não acrescenta uma proteção que a aplicação nunca teve. Do mesmo modo, as regras de firewall e a política de reencaminhamento da saída decidem o que acontece a seguir; um aperto de mão bem-sucedido é um facto sobre a ligação ao par, não sobre o resto da viagem.

A sobrecarga é a outra consequência visível. Cada pacote transporta um cabeçalho extra, e o transporte exterior pode acrescentar o seu, pelo que a carga útil por pacote diminui. Num caminho com uma unidade máxima de transmissão fixa, é exatamente por isso que um túnel pode deixar passar um ping e encravar um grande envio.

Verifica o caminho que a aplicação realmente seguiu

O último passo é confirmar a aplicação concreta, e não a máquina em geral. Resolve o destino, olha para a rota desse endereço e depois observa a ligação enquanto está aberta:

getent hosts example.com
ip route get "$(getent hosts example.com | awk '{print $1; exit}')"
ss -tnp state established '( dport = :443 )'

Se a rota nomear o túnel mas a lista de sockets mostrar uma ligação com um endereço de origem da interface física, a aplicação está ligada a algo específico, ou um segundo túnel disputa a rota predefinida. É uma questão de encaminhamento, e pode ser respondida com estas três saídas em vez do ecrã de estado do cliente.

A arquitetura de segurança RFC 4301 descreve a versão de camada IP deste embrulho para IPsec, e a mesma lógica de camadas aplica-se a WireGuard e OpenVPN. Assim que consegues apontar o pacote interior e o pacote exterior como objetos separados, a maior parte do comportamento do túnel deixa de ser misteriosa e torna-se uma tabela de encaminhamento que podes ler.