Una aplicació a través de WireGuard: enllaçar no és encaminar

El paràmetre sembla un commutador per aplicació, així que la gent enllaça el client amb la interfície WireGuard i espera que només aquell client faci servir el túnel. El que fa realment l'enllaç és triar una adreça d'origen. Aleshores el nucli busca una ruta per a la destinació, troba la ruta per defecte ordinària i envia el paquet per l'enllaç físic amb l'adreça del túnel adjunta. Només una ruta seleccionada per a aquesta adreça d'origen completa la intenció.

El mecanisme té dues meitats: una taula d'encaminament que només hauria d'usar el trànsit del túnel, i una regla que hi envia l'origen corresponent.

Enllaçar fixa una adreça d'origen i res més

Linux tria una interfície de sortida buscant la destinació en una taula d'encaminament, després que les regles de política hagin tingut l'oportunitat de redirigir aquesta cerca. Les regles poden seleccionar per l'adreça d'origen, una marca de tallafoc, la interfície d'entrada, un UID o fins i tot un port; cadascuna és una altra manera de dir aquest trànsit en lloc de tot. La configuració del client VPN tria la taula que conté les rutes del túnel; la regla tria quin trànsit té permís per consultar-la. L'enllaç sol no aporta cap de les dues.

Per això la fallada sembla tan estranya. L'aplicació sens dubte fa servir l'adreça del túnel, el túnel sens dubte està aixecat, i el trànsit sens dubte surt per la interfície equivocada. Cada afirmació és certa, i juntes descriuen un sistema on res no connectava l'adreça amb la ruta.

Dóna al túnel la seva pròpia taula

wg-quick instal·la les rutes allà on el perfil li diu. Afegir Table = 40 sota [Interface] les trasllada a la taula 40 en lloc de la taula principal. Aixeca la interfície i confirma que hi han arribat: ip -4 route ls table 40 hauria de mostrar les rutes del túnel, i ip -4 route get 10.66.127.142 mostra com el nucli resol ara una d'elles. Amb les rutes a la seva pròpia taula, la taula principal continua funcionant per a tota la resta.

Fes el mateix per a IPv6 en lloc de fer coincidir un prefix ampli. ip -6 rule add from fd00::2/128 lookup 40 fixa una adreça; fc00::/8 pot xocar amb altres interfícies de l'amfitrió i produir una regla que coincideix amb més del previst.

Afegeix la regla d'origen i mira els comptadors

Després connecta les meitats: ip -4 rule add from 10.66.127.142/32 lookup 40, amb la mateixa adreça adjunta a la interfície WireGuard. Posa les dues regles a PostUp perquè una reconnexió les restauri. Verifica-ho amb una petició real i no amb un paràmetre: ip route get 1.1.1.1 from 10.66.127.142 hauria de nomenar el dispositiu del túnel, i curl --interface wg0 ifconfig.me hauria d'informar de l'adreça del túnel en lloc de la de casa.

Quan encara falla, llegeix ip -s rule. Una regla que existeix però que mai no ha coincidit mostra comptadors a zero, cosa que distingeix una regla equivocada d'una absència de regla. Aquesta ordre estalvia moltes conjectures sobre si l'aplicació ha ignorat el paràmetre d'interfície.

El cas invers: mantén l'SSH fora del túnel

El problema oposat és igual de comú: wg-quick posseeix la ruta per defecte i la sessió SSH cap al servidor mor a mig camí. Les seves regles seuen en un número de prioritat baix, així que una excepció s'ha d'avaluar abans que elles. ip rule add dport 22 ipproto tcp table main priority 123 ho fa en un iproute2 recent; on el selector no està disponible, marca el flux a nftables i fes coincidir la marca.

Comprova també el camí de resposta. Una sessió SSH que s'estableix i després calla sol tenir encaminament asimètric, amb una direcció sortint pel túnel i l'altra per la interfície física. ip route get per a l'adreça del servidor et diu cap on aniria la resposta.

Anota el número de taula, la regla d'origen i l'excepció al mateix perfil. Les tres pertanyen a un sol disseny i s'editaran juntes.