Túnel completo versus rota de endpoint: manter o servidor VPN alcançável

Adicione uma rota padrão pelo túnel e os pacotes do próprio túnel irão segui-la. A tabela contém então uma regra que se derrota a si mesma. A ligação cifrada ao servidor tenta viajar dentro da ligação que está a tentar estabelecer.

Dois mecanismos impedem esse ciclo. Um é visível na tabela de rotas, o outro vive dentro da aplicação.

O tráfego interno e o externo são decisões diferentes

Um pacote de aplicação entra na interface virtual e é encapsulado. O resultado é um novo pacote endereçado ao endereço público do servidor. Esse pacote precisa de uma rota na rede física, porque nada dele pode entrar no túnel.

Ambos são decisões de encaminhamento, e só a primeira pertence ao túnel. Quando o cliente instala uma rota padrão que também cobre o servidor, o pacote externo também é capturado.

Os sintomas são imediatos e totais. O handshake conclui-se e depois nada flui, ou a ligação cai no instante em que a rota é instalada. Em ambos os casos o keepalive já não pode sair.

Opção um: uma rota de host para o endpoint

A abordagem direta acrescenta uma rota para o endereço do servidor através do gateway original. Basta uma linha. É visível para quem lê a tabela. Também é fácil de explicar num registo de alterações.

A sua fraqueza aparece quando o caminho subjacente muda. A rota guardada nomeia um gateway e uma interface da rede antiga. Após uma mudança de Wi-Fi esse gateway pode não existir, e a rota fica para trás, parece correta e não faz nada.

# before the tunnel: which path reaches the endpoint?
ip route get 198.51.100.7

# pin it through the current gateway
ip route add 198.51.100.7/32 via 192.168.1.1 dev wlan0

# after the tunnel is up, confirm the pin survived
ip route get 198.51.100.7

Um nome de host torna isto mais difícil. Se o endpoint for um nome que resolve em vários endereços, a exceção tem de cobrir o endereço realmente em uso. Uma consulta posterior pode devolver algo que a rota nunca cobriu.

Opção dois: proteger o socket

A outra abordagem nunca toca na tabela de rotas. O cliente marca ou protege o socket que transporta o túnel, pelo que o sistema operativo envia o tráfego desse socket para fora do túnel por política. O Android expõe o mecanismo diretamente às aplicações VPN. Os clientes de ambiente de trabalho implementam equivalentes com marcas de firewall ou chamadas de ligação ao dispositivo.

A vantagem é que a exceção segue a ligação em vez de um gateway guardado. Uma mudança de rede reescreve o caminho subjacente, e o socket protegido move-se com ele porque nunca foi fixado a um endereço. A tabela de rotas mantém-se limpa.

O custo é a visibilidade. Nada na tabela de rotas mostra a exceção, pelo que um revisor que procura uma rota de host não encontra nada e pode concluir que o desenho é inseguro. A proteção vive no código do cliente e nas regras de política que esse código instala.

Escolher entre as duas

Escolha o mecanismo ao nível do socket quando o cliente o suporta, porque sobrevive às mudanças de rede que quebram uma rota fixada. Escolha a rota de host quando a exceção tem de ser visível para outras ferramentas, ou quando o cliente não oferece nada melhor.

Nenhum dos mecanismos elimina a necessidade de o endereço do servidor ser alcançável. Um gateway privado tem um endereço público de escuta, e é esse endereço que deve ficar fora do túnel. As redes internas por detrás dele só se tornam alcançáveis depois de o túnel existir.

Escolha o que escolher, mantenha-o junto do componente que possui o túnel. Uma rota de host perdida acrescentada à mão funciona até à rede seguinte, e então torna-se a queda misteriosa de amanhã.