Tailscale Serve ou Funnel: quem pode realmente abrir a ligação?

Ambos os comandos publicam um serviço local através de um nome HTTPS do Tailscale, e a partir da máquina que os executa parecem quase idênticos. A diferença está em quem pode alcançar o URL depois, e essa diferença decide que controlos a sua aplicação ainda precisa. O Serve mantém o público dentro da tailnet, enquanto o Funnel o move para a internet aberta. Escolha primeiro o público e depois o comando que lhe corresponde.

O Serve responde a uma pergunta dentro da sua tailnet

O Serve faz de proxy a uma porta local ou serve conteúdo local aos dispositivos da sua tailnet, e as regras de acesso da tailnet continuam a aplicar-se a cada pedido. Um painel na porta 3000 torna-se acessível num nome HTTPS que só os seus dispositivos podem resolver e ao qual se podem ligar. É a predefinição correta para ferramentas internas, porque o público já está autenticado pela tailnet e não está a acrescentar uma superfície pública. O URL parece um sítio web normal, e é precisamente por isso que as pessoas o tomam por um.

O Serve também pode anexar cabeçalhos de identidade que descrevem o utilizador da tailnet aos pedidos que reencaminha. Se a sua aplicação confia nesses cabeçalhos como autenticação, ligue o backend ao localhost para que mais nada o possa alcançar diretamente; um backend à escuta num endereço encaminhável pode receber pedidos que nunca passaram pelo proxy.

O Funnel muda o público para a internet aberta

O Funnel publica um serviço escolhido para qualquer pessoa que tenha o URL, e os visitantes não precisam do cliente, de uma conta ou de pertencer à sua tailnet. O recurso precisa, por isso, da autenticação, da limitação de taxa e das correções que aplicaria a qualquer serviço público. Os pedidos públicos não transportam os cabeçalhos de identidade da tailnet do Serve, pelo que uma aplicação que dependia deles não tem qualquer identidade de utilizador sob o Funnel. Escolher um comando de publicação diferente não responde à pergunta da autenticação por si.

O Funnel tem também restrições que um tutorial de uma versão mais antiga pode não mencionar. Termina o TLS com um certificado que o Tailscale obtém para o nome e suporta apenas portas de escuta específicas, como descreve a documentação do Funnel. Se o seu serviço espera um protocolo diferente de HTTPS numa dessas portas, o Funnel é a ferramenta errada e não um quebra-cabeças de configuração.

Leia o modo no cliente, não na porta

Verifique o estado atual antes de partilhar seja o que for, porque os dois modos podem ser configurados para a mesma porta local em momentos diferentes. Os comandos de estado indicam o que está realmente publicado e para quem. Não deduza o público do facto de um URL responder.

tailscale serve status
tailscale funnel status
tailscale status --json | head -40

A sintaxe dos comandos mudou entre versões do cliente, pelo que uma invocação copiada pode selecionar um modo diferente do que pretendia. Prefira a forma documentada para a versão que executa e leia a confirmação impressa pelo cliente em vez de a assumir. Se existirem tanto uma configuração Serve como uma Funnel, a pública é a que importa para a exposição. Reponha a configuração que não pretendia em vez de acrescentar outra por cima.

Pare e volte a ler o estado se a saída não nomear o público. Um URL publicado sem público declarado é um palpite, e os palpites são a forma como os painéis internos acabam na internet aberta.

Teste com o público que realmente pretendia

Teste de fora da tailnet, não a partir da máquina que publicou o serviço. Um pedido de um dispositivo da tailnet prova que o proxy funciona; não prova que um estranho está excluído. Utilize uma rede sem cliente Tailscale e sem rota para a tailnet.

curl -sI https://host.tailnet-name.ts.net
curl -sI https://host.tailnet-name.ts.net --resolve host.tailnet-name.ts.net:443:203.0.113.10

Para um painel interno, o pedido externo deve falhar a ligação ou falhar a autorização, e o pedido interno deve ter sucesso com a identidade que espera. Para um serviço público, o pedido externo deve ter sucesso e a aplicação deve pedir as suas próprias credenciais. Registe qual desses dois resultados observou, porque o URL sozinho não lhe diz. Se o resultado for o oposto da intenção, remova primeiro a configuração pública e investigue depois.

Publicar um serviço também não é a mesma decisão que escolher um nó de saída, que controla de onde sai o seu tráfego de saída. O Serve e o Funnel respondem a quem pode alcançar algo que executa; um nó de saída responde de onde parecem vir as suas próprias ligações. Mantenha as duas perguntas separadas e a comparação continua simples.