Um app pelo WireGuard: vincular não é rotear

A configuração parece um interruptor por aplicativo, então as pessoas vinculam o cliente à interface WireGuard e esperam que só esse cliente use o túnel. O que a vinculação realmente faz é escolher um endereço de origem. Depois o kernel procura uma rota para o destino, encontra a rota padrão comum e envia o pacote pelo link físico com o endereço do túnel anexado. Só uma rota escolhida para esse endereço de origem cumpre a intenção.

O mecanismo tem duas metades: uma tabela de roteamento que só o tráfego do túnel deveria usar, e uma regra que envia a origem correspondente para lá.

Vincular define um endereço de origem, nada mais

O Linux escolhe uma interface de saída procurando o destino em uma tabela de roteamento, depois que as regras de política tiveram a chance de redirecionar essa busca. As regras podem selecionar pelo endereço de origem, uma marca de firewall, a interface de entrada, um UID ou até uma porta; cada uma é outra forma de dizer este tráfego em vez de tudo. A configuração do cliente VPN escolhe a tabela que contém as rotas do túnel; a regra escolhe qual tráfego pode consultá-la. A vinculação sozinha não fornece nenhuma das duas.

Por isso a falha parece tão estranha. O aplicativo sem dúvida usa o endereço do túnel, o túnel sem dúvida está no ar, e o tráfego sem dúvida sai pela interface errada. Cada afirmação é verdadeira, e juntas descrevem um sistema em que nada ligou o endereço à rota.

Dê ao túnel sua própria tabela

O wg-quick instala as rotas onde o perfil mandar. Adicionar Table = 40 em [Interface] as move para a tabela 40 em vez da tabela principal. Suba a interface e confirme que chegaram: ip -4 route ls table 40 deve mostrar as rotas do túnel, e ip -4 route get 10.66.127.142 mostra como o kernel resolve uma delas agora. Com as rotas na própria tabela, a tabela principal continua funcionando para todo o resto.

Faça o mesmo para IPv6 em vez de combinar um prefixo amplo. ip -6 rule add from fd00::2/128 lookup 40 fixa um endereço; fc00::/8 pode colidir com outras interfaces do host e produzir uma regra que combina com mais do que o pretendido.

Adicione a regra de origem e observe os contadores

Depois conecte as metades: ip -4 rule add from 10.66.127.142/32 lookup 40, com o mesmo endereço anexado à interface WireGuard. Coloque as duas regras em PostUp para que uma reconexão as restaure. Verifique com uma requisição real e não com uma configuração: ip route get 1.1.1.1 from 10.66.127.142 deve nomear o dispositivo do túnel, e curl --interface wg0 ifconfig.me deve informar o endereço do túnel em vez do da casa.

Quando ainda falhar, leia ip -s rule. Uma regra que existe mas nunca combinou mostra contadores zerados, e isso distingue uma regra errada da ausência de regra. Esse único comando economiza muita adivinhação sobre se o aplicativo ignorou sua configuração de interface.

O caso inverso: mantenha o SSH fora do túnel

O problema oposto é igualmente comum: o wg-quick é dono da rota padrão e a sessão SSH para o servidor morre no meio. As regras dele ficam em um número de prioridade baixo, então uma exceção precisa ser avaliada antes delas. ip rule add dport 22 ipproto tcp table main priority 123 faz isso em um iproute2 recente; onde o seletor não está disponível, marque o fluxo no nftables e combine a marca.

Verifique também o caminho de volta. Uma sessão SSH que se estabelece e depois silencia costuma ter roteamento assimétrico, com uma direção saindo pelo túnel e a outra pela interface física. ip route get para o endereço do servidor diz por onde a resposta iria.

Anote o número da tabela, a regra de origem e a exceção no próprio perfil. As três pertencem a um único projeto e serão editadas juntas.