Prefix d’amfitrió a WireGuard: per què funciona una adreça i la resta no

El túnel està aixecat, el handshake passa cada dos minuts i exactament una adreça de l’altre costat respon. Els pings a l’adreça del túnel del parell funcionen; res del que hi ha darrere no ho fa. Algú llegeix la configuració de la interfície, veu un prefix d’amfitrió i conclou que la màscara està malament. Ampliar-la a un /24 arregla el ping durant un temps i després trenca una altra cosa. El prefix mai va ser la culpa, i la ruta que faltava no és la que controla la màscara.

Què crea realment el prefix de la interfície

A Linux, assignar una adreça a una interfície crea una ruta connectada per a aquest prefix. Si assignes un prefix d’amfitrió, la ruta connectada cobreix una adreça. Si assignes un /24, en cobreix 256, i cadascuna passa a considerar-se abastable per aquest enllaç.

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

Un prefix d’amfitrió és una elecció completament normal per a un túnel punt a punt, perquè hi ha exactament un parell a l’altre costat. La tercera ordre és la que respon la pregunta de l’usuari: di quina interfície faria servir el nucli per a aquesta destinació, i no mostrarà res d’útil si no hi coincideix cap ruta.

Aquesta és tota l’explicació del símptoma. Una adreça respon perquè hi ha una ruta connectada per a ella, o perquè la llista permesa del parell resulta que la inclou. Tota la resta no té ruta i es descarta abans que WireGuard hi intervingui. El túnel està sa en tot moment, i per això el comptador de handshakes continua semblant tranquil·litzador.

AllowedIPs són dues regles amb un sol nom

La llista permesa per parell de WireGuard fa dues feines alhora, i la sintaxi de configuració fa que semblin una. D’entrada, autoritza quines adreces d’origen pot presentar un parell. De sortida, selecciona a quin parell s’envia un paquet, trobant la coincidència més específica.

Cap de les dues feines és encaminament. El nucli encara ha de decidir que un paquet pertany a la interfície del túnel abans que WireGuard el miri, i aquesta decisió ve de la taula de rutes. Una entrada de parell amb una llista permesa àmplia no instal·la una ruta per si sola.

Per això una configuració pot semblar completa i comportar-se de manera asimètrica. El client envia cap a l’altre extrem perquè existeix una ruta, i les respostes no arriben mai perquè la llista permesa de l’altre extrem no autoritza l’origen del client, o perquè l’altre extrem no té ruta de tornada. Totes dues direccions són decisions separades amb maneres de fallar separades. Anotar quina estàs provant és la meitat del diagnòstic.

D’on ve la ruta

Si fas servir wg-quick, les rutes es generen per tu a partir de la llista permesa de cada parell, tret que hagis posat Table = off i t’hagis fet càrrec tu mateix. Aquest és el comportament que documenta l’eina, i és la raó per la qual una configuració sense directrius de ruta explícites continua funcionant.

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

Compara la llista permesa amb les rutes que hi ha realment. Un parell que permet una subxarxa sencera però només va produir una ruta d’amfitrió significa que l’ajudant no es va executar mai, o que gestiones la interfície directament amb wg i ip, i en aquest cas res no genera rutes per tu.

Quan ho gestiones a mà, la ruta és una línia i la seva forma és explícita: la destinació per la interfície, sense porta d’enllaç perquè l’enllaç és punt a punt. Afegir-la no és una solució de compromís per a un prefix dolent; és la meitat que faltava d’un disseny que va decidir encarregar-se de l’encaminament.

Ampliar el prefix no afegeix l’entrada del parell

La solució temptadora és canviar l’adreça a un /24 perquè la ruta connectada cobreixi la LAN del servidor. Sembla que funciona, i la raó que sembli que funciona és que la ruta connectada ara coincideix, no que WireGuard hagi après res de nou.

El que també vas fer és reclamar tot el rang com a directament abastable per aquest enllaç, incloent-hi adreces que pertanyen a altres parells o a una LAN que en realitat és darrere del servidor. El trànsit a aquestes adreces ara entra al túnel, i si en surt per l’altre costat depèn de l’encaminament i de les llistes permeses del mateix servidor.

El costat criptogràfic no es veu afectat de cap manera. WireGuard encara necessita una entrada a la llista permesa que cobreixi la destinació per triar un parell, i l’altre extrem encara necessita una entrada que cobreixi el teu origen per acceptar-la. Un prefix d’interfície més ampli no pot proporcionar cap de les dues.

Confirma totes dues direccions abans de canviar res

Treballa els dos extrems per separat i anota què diu cadascun. Al client, la ruta i l’entrada del parell; al servidor, la imatge de mirall més la seva pròpia ruta de tornada:

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

La captura és el que resol les discussions sobre la direcció. Si els paquets de sortida apareixen a la interfície del túnel i el servidor no registra res, l’extrem remot els rebutja, normalment perquè el teu origen és fora de la seva llista permesa. Si no apareix res de tot, falta la ruta o apunta a un altre lloc.

Després arregla l’extrem més estret. Una entrada a la llista permesa del costat del servidor per a l’adreça del teu client i una entrada al costat del client per a la subxarxa de destinació és la forma normal, i deixa intacte el prefix de la interfície. Només amplia el prefix si el pla d’adreces vol de veritat una subxarxa compartida en aquest enllaç, i fes-ho com un canvi de pla en lloc d’un pas de depuració.