Tailscale Serve eller Funnel: vem kan egentligen öppna länken?

Båda kommandona publicerar en lokal tjänst via ett Tailscale HTTPS-namn, och från maskinen som kör dem ser de nästan identiska ut. Skillnaden är vem som kan nå URL:en efteråt, och den skillnaden avgör vilka kontroller din applikation fortfarande behöver. Serve håller publiken inom tailnetet, medan Funnel flyttar den till det öppna internetet. Välj publiken först och välj sedan kommandot som passar den.

Serve svarar på en fråga inne i ditt tailnet

Serve proxar en lokal port eller serverar lokalt innehåll till enheter i ditt tailnet, och tailnetets åtkomstregler gäller fortfarande för varje begäran. En instrumentpanel på port 3000 blir nåbar på ett HTTPS-namn som bara dina enheter kan slå upp och ansluta till. Det är rätt standard för interna verktyg, eftersom publiken redan är autentiserad av tailnetet och du inte lägger till en offentlig yta. URL:en ser ut som en vanlig webbplats, och det är just därför människor tar den för en sådan.

Serve kan också bifoga identitetsrubriker som beskriver tailnet-användaren till de begäranden den vidarebefordrar. Om din applikation litar på dessa rubriker som autentisering, bind backend till localhost så att inget annat kan nå den direkt; en backend som lyssnar på en dirigerbar adress kan ta emot begäranden som aldrig har gått genom proxyn.

Funnel ändrar publiken till det öppna internetet

Funnel publicerar en vald tjänst till alla som har URL:en, och besökare behöver inte klienten, ett konto eller medlemskap i ditt tailnet. Resursen behöver därför autentiseringen, hastighetsbegränsningen och uppdateringarna som du skulle tillämpa på vilken offentlig tjänst som helst. Offentliga begäranden bär inte Servens tailnet-identitetsrubriker, så en applikation som förlitade sig på dem har ingen användaridentitet alls under Funnel. Att välja ett annat publiceringskommando besvarar inte autentiseringsfrågan åt dig.

Funnel har också begränsningar som en handledning från en äldre version kanske inte nämner. Den avslutar TLS med ett certifikat som Tailscale hämtar för namnet, och den stöder bara vissa lyssnarportar, som Funnel-dokumentationen beskriver. Om din tjänst förväntar sig ett annat protokoll än HTTPS på en av dessa portar är Funnel fel verktyg och inte ett konfigurationspussel.

Läs läget från klienten, inte från porten

Kontrollera aktuellt tillstånd innan du delar något, eftersom de två lägena kan konfigureras för samma lokala port vid olika tidpunkter. Statuskommandona rapporterar vad som faktiskt är publicerat och för vem. Dra inte slutsatser om publiken av att en URL svarar.

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

Kommandosyntaxen har ändrats mellan klientversioner, så ett kopierat anrop kan välja ett annat läge än det du avsåg. Föredra den dokumenterade formen för den version du kör och läs bekräftelsen som klienten skriver ut i stället för att anta den. Om både en Serve- och en Funnel-konfiguration finns är den offentliga den som spelar roll för exponeringen. Återställ konfigurationen du inte avsåg i stället för att lägga ännu en ovanpå.

Stanna och läs statusen igen om utdata inte namnger publiken. En publicerad URL utan angiven publik är en gissning, och gissningar är hur interna instrumentpaneler hamnar på det öppna internetet.

Testa med den publik du faktiskt avsåg

Testa utifrån tailnetet, inte från maskinen som publicerade tjänsten. En begäran från en enhet i tailnetet bevisar att proxyn fungerar; den bevisar inte att en främling är utesluten. Använd ett nätverk utan Tailscale-klient och utan rutt in i tailnetet.

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

För en intern instrumentpanel bör den externa begäran misslyckas med att ansluta eller misslyckas med auktorisering, och den interna begäran bör lyckas med den identitet du förväntar dig. För en offentlig tjänst bör den externa begäran lyckas och applikationen bör begära sina egna autentiseringsuppgifter. Notera vilket av dessa två utfall du observerade, eftersom URL:en ensam inte säger det. Om resultatet är motsatsen till avsikten, ta bort den offentliga konfigurationen först och undersök efteråt.

Att publicera en tjänst är inte heller samma beslut som att välja en utgångsnod, som styr var din utgående trafik lämnar. Serve och Funnel svarar på vem som kan nå något du kör; en utgångsnod svarar på var dina egna anslutningar verkar komma från. Håll de två frågorna isär och jämförelsen förblir enkel.