Tailscale Funnel: a palavra que põe a tua aplicação na internet pública

Dois comandos da Tailscale diferem numa palavra. tailscale serve partilha um serviço local com os dispositivos da tua própria tailnet. tailscale funnel encaminha tráfego da internet em sentido lato para esse mesmo serviço, ao alcance de qualquer pessoa que tenha o URL.

Mesma sintaxe, exposição oposta. É o artigo inteiro em duas frases — mas trocar o sentido deixa na internet aberta um serviço que julgavas privado, por isso vale a pena ser preciso sobre o que o Funnel faz e não faz.

O que o Funnel é, na realidade

A descrição da Tailscale é direta: o Funnel «permite encaminhar tráfego da internet em sentido lato para um serviço local em execução num dispositivo da tua rede Tailscale». O objetivo é partilhar com pessoas que não estão na tua tailnet e não têm conta Tailscale.

O Serve é o caso inverso, e a documentação di-lo sem rodeios: se queres partilhar serviços locais apenas com os outros dispositivos da tailnet, usa o Serve.

A decisão não é, portanto, uma preferência técnica, é uma pergunta sobre o teu público:

• Apenas as tuas máquinas e as pessoas convidadas para a tailnet → Serve.
• Qualquer pessoa com a ligação, incluindo desconhecidos → Funnel.

Se não souberes responder a essa pergunta para um dado serviço, não corras ainda nenhum dos dois comandos.

As três restrições que decidem se o Funnel serve

O Funnel é deliberadamente estreito, e os seus limites estão documentados em vez de serem descobertos pelo caminho. Três deles resolvem a maioria dos casos antes de escreveres uma linha de configuração.

As portas: 443, 8443, 10000. É a lista completa. O Funnel só pode escutar nessas três. Não é um valor por omissão a sobrepor — se o teu serviço tiver de estar acessível publicamente noutra porta, o Funnel não é a ferramenta.

O nome de anfitrião pertence à Tailscale. O Funnel só pode usar nomes DNS do domínio da tua tailnet, na forma tailnet-name.ts.net. Se pensavas colocar um produto, uma demonstração para clientes ou algo com a tua marca num domínio teu, não é isso que ele faz.

A largura de banda tem teto, e o teto não é teu. A Tailscale afirma que o tráfego enviado através do Funnel está sujeito a limites não configuráveis. Para uma página de configuração ou uma ferramenta interna pequena, é irrelevante. Para transmitir uma mediateca a familiares, esse teto será provavelmente o constrangimento, antes da tua velocidade de envio.

A parte que se salta: não há qualquer início de sessão à frente

É a razão pela qual a confusão entre Serve e Funnel pesa mais do que uma gralha vulgar.

A documentação da Tailscale não descreve qualquer camada de autenticação à frente de um ponto de entrada Funnel — e é intencional, porque toda a sua finalidade é servir pessoas que não estão na tailnet e que, por isso, não podem ser autenticadas por ela. O Funnel dá-te uma entrada HTTPS pública; não te dá uma porta.

Consequência prática: a autenticação da tua aplicação é a única coisa entre a internet e os teus dados. Um painel sem palavra-passe, um explorador de ficheiros que confia na rede local, um painel de administração que só era acessível a partir da LAN — todos ficam abertos no momento em que são «funnelados» em vez de servidos.

Antes de ativar isto sobre o que quer que seja, o teste honesto cabe numa pergunta: publicaria este URL abertamente sem desconforto? Se a resposta for não, o serviço precisa da sua própria autenticação, ou precisa do Serve em vez do Funnel.

Ativá-lo: primeiro o ficheiro de políticas

O Funnel não está ativo por omissão num nó. Exige um atributo de nó funnel no ficheiro de políticas da tua tailnet, que indica à Tailscale que utilizadores o podem usar. Por omissão, esse direito vai para autogroup:member.

Essa mediação merece ser compreendida em vez de ignorada: significa que o Funnel é uma decisão administrativa ao nível da tailnet, não apenas um comando que alguém corre no portátil. Numa tailnet partilhada, quem controla o ficheiro de políticas controla a própria possibilidade de expor serviços publicamente.

Quando o Funnel é a resposta certa e quando não é

O Funnel encaixa quando queres dar a alguém de fora da tua tailnet um URL HTTPS que funcione com o mínimo de cerimónia: um ponto de entrada de webhook que um serviço terceiro tem de alcançar, uma pré-visualização do que estás a construir, uma partilha temporária. Os certificados e a entrada pública são tratados por ti, e funciona em todos os planos.

O Funnel não encaixa quando precisas de um domínio teu, de uma porta fora das três permitidas, de débito sustentado ou de uma camada de autenticação que controles. Esses requisitos apontam para outro lado: um proxy inverso numa máquina com IP público próprio, ou um produto de túnel construído em torno de domínios personalizados.

E para o caso em que as pessoas mais frequentemente pensam ao recorrer ao Funnel — quero que os meus dispositivos alcancem este serviço a partir de qualquer lugar — nem o Funnel nem um túnel público são a resposta. É o que a tailnet já faz, e o que um nó de saída ou um servidor WireGuard auto-hospedado fazem sem expor seja o que for publicamente.

O essencial

serve e funnel estão a uma palavra de distância no terminal e são opostos naquilo que publicam. O Serve mantém um serviço dentro da tailnet; o Funnel põe-no na internet, numa de três portas, sob um nome ts.net, com teto de largura de banda e sem nada que autentique os visitantes.

Decide antes de escrever qual é o público que realmente pretendes. Se a resposta for «as minhas máquinas», nunca precisaste de uma entrada pública — e a exposição mais segura continua a ser a que nunca se abriu.