WireGuard AllowedIPs: la ruta que NetworkManager mai no va afegir

El comptador d’apretades de mans s’actualitza, la interfície conserva la seva adreça i un ping a l’altre costat no arriba enlloc. Aquesta combinació confon la gent, perquè una apretada de mans que funciona sembla la prova que el túnel està llest. No ho és: un túnel pot estar completament negociat i tot i així no tenir cap ruta que hi encamini el trànsit, i són dues feines separades fetes per dues peces d’estat separades. La solució depèn del tot de quina de les dues falta, així que el primer pas és esbrinar-ho.

wg-quick fa les dues coses sense que ningú li ho demani. El suport de WireGuard integrat a NetworkManager també instal·la rutes de peers per defecte, cosa que redueix els sospitosos a una opció desactivada, una taula d’encaminament diferent o una configuració importada per alguna altra via.

Confirmem el túnel abans de perseguir la ruta

wg show mostra la interfície, el peer, el punt final i l’edat de l’última apretada de mans, i ip addr show confirma que l’adreça hi és. Una apretada de mans recent vol dir que les claus, el punt final i el camí UDP funcionen. Tot el que està trencat se situa més avall: encaminament, filtratge o resolució de noms.

Després pregunteu al nucli què faria amb una destinació real en lloc d’una d’hipotètica: ip route get 10.42.7.9. La resposta indica la interfície de sortida i l’adreça d’origen que portaria el paquet. Quan indica l’adaptador físic, el paquet no entra mai al túnel, per saludable que sembli l’apretada de mans.

AllowedIPs és un filtre i una llista de rutes

Els prefixos d’AllowedIPs fan dues feines. Seleccionen quin peer transporta una destinació de sortida i validen l’adreça d’origen dels paquets entrants, que és la frontera d’encaminament per clau criptogràfica. A wg-quick també governen la instal·lació automàtica de rutes, i aquest comportament extra és la raó per la qual la mateixa configuració funciona des d’un terminal i no des d’un client d’escriptori.

En el cas darrere d’aquest article, el perfil es va importar mitjançant un connector de tercers i no pas amb el suport integrat, i la interfície va pujar sense la ruta de prefix. Llistar la taula ho mostra de seguida: ip route show només conté la ruta connectada de l’adreça de la interfície i res per al rang remot.

Pregunteu si les rutes de peers estan activades

Llegiu el paràmetre abans de modificar res: nmcli -f wireguard.peer-routes,ipv4.route-table connection show work-wg. Quan peer-routes mostra no, la reparació suportada és nmcli connection modify work-wg wireguard.peer-routes yes, seguida d’una reconnexió. Afegir una ruta estàtica en lloc d’això funciona fins a la propera activació i després desapareix en silenci. Aquesta desaparició és la pista: una ruta que torna com un misteri cada matí no la instal·la el perfil.

Si l’opció ja està activada, comproveu si el prefix viu en una altra taula amb ip route show table all | grep 10. Una ruta en una taula que no és la principal no falta, simplement és invisible per a una consulta que només mira la taula principal. Repareu l’encaminament de polítiques en lloc d’apilar una entrada duplicada a sobre.

Afegiu el prefix a la connexió, no al sistema en marxa

A l’editor de connexions, la pàgina WireGuard conté el peer i les seves AllowedIPs, i la pàgina IPv4 conté rutes addicionals. Una ruta afegida allà sobreviu a les reconnexions perquè pertany al perfil. A la línia d’ordres l’equivalent és afegir una ruta a la connexió amb la forma de porta d’enllaç buida i després baixar i pujar la connexió perquè el canvi s’apliqui.

Trieu el prefix més estret que cobreixi els equips que necessiteu. Copiar l’exemple /8 del proveïdor pot engolir rangs locals que hi cauen a dins per casualitat, i les fallades resultants semblen un túnel trencat més que no pas una ruta massa ampla.

El túnel partit el decideix la llista de prefixos

No hi ha cap interruptor de túnel partit; la llista de prefixos és la decisió. Un peer amb un rang per a la LAN de l’oficina i un altre per a una xarxa de laboratori envia exactament aquestes destinacions pel túnel i deixa la resta en pau. Un sol equip necessita un /32, i els rangs que se solapen en dos llocs necessiten prefixos d’equip fins que algú renumera una subxarxa.

Triar no enviar res pel túnel porta la mateixa decisió fins al límit: una llista mínima manté l’enllaç aixecat mentre el trànsit corrent segueix el seu camí habitual. Escriviu la intenció, perquè si no el següent lector prendrà la llista curta per un descuit i l’ampliarà amb bona voluntat.

Un sol propietari per a la taula de rutes

wg-quick i NetworkManager tots dos creuen que posseeixen les rutes de la interfície. Importeu una configuració escrita per a wg-quick i després engegueu també el servei wg-quick, i obtindreu entrades duplicades o en conflicte el comportament de les quals depèn de quin va córrer l’últim. Trieu un sol propietari i traieu l’altre: si NetworkManager gestiona la connexió, desactiveu la unitat wg-quick per a aquesta interfície i no afegiu mai un segon perfil per al mateix dispositiu.

Quan la partició ha de seguir un adaptador físic en lloc d’una destinació, heu passat a l’encaminament de polítiques, i l’encaminament de polítiques també necessita un sol autor. Verifiqueu-ho repetint ip route get i després arribant a un equip dins del prefix remot amb una cosa que imprimeixi l’adreça d’origen que ha triat. Comproveu IPv6 i DNS per separat si el perfil en porta cap dels dos.