Tailscale Serve oder Funnel: Wer kann den Link wirklich öffnen?

Beide Befehle veröffentlichen einen lokalen Dienst über einen Tailscale-HTTPS-Namen, und vom ausführenden Rechner aus sehen sie fast identisch aus. Der Unterschied liegt darin, wer die URL danach erreichen kann, und dieser Unterschied entscheidet, welche Kontrollen deine Anwendung noch braucht. Serve hält die Zielgruppe im Tailnet, Funnel verschiebt sie ins offene Internet. Wähle zuerst die Zielgruppe und dann den Befehl, der zu ihr passt.

Serve beantwortet eine Frage innerhalb deines Tailnets

Serve proxyt einen lokalen Port oder liefert lokale Inhalte an Geräte in deinem Tailnet, und die Zugriffsregeln des Tailnets gelten weiterhin für jede Anfrage. Ein Dashboard auf Port 3000 wird unter einem HTTPS-Namen erreichbar, den nur deine Geräte auflösen und mit dem sie sich verbinden können. Das ist die richtige Voreinstellung für interne Werkzeuge, weil die Zielgruppe bereits durch das Tailnet authentifiziert ist und du keine öffentliche Fläche hinzufügst. Die URL sieht aus wie eine normale Website, und genau deshalb halten Menschen sie für eine.

Serve kann außerdem Identitäts-Header, die den Tailnet-Benutzer beschreiben, an weitergeleitete Anfragen anhängen. Wenn deine Anwendung diesen Headern als Authentifizierung vertraut, binde das Backend an localhost, damit nichts anderes es direkt erreichen kann; ein Backend, das auf einer routbaren Adresse lauscht, kann Anfragen erhalten, die nie durch den Proxy gegangen sind.

Funnel ändert die Zielgruppe auf das offene Internet

Funnel veröffentlicht einen ausgewählten Dienst für jeden, der die URL hat, und Besucher brauchen weder den Client noch ein Konto noch eine Mitgliedschaft in deinem Tailnet. Die Ressource braucht daher die Authentifizierung, Ratenbegrenzung und Patches, die du auf jeden öffentlichen Dienst anwenden würdest. Öffentliche Anfragen tragen nicht Serves Tailnet-Identitäts-Header, also hat eine Anwendung, die sich darauf verlassen hat, unter Funnel überhaupt keine Benutzeridentität. Ein anderer Veröffentlichungsbefehl beantwortet die Authentifizierungsfrage nicht für dich.

Funnel hat auch Einschränkungen, die ein Tutorial aus einer älteren Version vielleicht nicht erwähnt. Es beendet TLS mit einem Zertifikat, das Tailscale für den Namen bezieht, und unterstützt nur bestimmte Listening-Ports, wie die Funnel-Dokumentation beschreibt. Wenn dein Dienst auf einem dieser Ports ein anderes Protokoll als HTTPS erwartet, ist Funnel das falsche Werkzeug und kein Konfigurationsrätsel.

Lies den Modus am Client ab, nicht am Port

Prüfe den aktuellen Zustand, bevor du etwas teilst, denn beide Modi können zu unterschiedlichen Zeiten für denselben lokalen Port konfiguriert sein. Die Statusbefehle melden, was tatsächlich veröffentlicht ist und für wen. Schließe nicht von der Tatsache, dass eine URL antwortet, auf die Zielgruppe.

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

Die Befehlssyntax hat sich über Client-Versionen geändert, sodass ein kopierter Aufruf einen anderen Modus wählen kann als den beabsichtigten. Bevorzuge die dokumentierte Form für die Version, die du ausführst, und lies die Bestätigung, die der Client ausgibt, statt sie anzunehmen. Wenn sowohl eine Serve- als auch eine Funnel-Konfiguration existiert, ist die öffentliche diejenige, die für die Exposition zählt. Setze die Konfiguration zurück, die du nicht gemeint hast, statt eine weitere darüberzulegen.

Halte an und lies den Status erneut, wenn die Ausgabe die Zielgruppe nicht nennt. Eine veröffentlichte URL ohne genannte Zielgruppe ist eine Vermutung, und Vermutungen sind der Weg, auf dem interne Dashboards im offenen Internet landen.

Teste mit der Zielgruppe, die du tatsächlich gemeint hast

Teste von außerhalb des Tailnets, nicht vom Rechner, der den Dienst veröffentlicht hat. Eine Anfrage von einem Tailnet-Gerät beweist, dass der Proxy funktioniert; sie beweist nicht, dass ein Fremder ausgeschlossen ist. Nutze ein Netzwerk ohne Tailscale-Client und ohne Route ins 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

Für ein internes Dashboard sollte die äußere Anfrage nicht verbinden oder die Autorisierung verfehlen, und die innere Anfrage sollte mit der erwarteten Identität gelingen. Für einen öffentlichen Dienst sollte die äußere Anfrage gelingen und die Anwendung ihre eigenen Zugangsdaten abfragen. Halte fest, welches der beiden Ergebnisse du beobachtet hast, denn die URL allein sagt es dir nicht. Wenn das Ergebnis dem Vorhaben entgegengesetzt ist, entferne zuerst die öffentliche Konfiguration und untersuche danach.

Einen Dienst zu veröffentlichen ist auch nicht dieselbe Entscheidung wie die Wahl eines Exit-Nodes, der steuert, wo dein ausgehender Verkehr das Netz verlässt. Serve und Funnel beantworten, wer etwas erreicht, das du betreibst; ein Exit-Node beantwortet, woher deine eigenen Verbindungen zu kommen scheinen. Halte die beiden Fragen getrennt, und der Vergleich bleibt einfach.