Tailscale Funnel: das eine Wort, das Ihre App ins öffentliche Internet stellt

Zwei Tailscale-Befehle unterscheiden sich um ein Wort. tailscale serve teilt einen lokalen Dienst mit den Geräten Ihres eigenen Tailnets. tailscale funnel leitet Datenverkehr aus dem offenen Internet zu genau diesem Dienst, erreichbar für jeden, der die URL kennt.

Gleiche Syntax, umgekehrte Exponierung. Das ist der ganze Artikel in zwei Sätzen — aber wer es verwechselt, stellt einen für privat gehaltenen Dienst ins offene Internet. Es lohnt sich also, genau zu sein bei dem, was Funnel tut und was nicht.

Was Funnel tatsächlich ist

Die Beschreibung von Tailscale ist unmissverständlich: Funnel «lässt Sie Datenverkehr aus dem offenen Internet zu einem lokalen Dienst leiten, der auf einem Gerät in Ihrem Tailscale-Netz läuft». Der Zweck ist, mit Menschen zu teilen, die nicht in Ihrem Tailnet sind und kein Tailscale-Konto haben.

Serve ist der umgekehrte Fall, und die Dokumentation sagt es klar: Wer lokale Dienste nur mit den anderen Geräten im Tailnet teilen will, nimmt Serve.

Die Entscheidung ist also keine technische Vorliebe, sondern eine Frage nach Ihrem Publikum:

• Nur Ihre Maschinen und die ins Tailnet eingeladenen Personen → Serve.
• Jeder mit dem Link, auch Fremde → Funnel.

Wenn Sie diese Frage für einen Dienst nicht beantworten können, führen Sie noch keinen der beiden Befehle aus.

Die drei Einschränkungen, die über die Eignung entscheiden

Funnel ist bewusst eng gefasst, und seine Grenzen sind dokumentiert statt überraschend. Drei davon klären die meisten Fälle, bevor Sie eine Zeile Konfiguration schreiben.

Die Ports: 443, 8443, 10000. Das ist die vollständige Liste. Funnel kann nur auf diesen dreien lauschen. Das ist kein überschreibbarer Standard — muss Ihr Dienst öffentlich auf einem anderen Port erreichbar sein, ist Funnel das falsche Werkzeug.

Der Hostname gehört Tailscale. Funnel kann nur DNS-Namen aus der Domain Ihres Tailnets verwenden, in der Form tailnet-name.ts.net. Wenn Sie ein Produkt, eine Kundendemo oder irgendetwas mit Ihrer Marke auf einer eigenen Domain platzieren wollten: dafür ist es nicht gemacht.

Die Bandbreite ist gedeckelt, und der Deckel gehört nicht Ihnen. Tailscale gibt an, dass über Funnel gesendeter Verkehr nicht konfigurierbaren Bandbreitengrenzen unterliegt. Für eine Konfigurationsseite oder ein kleines internes Werkzeug ohne Belang. Für das Streamen einer Mediathek an Angehörige ist dieser Deckel vermutlich die Einschränkung — nicht Ihr Upload.

Der übersprungene Teil: davor steht keine Anmeldung

Das ist der Grund, warum die Verwechslung von Serve und Funnel schwerer wiegt als ein gewöhnlicher Tippfehler.

Die Dokumentation von Tailscale beschreibt keine Authentifizierungsschicht vor einem Funnel-Endpunkt — und das ist Absicht, denn der ganze Zweck besteht darin, Menschen zu bedienen, die nicht im Tailnet sind und daher von ihm nicht authentifiziert werden können. Funnel gibt Ihnen einen öffentlichen HTTPS-Eingang; es gibt Ihnen kein Tor.

Die praktische Folge: Die Anmeldung Ihrer Anwendung ist das Einzige zwischen dem Internet und Ihren Daten. Ein Dashboard ohne Passwort, ein Dateibrowser, der dem lokalen Netz vertraut, ein Admin-Panel, das nur aus dem LAN erreichbar war — sie alle stehen offen, sobald sie «gefunnelt» statt «geserved» werden.

Bevor Sie das für irgendetwas aktivieren, passt der ehrliche Test in eine Frage: Würde ich diese URL bedenkenlos öffentlich posten? Lautet die Antwort nein, braucht der Dienst zuerst eine eigene Authentifizierung — oder eben Serve statt Funnel.

Aktivieren: zuerst die Richtliniendatei

Funnel ist pro Knoten nicht standardmäßig aktiv. Es verlangt ein Knotenattribut funnel in der Richtliniendatei Ihres Tailnets, das Tailscale mitteilt, welche Nutzer es verwenden dürfen. Standardmäßig gilt das für autogroup:member.

Diese Zwischenstufe sollte man verstehen statt wegklicken: Sie bedeutet, dass Funnel eine administrative Entscheidung auf Tailnet-Ebene ist, nicht bloß ein Befehl, den jemand auf seinem Laptop ausführt. In einem geteilten Tailnet entscheidet, wer die Richtliniendatei kontrolliert, ob überhaupt jemand Dienste öffentlich stellen kann.

Wann Funnel die richtige Antwort ist – und wann nicht

Funnel passt, wenn Sie jemandem außerhalb Ihres Tailnets mit minimalem Aufwand eine funktionierende HTTPS-URL geben wollen: ein Webhook-Endpunkt, den ein Fremddienst erreichen muss, eine Vorschau auf etwas, das Sie bauen, eine befristete Freigabe. Zertifikate und öffentlicher Eingang werden für Sie erledigt, und es funktioniert in jedem Tarif.

Funnel passt nicht, wenn Sie eine eigene Domain brauchen, einen Port außerhalb der drei erlaubten, dauerhaften Durchsatz oder eine Authentifizierungsschicht, die Sie selbst kontrollieren. Diese Anforderungen weisen woandershin: ein Reverse Proxy auf einem Host mit eigener öffentlicher IP, oder ein Tunnel-Produkt, das um eigene Domains herum gebaut ist.

Und für den Fall, den die meisten eigentlich meinen, wenn sie zu Funnel greifen — ich möchte, dass meine eigenen Geräte diesen Dienst von überall erreichen — ist weder Funnel noch ein öffentlicher Tunnel die Antwort. Das leistet das Tailnet bereits, ebenso wie ein Exit Node oder ein selbst gehosteter WireGuard-Server — ohne irgendetwas öffentlich zu exponieren.

Das Wesentliche

serve und funnel liegen im Terminal ein Wort auseinander und sind in dem, was sie veröffentlichen, gegensätzlich. Serve hält einen Dienst im Tailnet; Funnel stellt ihn ins Internet, auf einem von drei Ports, unter einem ts.net-Hostnamen, mit gedeckelter Bandbreite und ohne irgendetwas, das Besucher authentifiziert.

Entscheiden Sie vor dem Tippen, welches Publikum Sie wirklich meinen. Lautet die Antwort «meine eigenen Maschinen», brauchten Sie nie einen öffentlichen Eingang — und die sicherste Exponierung ist die, die man nie geöffnet hat.