Unha app por WireGuard: vincular non é encamiñar

O axuste parece un interruptor por aplicación, así que a xente vincula o cliente á interface WireGuard e espera que só ese cliente use o túnel. O que fai realmente a vinculación é escoller un enderezo de orixe. Despois o núcleo busca unha ruta para o destino, atopa a ruta predeterminada habitual e envía o paquete pola ligazón física co enderezo do túnel engadido. Só unha ruta seleccionada para ese enderezo de orixe completa a intención.

O mecanismo ten dúas metades: unha táboa de encamiñamento que só debería usar o tráfico do túnel, e unha regra que envía alí a orixe correspondente.

Vincular fixa un enderezo de orixe e nada máis

Linux escolle unha interface de saída buscando o destino nunha táboa de encamiñamento, despois de que as regras de política tivesen ocasión de redirixir esa busca. As regras poden seleccionar polo enderezo de orixe, unha marca de cortalumes, a interface de entrada, un UID ou mesmo un porto; cada unha é outra forma de dicir este tráfico en lugar de todo. A configuración do cliente VPN escolle a táboa que contén as rutas do túnel; a regra escolle que tráfico pode consultala. A vinculación por si soa non achega ningunha das dúas.

Por iso o fallo parece tan estraño. A aplicación sen dúbida usa o enderezo do túnel, o túnel sen dúbida está levantado e o tráfico sen dúbida sae pola interface equivocada. Cada afirmación é certa, e xuntas describen un sistema onde nada conectaba o enderezo coa ruta.

Dálle ao túnel a súa propia táboa

wg-quick instala as rutas onde o perfil lle di. Engadir Table = 40 baixo [Interface] trasládaas á táboa 40 en lugar da táboa principal. Levanta a interface e confirma que chegaron: ip -4 route ls table 40 debería mostrar as rutas do túnel, e ip -4 route get 10.66.127.142 mostra como resolve o núcleo unha delas agora mesmo. Coas rutas na súa propia táboa, a táboa principal segue funcionando para todo o demais.

Fai o mesmo para IPv6 en lugar de facer coincidir un prefixo amplo. ip -6 rule add from fd00::2/128 lookup 40 fixa un enderezo; fc00::/8 pode chocar con outras interfaces do equipo e producir unha regra que coincide con máis do previsto.

Engade a regra de orixe e observa os contadores

Despois conecta as metades: ip -4 rule add from 10.66.127.142/32 lookup 40, con ese mesmo enderezo unido á interface WireGuard. Pon as dúas regras en PostUp para que unha reconexión as restaure. Verifica cunha petición real e non cun axuste: ip route get 1.1.1.1 from 10.66.127.142 debería nomear o dispositivo do túnel, e curl --interface wg0 ifconfig.me debería informar do enderezo do túnel en lugar do da casa.

Cando segue fallando, le ip -s rule. Unha regra que existe pero que nunca coincidiu mostra contadores a cero, e iso distingue unha regra errada da ausencia total de regra. Ese único comando aforra moitas conxecturas sobre se a aplicación ignorou o seu axuste de interface.

O caso inverso: mantén SSH fóra do túnel

O problema oposto é igual de común: wg-quick posúe a ruta predeterminada e a sesión SSH ao servidor morre a metade da sesión. As súas regras están nun número de prioridade baixo, así que unha excepción debe avaliarse antes ca elas. ip rule add dport 22 ipproto tcp table main priority 123 fai iso nun iproute2 recente; onde o selector non está dispoñible, marca o fluxo en nftables e fai coincidir a marca.

Comproba tamén o camiño de resposta. Unha sesión SSH que se establece e despois cala adoita ter encamiñamento asimétrico, cunha dirección saíndo polo túnel e a outra pola interface física. ip route get para o enderezo do servidor diche por onde iría a resposta.

Anota o número de táboa, a regra de orixe e a excepción no propio perfil. As tres pertencen a un mesmo deseño e editaranse xuntas.