Tailscale Serve fronte a Funnel: quen pode abrir a ligazón de verdade?

Ambos os comandos publican un servizo local mediante un nome HTTPS de Tailscale, e desde a máquina que os executa parecen case idénticos. A diferenza é quen pode chegar á URL despois, e esa diferenza decide que controis segue necesitando a túa aplicación. Serve mantén o público dentro da tailnet; Funnel trasládao á internet aberta. Escolle primeiro o público e logo o comando que encaixa con el.

Serve responde a unha pregunta dentro da túa tailnet

Serve fai de proxy dun porto local ou serve contido local aos dispositivos da túa tailnet, e as regras de acceso da tailnet seguen a aplicarse a cada solicitude. Un panel no porto 3000 vólvese accesible nun nome HTTPS que só os teus dispositivos poden resolver e ao que poden conectarse. É o valor predeterminado correcto para ferramentas internas, porque o público xa está autenticado pola tailnet e non engades unha superficie pública. A URL parece un sitio web normal, e por iso mesmo a xente tómaa por un.

Serve tamén pode anexar cabeceiras de identidade que describen o usuario da tailnet ás solicitudes que reenvía. Se a túa aplicación confía nesas cabeceiras como autenticación, liga o backend a localhost para que nada máis poida alcanzalo directamente; un backend que escoita nun enderezo encamiñable pode recibir solicitudes que nunca pasaron polo proxy.

Funnel cambia o público á internet aberta

Funnel publica un servizo seleccionado para calquera que teña a URL, e os visitantes non necesitan o cliente, unha conta nin pertenza á túa tailnet. O recurso necesita por tanto a autenticación, a limitación de taxa e os parches que aplicarías a calquera servizo público. As solicitudes públicas non levan as cabeceiras de identidade de tailnet de Serve, así que unha aplicación que dependía delas non ten ningunha identidade de usuario baixo Funnel. Escoller un comando de publicación distinto non responde por ti á pregunta da autenticación.

Funnel tamén ten restricións que un titorial dunha versión anterior pode non mencionar. Termina TLS cun certificado que Tailscale obtén para o nome, e só admite portos de escoita concretos, como describe a documentación de Funnel. Se o teu servizo espera un protocolo distinto de HTTPS nun deses portos, Funnel é a ferramenta equivocada e non un crebacabezas de configuración.

Le o modo no cliente, non no porto

Comproba o estado actual antes de compartir nada, porque os dous modos poden configurarse para o mesmo porto local en momentos distintos. Os comandos de estado informan do que está realmente publicado e para quen. Non deduzas o público do feito de que unha URL responda.

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

A sintaxe dos comandos cambiou entre versións do cliente, así que unha invocación copiada pode seleccionar un modo distinto do que pretendías. Prefire a forma documentada para a versión que executas e le a confirmación que imprime o cliente en lugar de supoñela. Se existen tanto unha configuración de Serve como unha de Funnel, a pública é a que importa para a exposición. Restablece a configuración que non querías en lugar de engadir outra enriba.

Detente e volve ler o estado se a saída non nomea o público. Unha URL publicada sen un público declarado é unha conxectura, e as conxecturas son a forma en que os paneis internos acaban na internet aberta.

Proba co público que realmente querías

Proba desde fóra da tailnet, non desde a máquina que publicou o servizo. Unha solicitude desde un dispositivo da tailnet demostra que o proxy funciona; non demostra que un descoñecido quede excluído. Usa unha rede que non teña cliente de Tailscale nin ruta cara á 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 un panel interno, a solicitude externa debería fallar ao conectar ou fallar a autorización, e a solicitude interna debería ter éxito coa identidade que esperas. Para un servizo público, a solicitude externa debería ter éxito e a aplicación debería pedir as súas propias credenciais. Anota cal deses dous resultados observaches, porque a URL soa non cho di. Se o resultado é o contrario do que pretendías, elimina primeiro a configuración pública e investiga despois.

Publicar un servizo tampouco é a mesma decisión que escoller un nodo de saída, que controla por onde sae o teu tráfico de saída. Serve e Funnel responden quen pode chegar a algo que executas; un nodo de saída responde de onde parecen vir as túas propias conexións. Mantén as dúas preguntas separadas e a comparación segue sendo sinxela.