ZeroTier cara a unha LAN: regras de ruta de UFW, non un permiso de porto

Chegar a unha impresora na LAN da oficina a través dun membro de ZeroTier soa a unha soa regra, pero en realidade son tres decisións en tres lugares distintos. A superposición debe saber onde está a LAN, o equipo Linux debe estar disposto a reenviar paquetes e a LAN debe saber como enviar a resposta de volta. Unha regra de entrada que abre un porto na pasarela non toca ningunha desas cousas. É a ferramenta equivocada aplicada ao equipo correcto.

Tres tarefas, tres responsables

A ruta xestionada pertence á configuración da rede de ZeroTier. Indica aos membros que un prefixo é alcanzable a través dun enderezo de membro concreto.

O reenvío pertence ao núcleo de Linux e a quen posúe a política do seu cortalumes. Decide se un paquete que chega pola superposición volve saír pola interface física. Un equipo que non reenvía descartará o paquete en silencio despois de aceptalo. O emisor ve un tempo de espera esgotado e no rexistro do servizo non aparece nada.

A ruta de volta pertence á LAN. Os seus equipos e o seu encamiñador deben saber que o prefixo da superposición é alcanzable a través do enderezo LAN da súa pasarela, ou algo ten que traducir o tráfico para que a pregunta nin sequera se formule.

Cada unha delas pode ser correcta mentres as demais fallan, e por iso unha proba que só fai ping á pasarela non demostra nada sobre o servizo que hai detrás.

Apunte a ruta xestionada ao membro

Engada unha ruta para o prefixo de LAN previsto a través do enderezo de superposición da pasarela, non do seu enderezo LAN. O enderezo de superposición é o que outros membros poden alcanzar; o enderezo LAN só ten sentido no cable.

Os membros deben aceptar as rutas xestionadas para que o deseño funcione, e as súas propias redes locais non deben usar xa o prefixo que vostede anuncia. Un portátil remoto que na casa está en 192.168.60.0/24 tampouco pode encamiñar 192.168.60.0/24 a través da superposición.

Manteña o prefixo anunciado tan estreito como permita a tarefa. Anunciar un agregado maior para influír na preferencia tamén pode reclamar espazo de enderezos que vostede non posúe, e o conflito resultante aparece nos dispositivos que se conectan a ambas as redes. Tamén pode facer que un membro prefira unha ruta que non leva a ningures. Manteña a ruta honesta e deixe que a política faga o resto.

Escriba o prefixo e o enderezo do membro na mesma nota que as regras do cortalumes, porque o fallo máis habitual é unha ruta que apunta ao membro equivocado.

Active o tránsito no núcleo

Lea o valor de reenvío en execución antes de cambiar nada, e despois faga permanente o axuste mediante o mecanismo que o seu sistema xa utiliza, non mediante unha orde puntual que desaparece ao reiniciar.

Se UFW posúe a política, as súas regras de ruta expresan o reenvío para un par de orixe, destino e interface. Son distintas das regras de entrada que abren un servizo na propia pasarela:

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

O nome da interface é o dispositivo de superposición real nese equipo, que pode ler con ip link; non é unha cadea fixa en todas as instalacións. Se o equipo reenvía por defecto e UFW non está no camiño, a regra de ruta ignorarase e o que importa son os axustes do núcleo.

Escolla como volven as respostas

Coa preservación da orixe, o servizo da LAN ve o enderezo de superposición real e responde a el. Iso require unha ruta no equipo da LAN ou no seu encamiñador que apunte o prefixo de superposición á súa pasarela, e iso é un cambio fóra da caixa Linux.

Cando esa ruta non se pode engadir, unha tradución de orixe delimitada fai que a petición pareza vir da pasarela na LAN. Entón as respostas volven localmente e non fai falta cambiar o encamiñamento da LAN, a cambio de perder a orixe orixinal nos rexistros do servizo.

Limite a tradución á orixe da superposición e ao destino concreto da LAN. Traducir todo o que sae da interface LAN é a versión ampla que despois sorprende a calquera que lea as regras, e ademais oculta tráfico que debería ter sido bloqueado.

Ningunha das dúas opcións concede acceso non solicitado desde a LAN cara a membros arbitrarios da superposición. Se iso se desexa, é unha regra aparte coa súa propia revisión.

Probe desde un membro real

Conéctese desde outro membro, non desde a pasarela, e solicite un servizo permitido. Despois probe un servizo que deba permanecer pechado, e repita ambas as probas tras unha reconexión e tras un reinicio da pasarela.

Un membro que informa de ONLINE, ou un ping correcto ao enderezo de superposición da pasarela, non valida a ruta, a regra de reenvío nin a ruta de volta:

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

A segunda orde mostra que interface usaría o paquete para o equipo da LAN, e a terceira mostra se a regra de ruta existe na forma que vostede pretendía. Se ambas parecen correctas e o servizo segue esgotando o tempo, a ruta de volta é o sospeitoso restante.