Einen lokalen Dev-Server mit Tailscale einem Kunden zeigen

Ein Kunde möchte die Seite sehen, bevor sie live geht. Die Seite ist ein Dev-Server auf meinem Laptop auf Port 3000, und die ehrlichen Optionen waren früher: irgendwo eine Vorschau deployen, den Bildschirm teilen oder mit einem Tunneldienst kämpfen. Tailscale hat zwei Befehle dafür, und sie unterscheiden sich in genau einer Sache: wer den Link öffnen kann.

tailscale serve --bg 3000      # HTTPS-Link für Geräte in meinem Netz
tailscale funnel --bg 3000     # HTTPS-Link für jeden im Internet
tailscale serve status         # was gerade geteilt ist
tailscale serve reset          # alles aus

serve: für Leute in deinem Netz

tailscale serve nimmt einen lokalen Port und veröffentlicht ihn per HTTPS unter dem Namen des Rechners, nur für Geräte in deinem eigenen Tailscale-Netz. Das Zertifikat kommt über Tailscale von Let's Encrypt, der Browser zeigt also ein Schloss und keine Warnung. Die URL ist https://<rechner>.<dein-tailnet>.ts.net, und jeder, der im selben Netz angemeldet ist, kann sie öffnen: mein Handy auf dem Sofa, ein Kollege, der schon drin ist. Sonst löst niemand den Namen überhaupt auf. Ich benutze das ständig, um ein Layout auf einem echten Handy zu prüfen, ohne IP und Port einzutippen.

funnel: für Leute außerhalb

tailscale funnel ist dasselbe mit offener Tür zum öffentlichen Internet. Der Link funktioniert für jeden, ohne Tailscale-Konto, ohne App. Der Verkehr kommt über die Relay-Server von Tailscale herein und endet auf meinem Laptop, wo TLS terminiert; das Relay transportiert also nur Chiffrat.

Zwei Voraussetzungen, beide einmalig: HTTPS-Zertifikate und MagicDNS müssen für das Netz aktiviert sein, und die Policy-Datei braucht ein Node-Attribut, das Funnel auf diesem Rechner erlaubt. Beim ersten Aufruf druckt die CLI die genauen Zeilen zum Einfügen oder einen Link in die Admin-Konsole, die es für dich erledigt. Auf der öffentlichen Seite sind nur die Ports 443, 8443 und 10000 erlaubt; der lokale Port ist beliebig.

Welchen nehmen

Serve, wenn der Betrachter Tailscale hat: meine eigenen Geräte und die Leute, mit denen ich täglich arbeite. Funnel, wenn nicht: ein Kunde, ein Reviewer, jemand, der auf einen Link klicken und eine Seite sehen soll. Funnel ist der, zu dem ich seltener greife und den ich früher wieder abschalte.

Was Funnel nicht ist: eine Staging-Umgebung. Der Link lebt, solange mein Laptop wach ist und der Dev-Server läuft. Deckel zu, Link tot. Die Bandbreite durchs Relay ist bescheiden, gut für einen Seitenrundgang, falsch für einen Launch oder einen Video-Upload. Und der Name leitet sich vom Rechnernamen ab, ist also kein Geheimnis; wenn der Inhalt zählt, bleibt das eigene Login des Dev-Servers davor.

Eigenheiten der Dev-Server

Der Proxy leitet an 127.0.0.1:3000 weiter, mit dem öffentlichen Hostnamen im Host-Header. Den meisten Servern ist das egal. Vite nicht, es verweigert mit einer Blocked-Host-Meldung, bis der Name in server.allowedHosts steht; neuere Next-Versionen wollen den Origin in allowedDevOrigins. Hot Reload funktioniert durch beide Befehle, was mich immer noch ein bisschen überrascht.

Wieder abschalten

--bg hält die Freigabe im Hintergrund am Leben, nachdem der Befehl zurückgekehrt ist; das willst du für einen Tag Hin und Her. Für einen einstündigen Call lasse ich das Flag weg: Der Befehl läuft dann im Vordergrund, und mit dem Terminalfenster endet auch die Freigabe. So oder so räumt tailscale serve reset jeden serve- und funnel-Eintrag auf dem Rechner weg, und tailscale serve status sollte danach nichts mehr ausgeben. Die Status-Zeile tippe ich nach jeder Demo, denn von einem vergessenen öffentlichen Link auf einen Dev-Server erfährst du sonst von einem Fremden.