As rotas DHCP podem desviar o seu tráfego para fora do túnel VPN?

A encriptação começa numa fronteira, e essa fronteira é uma decisão de encaminhamento que o ponto final toma antes de qualquer pacote ser encapsulado. Uma rede que nunca vê as suas chaves ainda pode entregar à sua máquina uma rota de que gosta mais do que a do próprio túnel. Aqui confundem-se duas falhas: ler um pacote que já está dentro do túnel e encaminhar um pacote que nunca lá foi colocado.

A distinção importa porque a segunda falha é mais barata de montar e muito mais fácil de deixar passar. Aparece como um pedido que saiu pela interface errada enquanto o cliente continuava a relatar uma ligação saudável.

Duas formas como uma rede pode afetá-lo

Um pacote que chega ao túnel tem o conteúdo escondido de cada salto que atravessa, e essa proteção mantém-se mesmo quando o caminho o surpreende. Um pacote que nunca chega ao túnel é um pedido comum do seu endereço, enviado para onde a tabela de rotas apontava. A primeira falha exige uma cifra quebrada ou um par comprometido, enquanto a segunda só precisa de uma mensagem de configuração em que a sua máquina decidiu confiar. É essa assimetria que faz com que a metade do encaminhamento mereça uma revisão própria.

O equipamento no caminho não precisa das suas chaves para influenciar o segundo caso. Precisa apenas que o seu ponto final aceite uma rota, um resolver ou uma regra de política que produza uma.

expected:  app -> tunnel device -> encapsulation -> internet
observed:  app -> wlan0        -> plaintext     -> internet

De onde pode vir uma rota antes de o túnel existir

O DHCP distribui mais do que uma concessão de endereço. A opção de rotas estáticas sem classe pode transportar prefixos de destino e próximos saltos, e a RFC 3442 discute as consequências de segurança de um endereço de router errado: tráfego mal encaminhado, uma negação de serviço ou um observador estacionado no caminho. Um cliente que aceite essas rotas antes de o túnel estar ativo pode acabar com um caminho preferido que não tem nada a ver com o seu fornecedor.

Nada disso torna a injeção de rotas universal. O cliente tem de aceitar a opção, o prefixo tem de cobrir o tráfego que lhe interessa, o próximo salto escolhido tem de ser alcançável e a política de aplicação tem de permitir que o pacote saia por ali. Retire qualquer uma dessas condições e a mesma resposta fica inofensiva. É também por isso que duas máquinas na mesma rede podem comportar-se de forma diferente, pois não estão a correr o mesmo cliente, a mesma política ou sequer a mesma família de endereços.

O IPv6 merece uma passagem própria, porque os anúncios de router transportam uma rota predefinida através de código diferente do da opção DHCPv4. Um teste que só inspeciona a tabela v4 não o cobre.

Verifique o caminho que o kernel escolhe de facto

As consultas de rota podem ser respondidas, por isso pergunte-lhes em vez de inferir a partir de uma luz de estado. Os comandos abaixo mostram a rota e a origem escolhidas para um destino, mais as regras que podem sobrepor-se à tabela principal. Execute-os enquanto está ligado e outra vez depois de se voltar a ligar, porque a renovação da concessão pode mudar a resposta.

ip route get 203.0.113.10
ip route show table all | grep -E '^(default|203\.0\.113)'
ip rule show
resolvectl query example.com

Leia a saída a pensar em duas coisas: a interface indicada na rota e o endereço de origem escolhido. Uma rota de túnel indica o dispositivo do túnel, uma rota fugida indica o físico, e a diferença é visível sem desencriptar nada. Se a resposta mudar entre execuções, guarde as duas saídas e compare as regras que as produziram.

Não pare na rota predefinida. Uma exceção de aplicação, um prefixo de túnel dividido ou uma segunda regra de política podem levar um destino específico à volta do túnel enquanto a predefinida continua a apontar para dentro.

Decida onde deve viver a aplicação das regras

Três condições decidem se a aplicação do lado do cliente é suficiente ou se precisa de algo fora dele. Se o cliente instala e defende rotas para cada família de endereços que usa, um túnel que detém a rota predefinida costuma ser suficiente. Se a máquina tem de chegar a recursos locais enquanto tudo o resto fica dentro do túnel, essas exceções têm de ser enumeradas e assumidas em vez de ficarem ao critério do que a rede de acesso anunciou. E se a plataforma conseguir ligar o tráfego a uma interface por aplicação, essa ligação é uma garantia mais forte do que uma rota que qualquer coisa pode sobrepor.

Seja qual for a escolha, escreva a decisão onde vive a configuração. Uma regra que existe porque alguém a escreveu durante um incidente não sobrevive ao próximo reinício, por isso mantenha as exceções locais e de arranque estreitas e registe por que existe cada uma.

Volte a executar os comandos de consulta após cada atualização do cliente e cada mudança de rede, e compare com a última saída registada. A tabela de rotas é a fronteira da aplicação das regras, por isso trate-a como tal.