Eu já havia falado sobre como optei por sair do Cloudflare Tunnel para o Pangolin auto-hospedado. Tudo estava bem; Pangolim funcionou. Então, teoricamente, caso encerrado, certo? Enquanto trabalhava no experimento Tailscale, me deparei com o funil Tailscale. Foi apenas um comando no terminal e o URL ativo final apareceu do outro lado. A proposta – sem proxy reverso, sem registros DNS, sem certificados, sem encaminhamento de porta – me fez repensar a configuração do Pangolin. Foi então que decidi mover alguns serviços para o funil. No começo parecia que eu tinha pensado demais nas configurações, mas essa sensação não durou muito.
Parecia muito fácil para ser verdade
Uma equipe. Sem proxy reverso. Immich, ao vivo.
O DNA e as partes de acesso externo do meu laboratório doméstico eram uma montanha-russa. O DNA é assunto para outro dia; vamos falar sobre acesso externo. Eu, como todo mundo, comecei com Cloudflared. Fácil de implementar e fácil de escolher para o aspirante a trabalhador de laboratório doméstico. E gradualmente mudou para todo o Cloudflare – túnel, rede e DNS. Então, finalmente mudei para Pangolin para acesso público externo e Tailscale para acesso privado externo porque não gostava de ter todos os meus ovos na mesma cesta.
Estou usando Pangolin há um mês e tudo está indo bem como esperado. Era uma configuração sólida, mas não era invisível. Eu ainda mantenho coisas como Traefik, registros DNS, painel, manutenção ocasional e ainda por cima uma conta VPS pequena, mas periódica. Mas ainda estava feliz com a configuração. Então, na semana passada, enquanto escrevia um artigo sobre como o Tailscale me ajudou a evitar pagar um ISP por um IP estático, me deparei com um funil. Essa descoberta me fez questionar toda a minha configuração.
Dei uma olhada rápida nos recursos e o apelo foi quase absurdo – sem proxy reverso, sem DNS, sem certificados SSL e sem encaminhamento de porta. Eram apenas dois comandos – tailscale serve e tailscale funnel – e me dariam uma URL pública que funcionaria mesmo para pessoas fora da minha rede final. Isso me fez pensar, se era tão fácil, por que eu estava comandando o Pangolin? Foi então que decidi tentar: suspender temporariamente a configuração do Pangolin por uma semana ou migrar alguns serviços para o funil para testes no mundo real.
Comecei com os comandos tailscale serve e tailscale funnel, mas recebi a mensagem de erro “Serve and funnel CLI mudou”. Depois de revisar os novos documentos, mudei para a nova sintaxe. Como esta é a primeira vez que uso o funil nesta conta, fui solicitado a ativar o funil nesta rede de back-end. Era basicamente um link direto do navegador com um processo de aprovação de um clique. Feito isso, executo o comando com Immich localhost na porta 443.
sudo tailscale funnel --bg --https=443 http://localhost:2283Isso imediatamente me deu um URL público ativo; Eu imediatamente o abri no meu dispositivo fora da minha rede back-end. Immich carregou instantaneamente. Era apenas um comando em vez dos dois que aceitei – e já tinha a URL direta. Então comecei a pensar: passei muito tempo substituindo o túnel Cloudflare pelo Pangolin, e agora parecia que uma ferramenta completamente diferente eliminou a necessidade de fazer a maior parte desse trabalho. Isso me fez pensar se eu havia projetado demais meu laboratório doméstico.
Depois que Imich funcionou perfeitamente, pensei em transferir mais serviços para ele. Foi quando a lua de mel terminou.
Então eu bati na parede três vezes
Três portas. Um nome de host. Um carro.
Imich funcionou tão bem que não parecia mais um teste; Eu realmente queria mover mais serviços para ele. Eu queria migrar a maioria dos meus serviços do Pangolin para o Funnel como prova de conceito. Olhando a documentação, não li a linha corretamente, mas vi que ela mencionava as portas 443, 8443 e 10000. Então, usei as mesmas portas ao habilitar os funis. Immich já estava habilitado na porta 443 então usei os outros dois Uptime Kuma e ntfy.
sudo tailscale funnel --bg --https=8443 http://localhost:3001
sudo tailscale funnel --bg --https=10000 http://localhost:8091Ambos trabalharam. Ambos os comandos me forneceram URLs públicos ativos e também funcionaram bem. Então tentei outro serviço, mas na porta 9000. Criou um funil, mas a URL não funcionou. Ele continuou me dando o erro ERR_CONNECTION_TIMED_OUT. Desativei o funil e passei; ainda o mesmo erro. Foi incrível não ter recebido nenhum erro ao construir a CLI, mas ela nunca funcionou no navegador. Foi então que decidi verificar novamente os documentos. E a linha que ignorei anteriormente foi “O funil só pode escutar nas portas 443, 8443 e 10000.“Isso deixou tudo claro e pior ao mesmo tempo.
Quando criei um funil na porta 9000, a CLI acabou de criá-lo e nunca validou a porta. Mas quando tentei abrir o link, a infraestrutura de retransmissão pública real do Tailscale descarta silenciosamente qualquer coisa fora de 443, 8443 e 10.000. Nesse ponto, percebi que havia preenchido todos os três slots sem nem mesmo me esforçar muito.
Então recorri a outro dispositivo para hospedar outro serviço. Executei um comando semelhante no meu PC para jogos.
tailscale funnel --bg --https=443 http://localhost:11434Funcionou, mas me deu um novo nome de host. Isso fazia sentido: um nó diferente significava um nome de host diferente. Foi quando finalmente percebi que não era um ponto de entrada comum, mas que cada nó se tornava sua própria pequena ilha. Com o Pangolin, várias máquinas backend podem estar atrás de um único ponto de entrada público.
Eu poderia ter vivido com isso, mas a próxima pergunta foi mais preocupante. Percebi que cada domínio tem a mesma estrutura: ts.net estrutura de domínio Eu estava acostumado com mais estruturas de marca, por exemplo photos. e o nome do host ts.net ficava me lembrando que esses serviços pertencem ao namespace de outra pessoa.
Depois dessa experiência percebi uma coisa: o funil não estava quebrado. Não foi construído para o propósito que eu esperava. Ele foi criado para resolver um problema totalmente diferente.
Então o Pangolim fez sentido novamente
O funil falhou. Apenas esclareceu o trabalho.
Eu perguntei “Um funil pode substituir um Pangolim?” pergunta quando comecei o experimento. E no final — nem mesmo um fim de semana completo se passou — a pergunta mudou para “Seria?” Tratei o funil Pangolin e Tailscale como se resolvessem o mesmo problema. Mas finalmente percebi que não.
Minha arquitetura está categoricamente dividida em duas partes: serviços públicos e privados. Os serviços disponíveis publicamente incluem Jellyfin, Immich, Nextcloud, Uptime Kuma e outros que distribuo fora da minha rede doméstica. Todo o resto se enquadra na segunda categoria – o painel do Docker, ferramentas internas, interfaces administrativas e serviços de desenvolvimento que nunca pretendo expor publicamente.
Há muito tempo que uso o Tailscale para a segunda categoria. E acho que o funil se ajusta confortavelmente ao Tailscale. Exposição simples e direta quando eu realmente preciso, sem a sobrecarga do meu proxy reverso. Portanto, para trabalho temporário, não preciso criar um novo serviço Pangolin e definir DNS para ele. Posso simplesmente criar um funil temporário, distribuí-lo e desativá-lo quando terminar.
Em vez de expor tudo usando o Pangolin, fiquei mais consciente do que realmente merece uma URL pública, o que acaba tornando o trabalho do Pangolin muito mais limpo. No final do experimento percebi que a comparação Pangolim e Funil estava errada. Ambos resolvem problemas diferentes e podem trabalhar lado a lado.
Não é um substituto – um motivo para mantê-lo.
O funil substituiu o Pangolim? Não, o experimento não me transformou de volta no Pangolim. Na verdade, isso melhorou minha configuração e me fez entender quais serviços merecem uma URL pública permanente e quais precisam apenas de uma URL temporária. Eu hospedo alguns serviços que estão disponíveis na Internet aberta. E esses serviços merecem domínio próprio, roteamento real e escalabilidade, e não o resto. Comecei uma experiência tentando substituir o Pangolim. Finalmente entendi por que instalei o Tailscale em primeiro lugar.
