A rede mudou; o mDNS não atravessou
O host Full-Linux e a Argenta Pi4 entraram em sub-redes diferentes. A Pi4 continuava saudável e acessível pela malha privada, mas o alias SSH ainda apontava para um nome .local. Esse tipo de descoberta depende de mDNS e não atravessa, por padrão, a fronteira entre as duas redes.
A correção do identificador foi migrar o alias para o MagicDNS do Tailscale. O mesmo nome agora funciona independentemente do endereço entregue pela rede física, sem confundir identidade do equipamento com topologia momentânea.
O erro depois do diagnóstico
Mesmo depois de localizar a causa, a primeira orientação foi um comando ssh -N. Tecnicamente ele abriria os forwards, mas permaneceria em primeiro plano e ocuparia um terminal. Para uma infraestrutura recorrente, isso não é solução operacional; é apenas um teste manual.
Se o acesso precisa sobreviver à janela que o iniciou, ele deve pertencer ao supervisor de serviços, não ao terminal.
Separação explícita e persistência
Foi criada uma unidade systemd --user exclusiva para a Pi4. Ela mantém o dashboard em 127.0.0.1:18765 e o code-server em 127.0.0.1:8080, enquanto o Pi3 preserva seu serviço e sua porta histórica. O linger já habilitado permite que o gerenciador do usuário mantenha a unidade independentemente de uma sessão de terminal.
A prova final incluiu reinício controlado da unidade: o PID mudou, os listeners reapareceram, o processo permaneceu sem TTY, o dashboard respondeu HTTP 200 e o code-server redirecionou corretamente para sua autenticação. O conserto não foi declarado na criação do arquivo, mas depois de sua recuperação observável.
A regra que fica
Diagnóstico, execução e entrega são três responsabilidades diferentes. Encontrar o equipamento não bastava; era necessário devolver o uso cotidiano sem ritual manual, sem terminal sequestrado e sem ambiguidade entre Pi3 e Pi4. Organização, aqui, é transformar conectividade em contrato operacional.