Acesso remoto ao dashboard
O dashboard do EzyShield escuta apenas em loopback (127.0.0.1 ou ::1). Essa é uma regra dura: ele se recusa a subir em qualquer outro endereço. Cabe ao operador trazer a conexão de fora — de um laptop, celular ou bastion — por um canal que já fala TLS ou é confiável por outro motivo.
Este guia cobre os três padrões de transporte que recomendamos, na ordem "mais fácil primeiro".
Opção 1: SSH port-forward (recomendado)
A opção mais simples. Nada extra roda no servidor. Do seu laptop:
ssh -L 9090:127.0.0.1:9090 operador@servidor.exemplo.comDepois abra http://localhost:9090 no navegador. O tráfego passa pelo canal SSH; o dashboard no servidor vê uma conexão local.
Túnel em background
Se você quer o túnel aberto sem prender o terminal:
ssh -fN -L 9090:127.0.0.1:9090 operador@servidor.exemplo.com-fmanda o processo para background depois da autenticação.-Ndiz "não rode comando remoto" — o túnel já é o objetivo.
Para matar depois:
kill $(pgrep -f "ssh -fN -L 9090")Setup persistente via ~/.ssh/config
Coloque a definição do túnel no seu config do SSH para subir com uma palavra só:
Host ezyshield-dashboard
HostName servidor.exemplo.com
User operador
LocalForward 9090 127.0.0.1:9090
# Opcional: manter conexão viva por NATs.
ServerAliveInterval 30
ServerAliveCountMax 3
# Opcional: morre em silêncio se o server sumir.
ExitOnForwardFailure yesDepois:
ssh ezyshield-dashboard
# abra http://localhost:9090 no navegadorJunte -fN para mandar para background, junte -o RemoteCommand=none se sua conta usa comando forçado.
Observações
- Se a porta 9090 já estiver ocupada localmente, escolha qualquer porta livre e mude o primeiro número:
-L 9091:127.0.0.1:9090mapeiahttp://localhost:9091para a 9090 do lado do servidor. - O túnel te dá exatamente o que uma sessão local dá — sem multi- usuário, sem controle de acesso por time, um login por vez. Isso é ok para o escopo single-admin atual.
Opção 2: Cloudflare Tunnel (persistente, sem portas abertas)
Boa quando você quer uma URL estável que dá para favoritar e controlar o acesso via Cloudflare Access. O servidor nunca abre uma porta escutando além da conexão de saída do cloudflared para o Cloudflare.
Passos em alto nível:
Crie uma conta Cloudflare e uma zone que você controle.
Instale o
cloudflaredno servidor: https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/downloads/Autentique:
cloudflared tunnel login— abre um fluxo de browser amarrado à sua conta Cloudflare.Crie um tunnel:
cloudflared tunnel create ezyshield.Aponte para um hostname:
cloudflared tunnel route dns ezyshield dashboard.seu-dominio.exemplo.Configure o ingress em
~/.cloudflared/config.yml:yamltunnel: ezyshield credentials-file: /root/.cloudflared/<tunnel-uuid>.json ingress: - hostname: dashboard.seu-dominio.exemplo service: http://127.0.0.1:9090 - service: http_status:404Rode:
cloudflared tunnel run ezyshield, ou instale como serviço.Proteja o acesso via Cloudflare Access. No painel Zero Trust do Cloudflare, adicione uma Access application para
dashboard.seu-dominio.exemploe exija um identity provider (Google, GitHub, Okta, PIN por e-mail, etc.). Sem esse passo qualquer um com a URL consegue chegar na página de login.
Referência: https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/
O dashboard no servidor continua ligado apenas em 127.0.0.1 — só o cloudflared fala com ele, e só o Cloudflare fala com o cloudflared.
Opção 3: Tailscale (mesh privada, config zero)
Boa quando você já tem uma mesh Tailscale ligando time e máquinas. Instale Tailscale no servidor e no laptop e logue na mesma tailnet. O tráfego é peer-to-peer via mesh, cifrado com WireGuard — sem IP público nem DNS — e você pode restringir o acesso com ACLs no painel do Tailscale.
Importante: o dashboard escuta só em 127.0.0.1:9090, e sua guarda de loopback rejeita qualquer bind não-loopback, então você não pode simplesmente abrir o endereço tailnet do servidor na porta 9090. Uma instalação Tailscale padrão (modo kernel) não encaminha o tráfego destinado à tailnet para um listener só de loopback — uma requisição a http://<nome-tailnet-do-servidor>:9090 chega em 100.x.y.z:9090, não encontra listener e é recusada. (Falha fechando — sem brecha de segurança — mas não funciona como URL direta.) Ligue a tailnet ao dashboard de loopback de uma destas duas formas:
tailscale serve— o proxy reverso embutido do Tailscale. No servidor:bash# Encaminha o endereço tailnet do node (HTTPS) para o dashboard local em :9090. sudo tailscale serve --bg 9090 tailscale serve status # verifica; rode `tailscale serve --help` para desfazerDepois abra
https://<servidor>.<tailnet>.ts.net/de qualquer dispositivo na tailnet. O Tailscale termina a conexão e a encaminha para127.0.0.1:9090, então o dashboard ainda vê um cliente de loopback e sua guarda de bind é satisfeita. (O serve HTTPS exige certificados HTTPS habilitados na sua tailnet; as flags exatas variam conforme a versão do Tailscale.)Túnel SSH sobre Tailscale — idêntico à Opção 1, mas apontando o SSH para o nome tailnet, de modo que nenhuma porta fica exposta:
bashssh -L 9090:127.0.0.1:9090 <usuário>@<nome-tailnet-do-servidor> # depois abra http://localhost:9090
Referência: https://tailscale.com/kb/1017/install/ · https://tailscale.com/docs/features/tailscale-serve
Nunca exponha 0.0.0.0
Para constar: não faça isso. Mesmo que você coloque addr: 0.0.0.0:9090 no config, o dashboard se recusa a subir com um erro explícito citando AGENTS.md §2. É proposital. Se você está tentado a burlar, uma das três opções acima quase sempre resolve a necessidade real — um caminho remoto persistente sem listener exposto.
E se o daemon estiver offline?
Nenhum desses transportes toca a conexão com o daemon: em todos os casos o dashboard alcança o daemon por um socket unix local. Se o daemon estiver parado, todas as opções acima ainda entregam o banner "Daemon offline" no lugar dos dados ao vivo. Suba o daemon (systemctl status ezyshield) — o túnel não precisa mudar.