ZeroTier cap a una LAN: regles de ruta d’UFW, no una permissió de port
Permetre un port a la passarel·la no és el mateix que reenviar cap a un equip que hi ha darrere. Definiu la ruta gestionada, activeu el trànsit i trieu un camí de tornada.
Arribar a una impressora de la LAN de l’oficina a través d’un membre de ZeroTier sembla una sola regla, i en realitat són tres decisions en tres llocs diferents. La superposició ha de saber on és la LAN, l’equip Linux ha d’estar disposat a reenviar paquets i la LAN ha de saber com enviar la resposta de tornada. Una regla d’entrada que obre un port a la passarel·la no toca cap d’aquestes coses. És l’eina equivocada aplicada a l’equip correcte.
Tres feines, tres responsables
La ruta gestionada pertany a la configuració de la xarxa ZeroTier. Indica als membres que un prefix és abastable a través d’una adreça de membre concreta.
El reenviament pertany al nucli de Linux i a qui posseeix la seva política de tallafocs. Decideix si un paquet que arriba per la superposició torna a sortir per la interfície física. Un equip que no reenvia descartarà el paquet en silenci després d’acceptar-lo. L’emissor veu un temps d’espera exhaurit i al registre del servei no hi apareix res.
El camí de tornada pertany a la LAN. Els seus equips i el seu encaminador han de saber que el prefix de la superposició és abastable a través de l’adreça LAN de la vostra passarel·la, o alguna cosa ha de traduir el trànsit perquè la pregunta no arribi a plantejar-se.
Cadascun d’aquests pot ser correcte mentre els altres fallen, i per això una prova que només fa ping a la passarel·la no demostra res sobre el servei que hi ha darrere.
Apunteu la ruta gestionada al membre
Afegiu una ruta per al prefix de LAN previst a través de l’adreça de superposició de la passarel·la, no de la seva adreça LAN. L’adreça de superposició és la que altres membres poden assolir; l’adreça LAN només té sentit al cable.
Els membres han d’acceptar les rutes gestionades perquè el disseny funcioni, i les seves pròpies xarxes locals no han d’utilitzar ja el prefix que anuncieu. Un portàtil remot que a casa és a 192.168.60.0/24 tampoc no pot encaminar 192.168.60.0/24 a través de la superposició.
Manteniu el prefix anunciat tan estret com la tasca permeti. Anunciar un agregat més gran per influir en la preferència també pot reclamar espai d’adreces que no posseïu, i el conflicte resultant apareix als dispositius que es connecten a les dues xarxes. També pot fer que un membre prefereixi un camí que no porta enlloc. Manteniu la ruta honesta i deixeu que la política faci la resta.
Escriviu el prefix i l’adreça del membre a la mateixa nota que les regles del tallafocs, perquè la fallada més habitual és una ruta que apunta al membre equivocat.
Activeu el trànsit al nucli
Llegiu el valor de reenviament en execució abans de canviar res, i després feu permanent l’ajust amb el mecanisme que el vostre sistema ja utilitza, no amb una ordre puntual que desapareix en reiniciar.
Si UFW posseeix la política, les seves regles de ruta expressen el reenviament per a una parella d’origen, destinació i interfície. Són separades de les regles d’entrada que obren un servei a la mateixa passarel·la:
sysctl net.ipv4.ip_forward
sudo ufw route allow in on zt3f2a1c9d out on eth0 proto tcp to 192.168.60.20 port 443
sudo ufw status verbose
El nom de la interfície és el dispositiu de superposició real d’aquest equip, que podeu llegir amb ip link; no és una cadena fixa a totes les instal·lacions. Si l’equip reenvia per defecte i UFW no és al camí, la regla de ruta s’ignorarà i el que importa són els ajustos del nucli.
Trieu com tornen les respostes
Amb la preservació de l’origen, el servei de la LAN veu l’adreça de superposició real i hi respon. Això requereix una ruta a l’equip de la LAN o al seu encaminador que apunti el prefix de superposició a la vostra passarel·la, i això és un canvi fora de la caixa Linux.
Quan aquesta ruta no es pot afegir, una traducció d’origen delimitada fa que la petició sembli venir de la passarel·la de la LAN. Llavors les respostes tornen localment i no cal cap canvi d’encaminament a la LAN, a canvi de perdre l’origen original als registres del servei.
Limiteu la traducció a l’origen de la superposició i a la destinació concreta de la LAN. Traduir tot el que surt de la interfície LAN és la versió àmplia que després sorprèn qui llegeix les regles, i també amaga trànsit que hauria d’haver estat bloquejat.
Cap de les dues opcions no concedeix accés no sol·licitat des de la LAN cap a membres arbitraris de la superposició. Si això es vol, és una regla separada amb la seva pròpia revisió.
Proveu-ho des d’un membre real
Connecteu-vos des d’un altre membre, no des de la passarel·la, i sol·liciteu un servei permès. Després proveu un servei que ha de romandre tancat, i repetiu les dues proves després d’una reconnexió i després d’un reinici de la passarel·la.
Un membre que informa d’ONLINE, o un ping correcte a l’adreça de superposició de la passarel·la, no valida la ruta, la regla de reenviament ni el camí de tornada:
zerotier-cli listnetworks
ip -4 route get 192.168.60.20
sudo ufw status numbered
La segona ordre mostra quina interfície faria servir el paquet per a l’equip de la LAN, i la tercera mostra si la regla de ruta existeix en la forma que preteníeu. Si totes dues semblen correctes i el servei encara s’esgota, el camí de tornada és el sospitós restant.