ZeroTier verso una LAN: regole di rotta UFW, non un permesso di porta

Raggiungere una stampante sulla LAN dell’ufficio tramite un membro ZeroTier sembra una sola regola, ma in realtà sono tre decisioni in tre punti diversi. L’overlay deve sapere dov’è la LAN, l’host Linux deve essere disposto a inoltrare i pacchetti e la LAN deve sapere come rimandare indietro la risposta. Una regola in ingresso che apre una porta sul gateway non tocca nessuna di queste cose. È lo strumento sbagliato applicato all’host giusto.

Tre compiti, tre responsabili

La rotta gestita appartiene alla configurazione di rete di ZeroTier. Indica ai membri che un prefisso è raggiungibile tramite un determinato indirizzo di membro.

L’inoltro appartiene al kernel Linux e a chi possiede la politica del suo firewall. Decide se un pacchetto che arriva sull’overlay esce di nuovo dall’interfaccia fisica. Un host che non inoltra scarterà il pacchetto in silenzio dopo averlo accettato. Il mittente vede un timeout e nel registro del servizio non compare nulla.

Il percorso di ritorno appartiene alla LAN. I suoi host e il suo router devono sapere che il prefisso dell’overlay è raggiungibile tramite l’indirizzo LAN del vostro gateway, oppure qualcosa deve tradurre il traffico perché la domanda non si ponga mai.

Ognuna di queste può essere corretta mentre le altre falliscono, ed è per questo che un test che fa solo ping al gateway non dimostra nulla sul servizio che sta dietro.

Puntate la rotta gestita verso il membro

Aggiungete una rotta per il prefisso LAN previsto tramite l’indirizzo overlay del gateway, non tramite il suo indirizzo LAN. L’indirizzo overlay è quello che gli altri membri possono raggiungere; l’indirizzo LAN ha senso solo sul cavo.

I membri devono accettare le rotte gestite perché il progetto funzioni, e le loro reti locali non devono già usare il prefisso che state annunciando. Un portatile remoto che a casa si trova su 192.168.60.0/24 non può neppure instradare 192.168.60.0/24 attraverso l’overlay.

Mantenete il prefisso annunciato il più stretto possibile per il compito. Annunciare un aggregato più ampio per influenzare la preferenza può anche rivendicare spazio di indirizzi che non possedete, e il conflitto risultante appare sui dispositivi collegati a entrambe le reti. Può anche indurre un membro a preferire un percorso che non porta da nessuna parte. Mantenete la rotta onesta e lasciate che la politica faccia il resto.

Scrivete il prefisso e l’indirizzo del membro nella stessa nota delle regole del firewall, perché il guasto più comune è una rotta che punta al membro sbagliato.

Abilitate il transito nel kernel

Leggete il valore di inoltro in esecuzione prima di cambiare qualcosa, poi rendete permanente l’impostazione tramite il meccanismo che il vostro sistema già usa, non tramite un comando una tantum che sparisce al riavvio.

Se UFW possiede la politica, le sue regole di rotta esprimono l’inoltro per una coppia di sorgente, destinazione e interfaccia. Sono separate dalle regole in ingresso che aprono un servizio sul gateway stesso:

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

Il nome dell’interfaccia è il dispositivo overlay reale su quell’host, che potete leggere con ip link; non è una stringa fissa in tutte le installazioni. Se l’host inoltra per impostazione predefinita e UFW non è sul percorso, la regola di rotta sarà ignorata e ciò che conta sono le impostazioni del kernel.

Scegliete come tornano le risposte

Con la conservazione della sorgente, il servizio della LAN vede il vero indirizzo overlay e vi risponde. Ciò richiede una rotta sull’host della LAN o sul suo router che punti il prefisso overlay al vostro gateway, e questa è una modifica fuori dalla macchina Linux.

Quando quella rotta non può essere aggiunta, una traduzione di sorgente limitata fa sembrare che la richiesta provenga dal gateway sulla LAN. Le risposte tornano allora localmente e non serve alcuna modifica all’instradamento della LAN, al costo di perdere la sorgente originale nei registri del servizio.

Limitate la traduzione alla sorgente overlay e alla destinazione LAN specifica. Tradurre tutto ciò che esce dall’interfaccia LAN è la versione ampia che poi sorprende chiunque legga le regole, e nasconde anche traffico che avrebbe dovuto essere bloccato.

Nessuna delle due scelte concede accesso non richiesto dalla LAN verso membri overlay arbitrari. Se lo si desidera, è una regola separata con la sua revisione.

Provate da un membro reale

Collegatevi da un altro membro, non dal gateway, e richiedete un servizio consentito. Poi provate un servizio che deve restare chiuso, e ripetete entrambi i test dopo una riconnessione e dopo un riavvio del gateway.

Un membro che segnala ONLINE, o un ping riuscito all’indirizzo overlay del gateway, non convalida la rotta, la regola di inoltro né il percorso di ritorno:

zerotier-cli listnetworks
ip -4 route get 192.168.60.20
sudo ufw status numbered

Il secondo comando mostra quale interfaccia userebbe il pacchetto verso l’host della LAN, e il terzo se la regola di rotta esiste nella forma che intendevate. Se entrambi sembrano corretti e il servizio scade ancora, il percorso di ritorno è il sospetto rimasto.