Mesh VPNs vs. Öffentliche Tunnels: Der Tailscale Funnel Wandel

Für über ein Jahrzehnt folgte das Exponieren eines lokal laufenden Webservers im öffentlichen Internet einer vertrauten Routine: Terminal öffnen, ngrok http 8080 ausführen, die zufällig generierte öffentliche URL kopieren und in eine Webhook-Konfiguration einfügen oder mit einem Kollegen teilen.

Öffentliche Reverse-Proxys wie ngrok machten die lokale Webentwicklung erheblich einfacher, brachten aber auch einen leisen Sicherheitskompromiss in moderne Unternehmensabläufe. Das Betreiben eines öffentlichen Tunnel-Agents öffnet eine Lücke durch Firewalls, NATs und Zero Trust Network Access (ZTNA)-Richtlinien — eine, die das Sicherheitsteam oft nicht sieht. Jede exponierte öffentliche URL, wenn sie entdeckt oder durch Brute-Force erlangt wird, kann einen unautentifizierten Einstiegspunkt in eine Entwickler-Umgebung, interne APIs oder das umgebende Firmennetzwerk darstellen.

Da Plattform- und Sicherheitsteams zunehmend auf Zero-Trust-Architekturen setzen, wird ein Teil dieser ad-hoc öffentlichen Proxy-Nutzung in bestimmten, enger gefassten Situationen durch WireGuard-basierte Mesh VPNs und identitätsbewusste Edge-Funktionen wie Tailscale Funnel ersetzt. Es ist wichtig zu sagen: Funnel ist seit seiner Einführung 2023 eine Beta-Funktion und wird noch immer so in den Tailscale-Dokumentationen bezeichnet. Daher ist “ngrok ersetzen” eher für interne Teams, die bereits Tailscale standardisiert haben, zutreffender als ein branchenweiter Wandel.

Dieser Artikel erklärt, warum einige Plattform-Engineering-Teams Mesh-basierte Zugänge gegenüber ad-hoc öffentlichen Proxys bevorzugen, wie Zero-Trust-Localhost-Sharing im Detail funktioniert und wo der Vergleich zwischen Tailscale Funnel und ngrok Bestand hat — und wo nicht.

Die Sicherheitskrise traditioneller öffentlicher Tunnels

1. Perimeter-Umgehung, kein natives IAM

Traditionelle öffentliche Tunnel-Agents öffnen eine verschlüsselte ausgehende TCP/TLS-Verbindung von einem lokalen Arbeitsplatz zu einer Relay-Cloud eines Drittanbieters. Öffentliche Nutzer greifen auf die Domain des Relays zu, das den Traffic an den lokalen Port des Entwicklers weiterleitet.

Dies umgeht standardmäßig Netzwerküberwachung, WAFs und Identitätsanbieter. Es sei denn, der Entwickler konfiguriert Authentifizierung innerhalb seiner Anwendung (oder über Edge-Funktionen des Tunnel-Anbieters — mehr dazu unten), ist der lokale Dienst ungeschützt im Internet.

2. Geheimnis-Leckage und ephemere Verbreitung

Entwickler testen routinemäßig lokale Apps mit Staging-Credentials, unredigierten API-Schlüsseln oder internen Endpunkten. Wird eine öffentliche Tunnel-URL in GitHub committet, in einem öffentlichen Slack-Kanal gepostet oder von einem Scanner durchsucht, werden diese Geheimnisse erreichbar.

3. Fehlende Governance und Audit-Transparenz

Sicherheitsteams haben häufig keine zentrale Übersicht darüber, welche Entwickler zu einem bestimmten Zeitpunkt öffentliche Tunnel-Binaries laufen lassen oder was während einer Tunnel-Laufzeit erreichbar war.

+-----------------------------------------------------------------------------------+
|                            TRADITIONELLE ÖFFENTLICHE TUNNELS                        |
+-----------------------------------------------------------------------------------+

  Öffentliches Internet        Public Tunnel Gateway                  Lokaler Arbeitsplatz
  +---------------+             +-------------------+                  +---------------+
  | Anonymer      | ------e | Öffentlicher Relay | === TLS Tunnel =| Entwickler    |
  | Angreifer    |             | (statische/zufällige IP)|             | Localhost     |
  +---------------+             +-------------------+                  +---------------+
                                      |
                          (Kein natives IAM, sofern nicht konfiguriert;
                           Perimeter/WAF/IdP standardmäßig umgangen)

Der Paradigmenwechsel: WireGuard Mesh-Netzwerke und Zero Trust

Anstatt die Exposition lokaler Ports als Routing-Problem zu behandeln, sieht Mesh-Netzwerk es als Identitäts- und Overlay-Routing-Problem.

Ein Mesh-VPN (Tailscale, Headscale, NetBird und ähnliche Tools) baut ein Peer-to-Peer-Overlay-Netzwerk — Tailscale nennt es ein tailnet — auf dem bestehenden physischen Netzwerk auf, unter Verwendung von WireGuard als Transport. Im Gegensatz zu klassischen Hub-and-Spoke-VPNs, die den gesamten Unternehmensverkehr durch einen Engpass leiten, bevorzugt ein Mesh-Netzwerk direkte, kryptografisch verifizierte Verbindungen zwischen Geräten, wo immer möglich.

• Public-Key-Identität: Knoten authentifizieren sich gegenseitig mittels WireGuard’s Curve25519-Schlüsselaustausch, mit ChaCha20-Poly1305 für Verschlüsselung — es gibt keine geteilte statische IP oder vorab geteiltes Geheimnis, das geleakt werden könnte.
• Identitätsbasierter Zugriff: Knoten sind an Nutzer-Identitäten eines Enterprise IdP (Okta, Microsoft Entra ID, Google Workspace und andere via SSO/SAML/OIDC) gebunden.
• NAT-Traversal: Tailscale-Clients verwenden STUN, um ihre öffentliche IP/Port durch NAT zu entdecken, und versuchen dann direkte UDP-Hole-Punching zwischen Peers. Wenn das fehlschlägt — häufig hinter symmetrischen (“harten”) NATs, Carrier-Grade NATs oder strengen Firewalls — fällt der Traffic auf das eigene Relay-Protokoll DERP (Designated Encrypted Relay for Packets) zurück. DERP ist Tailscale-eigenes Design, nicht der Standard ICE/TURN-Stack von WebRTC; es spielt eine ähnliche Rolle, läuft aber über HTTPS und authentifiziert mit WireGuard-Schlüsseln statt TURN-Credentials. Jede Verbindung beginnt technisch relayed durch DERP und wird dann opportunistisch auf einen direkten Pfad hochgestuft.

Zero-trust localhost sharing

Im reinen Mesh-Modell, wenn Entwickler A http://localhost:3000 mit Entwickler B teilen möchte, wird der Dienst niemals öffentlich exponiert. Entwickler A läuft stattdessen tailscale serve, was den Port nur für authentifizierte Geräte im tailnet erreichbar macht. ACLs (oder die neuere grants-Syntax — siehe unten) bestimmen genau, welche Nutzer oder Rollen darauf zugreifen dürfen.

Wie Tailscale Funnel tatsächlich funktioniert

Interne Peer-to-Peer-Sharing deckt die meisten alltäglichen Entwicklerzusammenarbeiten ab, aber Teams benötigen dennoch öffentliche Endpunkte für Dinge wie eingehende Webhooks von Stripe, GitHub, Twilio oder Shopify. Hier schließt Tailscale Funnel die Lücke — und es ist wichtig, den aktuellen Status genau zu verstehen: Funnel ist seit März 2023 in Beta und wird in der Tailscale-Dokumentation noch immer so beschrieben. Es ist auf Free-, Personal/Premium- und Enterprise-Plänen verfügbar, aber Tailscale behält sich das Recht vor, die Funktion mit Vorankündigung zu ändern oder zu deaktivieren. Es gibt keine garantierte Support-Stufe für GA-Features.

+-----------------------------------------------------------------------------------+
|                          TAILSCALE FUNNEL-ARCHITEKTUR                            |
+-----------------------------------------------------------------------------------+

  Öffentliche Webhook        Tailscale Funnel Ingress                Entwickler-Arbeitsstation
  (z.B. Stripe)             (Public Ingress Node)                   (Privates Tailnet-Node)
  +--------------+          +--------------------+                  +------------------+
  | Event senden | -------e | Funnel Ingress     | === WireGuard == | Tailscale Agent  |
  | HTTPS        |          | (TLS-Beendigung)   |    Overlay-Pfad | -e 127.0.0.1:3000|
  +--------------+          +--------------------+                  +------------------+
                                      |                                       |
                            Automatisch ausgestellte Let's             Gesteuert durch die "funnel"
                            Encrypt-Zertifikate für                     nodeAttr in der tailnet
                            cnodee.ctailnete.ts.net               Richtlinie

Wie eine Anfrage tatsächlich fließt:

1. Tailscale betreibt eine globale Reihe von Funnel-Ingress-Servern. Wenn Sie Funnel aktivieren, erstellt Tailscale einen öffentlichen DNS-Eintrag für Ihren Node’s MagicDNS-Name (node-name.tailnet-name.ts.net) und weist auf diese Server. Zudem wird automatisch ein Let’s Encrypt-Zertifikat dafür ausgestellt.
2. Ein öffentlicher Client verbindet sich über HTTPS mit einem nahegelegenen Funnel-Ingress-Node.
3. Dieser Node öffnet einen TCP-Proxy zu Ihrem Gerät über das tailnet und übergibt den verschlüsselten Stream — die Tailscale-Ingress-Server erhalten nur so viel tailnet-Zugriff, wie nötig, um diese Verbindung herzustellen.
4. Der Tailscale-Daemon auf Ihrem Gerät beendet die TLS-Verbindung lokal und leitet Klartext-Traffic an 127.0.0.1:cporte weiter (derzeit proxyt Funnel nur zu Loopback-Adressen).

Ein wichtiger Punkt, den das “Zero Trust”-Rahmenwerk verschleiern kann: Sobald Funnel für einen Port aktiviert ist, ist dieser Endpunkt öffentlich und standardmäßig unauthentifiziert, genauso wie eine ngrok-URL. Das Identitätsmodell von Tailscale regelt wer Funnel aktivieren darf (über das funnel-Node-Attribut in der tailnet-Richtlinie) — es prüft jedoch nicht, wer den öffentlichen URL aufruft. Wenn Sie eine Authentifizierung pro Anfrage auf einem Funnel-Endpunkt benötigen, müssen Sie diese auf Anwendungsebene hinzufügen, genau wie bei jedem anderen Tunnel.

Architektonischer Vergleich: Tailscale Funnel vs. ngrok

Dimension	ngrok	Tailscale Funnel
Primäres Modell	Zentralisierter Reverse-Proxy-Relay	Peer-to-Peer-Mesh-Overlay mit öffentlichem Ingress-Edge
Standardzugang	Öffentlich für jeden mit URL	Privat im tailnet (serve); öffentlich nur bei expliziter Markierung (funnel)
Reifegrad	GA, produktiv in allen kostenpflichtigen Tarifen	Beta seit 2023; auf allen Plänen, kein GA-SLA
Per-Request-Identität	Traffic Policy unterstützt Basic Auth, OAuth (Google/GitHub etc.), OIDC, JWT-Validierung und — auf Enterprise — SAML SSO für das Dashboard, vor Traffic-Weiterleitung bei ngrok	Kein Per-Request-Auth auf dem Funnel-Pfad selbst; ACLs/Grants steuern wer Funnel aktivieren darf, nicht wer ihn erreicht
Zugrundeliegendes Protokoll	Custom TLS/HTTP-Tunnel-Multiplexing	WireGuard-Overlay + STUN/DERP für NAT-Traversal
Domain/URL	Zufällige Ephemeral-Subdomain (kostenlos) oder reservierte/custom Domains (bezahlt)	Stabiles node.tailnet.ts.net MagicDNS mit automatisch ausgestelltem TLS
Erlaubte Ports	Jeder Port, den Sie tunneln möchten	HTTPS-Funnel beschränkt auf 443, 8443 oder 10000
Governance	Enterprise-Plan unterstützt SAML SSO für das ngrok-Dashboard und zentrales API-Key/Traffic-Policy-Management	Zentralisiertes, versionkontrolliertes HuJSON-Policy-File (ACLs oder die neuere grants-Syntax)
Preis (Stand Mitte 2026)	Kostenloser Tarif ($0, kleiner Nutzungskredit); Hobbyist ca. $8–10/Monat (5 GB, 100k Anfragen); Pay-as-you-go ab $20/Monat + Nutzung	Tailscale selbst: kostenloser Personal-Tarif (bis 6 Nutzer); Standard ca. $8/Nutzer/Monat, Premium ca. $18/Nutzer/Monat, Enterprise individuell (Funnel ist kein separater Preis — ist eine Funktion Ihres Tailscale-Plans)

Ein gerechterer Vergleich als “ngrok hat keine Identität, Tailscale schon” ist: ngrok erzwingt Identität pro HTTP-Anfrage an seinem Edge (nützlich für das Gatekeeping eines bestimmten öffentlichen Endpunkts), während Tailscale Identität auf Netzwerkebene erzwingt (nützlich, um zu entscheiden, welche Menschen und Geräte überhaupt im tailnet existieren und welche von ihnen öffentlich etwas exponieren dürfen). Sie lösen nebeneinanderstehende, aber unterschiedliche Probleme, und für öffentlich zugängliche Endpunkte, die pro Besucher-Authentifizierung benötigen, ist ngrok’s Traffic Policy heute vermutlich die passendere Lösung.

Einrichtung beider Modi

Das CLI wurde ab Tailscale Client v1.38.1 (Funnel in eigenem Befehl) und erneut in v1.52 (beide Befehle in einer Zeile für den gemeinsamen Fall) deutlich vereinfacht. Wenn Sie ältere Tutorials mit tailscale serve https / http://127.0.0.1:3000-Syntax gesehen haben, ist das die Vor-1.52-Form — es funktioniert noch, ist aber nicht mehr in aktuellen Dokumentationen oder --help-Ausgaben.

Private, tailnet-interne Freigabe:

# Starten Sie Ihre lokale Anwendung auf Port 3000
npm run dev

# Teilen Sie sie nur mit Ihrem tailnet — keine öffentliche Exposition
tailscale serve 3000

Dies stellt ein gültiges TLS-Zertifikat für Ihren MagicDNS-Namen bereit; nur authentifizierte Mitglieder des tailnets können darauf zugreifen oder es auflösen.

Öffentliche Freigabe für Webhook-Tests:

# Exponieren Sie denselben Port öffentlich ins Internet
tailscale funnel 3000

# Als dauerhaften Hintergrundprozess laufen lassen
tailscale funnel --bg 3000

# Aktuellen Status prüfen
ntailscale funnel status

# Sofortige Abschaltung der öffentlichen Freigabe bei Bedarf
tailscale funnel 3000 off

Funnel beschränkt Sie auf die Ports 443, 8443 oder 10000 und — Stand jetzt — proxyed nur zu http://127.0.0.1, Sie können also nicht direkt auf eine andere Maschine im LAN zeigen, ohne Tailscale dort ebenfalls laufen zu lassen.

Infrastruktur absichern mit zentralen ACLs

Ein echter Vorteil eines Mesh-Netzwerks gegenüber ad-hoc Entwickler-Tunneln ist die deklarative, zentral verwaltete Policy. Tailscale erzwingt ein funnel-Node-Attribut, bevor ein Gerät öffentlichen Traffic akzeptieren darf:

{
  // Nutzergruppen, verbunden mit Ihrem Enterprise IdP
  "groups": {
    "group:devs": ["alice@company.com", "bob@company.com"],
    "group:secops": ["carol@company.com"]
  },

  "tagOwners": {
    "tag:staging": ["group:secops"]
  },

  "acls": [
    {
      "action": "accept",
      "src": ["group:devs"],
      "dst": ["tag:staging:80,443"]
    },
    {
      "action": "accept",
      "src": ["group:devs"],
      "dst": ["group:devs:*"]
    }
  ],

  // Nur secops-Gruppe darf Funnel auf ihren Nodes aktivieren
  "nodeAttrs": [
    {
      "target": ["group:secops"],
      "attr": ["funnel"]
    }
  ]
}

Standardmäßig fügt Tailscale "target": ["autogroup:member"] für das funnel-Attribut hinzu, was bedeutet, dass jedes tailnet-Mitglied Funnel aktivieren kann, sofern nicht eingeschränkt. Das Sperren auf eine secops- oder platform-Gruppe, wie oben gezeigt, ist die tatsächliche Kontrolle, die verhindert, dass ein beliebiger Entwickler eine Dienst öffentlich exponiert.

Hinweis zur Syntax bei Aktualisierung älterer Richtlinien: Tailscale empfiehlt jetzt grants anstelle klassischer ACLs für neue Konfigurationen. Grants sind eine Erweiterung der ACLs — sie fügen Anwendungsebene-Fähigkeiten (z.B. welche Dateien ein Nutzer auf einem Ziel bearbeiten darf) zu den gleichen Netzwerkregeln hinzu — und ACLs funktionieren weiterhin, erhalten aber keine neuen Features mehr. Das nodeAttrs/funnel-Mechanismus ist davon unberührt.

Performance- und Latenz-Abwägungen

• Interner tailscale serve-Traffic: Wenn NAT-Traversal gelingt, ist dies ein direkter Peer-to-Peer-WireGuard-Pfad — kein Relay dazwischen, und in der Regel die geringste Latenz der drei hier diskutierten Muster.
• tailscale funnel-Traffic: öffentliche Anfragen landen immer zuerst bei einem Funnel-Ingress-Node, reisen dann über das WireGuard-Overlay zu Ihrem Gerät. Tailscale veröffentlicht keine harte Bandbreitenbegrenzung für Funnel; unabhängige Betreiber, die Video- und Dateifreigabe-Workloads darüber laufen lassen, haben in der Praxis keine Limits erreicht, aber Tailscale garantiert keinen Durchsatz wie ein dediziertes CDN oder bezahltes Tunnel-Upgrade.
• ngrok: bei bezahlten Tarifen hängt die Durchsatzrate von Ihrer Region und Ihrem Plan ab; die kostenlosen/Hobbyist-Tarife sind durch monatliche Bandbreitenlimits (1 GB bzw. 5 GB) beschränkt, Stand Mitte 2026.

Eine wirklich neue Option, die es zu kennen lohnt: Tailscale Peer Relays, die seit Februar 2026 allgemein verfügbar sind. Anstatt sich nur auf Tailscale’s geteilte DERP-Server zu verlassen, wenn direkte P2P-Verbindungen scheitern, kann eine Organisation eigene Relay-Knoten betreiben, die Tailscale gegenüber DERP bevorzugt. Dies ist für Hochdurchsatz- oder restriktive Netzwerkumgebungen (symmetric NAT, Cloud-Netzwerke mit eingeschränkter direkter Konnektivität) gedacht und kann in manchen Deployments auch traditionelle Subnetz-Router ersetzen — es ist eine serve/interne Traffic-Optimierung, keine Änderung der öffentlichen Funnel-Routing-Logik.

Was sich 2026 noch geändert hat

Einige Tailscale-Entwicklungen dieses Jahres sind relevant für Teams, die diese Infrastruktur bewerten, auch wenn sie außerhalb des ngrok-Vergleichs liegen:

• Peer Relays (GA, Feb 2026) — oben erwähnt; kundenbetriebene Relays als Hochdurchsatz-Alternative zu geteilten DERP-Servern, inklusive Unterstützung für statische Endpunkte hinter Load Balancern.
• Grants (Policy-Syntax) — die nächste Generation als Ersatz für klassische ACLs, mit Anwendungsebene-Berechtigungen auf Netzwerkregeln. ACLs werden nicht deprecated, aber Tailscale steuert neue Policy-Arbeiten auf Grants zu.
• Aperture by Tailscale — ein KI-Gateway, eingeführt im Februar 2026 und im März als Self-Serve in Alpha, das API-Schlüssel für LLM-Anbieter (OpenAI, Anthropic, Google und andere) hinter Tailscale-Identität zentralisiert, anstatt rohe Schlüssel an Geräte oder Agenten zu verteilen. Es zielt auf das Sichtbarkeitsproblem “Wer ruft welches Modell von wo aus an” ab, das auftritt, wenn KI-Coding-Agenten auf Entwicklermaschinen und CI-Runners laufen. Besonders interessant, wenn Ihr Team bereits über MCP-basierte Agenten und Tunnels nachdenkt.

Keines dieser Features ändert den Kern des Funnel-vs-ngrok-Vergleichs, aber es zeigt, dass Tailscale aktiv die Mesh-Seite dieses Vergleichs ausbaut, anstatt Funnel im Beta-Stadium verharren zu lassen.

Migrationsstrategie, falls Sie das wirklich umsetzen

Phase 1 — Identitäts- und Overlay-Setup Verbinden Sie Ihr IdP, deployen Sie den Tailscale-Client via MDM (Jamf, Kandji, Intune) und aktivieren Sie MagicDNS.

Phase 2 — Interne Zusammenarbeit auf tailscale serve umstellen Ersetzen Sie ad-hoc lokale Freigaben und Screen-Sharing-Demos durch tailnet-interne serve-Links, gesteuert durch Ihre bestehenden IdP-Gruppen.

Phase 3 — Kontrollierter öffentlicher Ingress, nur dort Beschränken Sie das funnel-Node-Attribut auf eine bestimmte Gruppe (platform/secops) und behandeln Sie jeden aktivierten Funnel-Endpunkt als öffentlich zugänglichen Dienst, der noch eigene Authentifizierung braucht — Funnel bietet einen privaten, identitätsgesteuerten Pfad zur Exposition, nicht die Authentifizierung bei der Exposition. Wenn Sie eine pro-Besucher-Authentifizierung auf einem öffentlichen Tunnel-URL benötigen, ist das immer noch eine Frage der Anwendungsebene oder eines Tools wie ngrok’s Traffic Policy.

Fazit

Die zentrale Aussage — dass ad-hoc öffentliche Tunnels eine unkontrollierte Angriffsfläche schaffen — hält stand, und es ist ein echter Grund, warum sicherheitsbewusste Teams heute bewusster Tools wie ngrok einsetzen als vor fünf Jahren. Tailscale Funnel ist eine legitime, identitätsnahe Methode, um einen öffentlichen HTTPS-Endpunkt zu erhalten, ohne Firewall-Ports zu öffnen, und tailscale serve eliminiert tatsächlich viel unnötige öffentliche Exposition bei interner Nutzung.

Aber es lohnt sich, mit klarem Blick zu bewerten: Funnel ist noch immer eine Beta-Funktion, mehr als drei Jahre nach dem Start, bietet keine Per-Request-Authentifizierung und proxyed nur zu Loopback-Adressen. Für Teams, die heute identitätsbewusste öffentliche Endpunkte brauchen, erfüllen ngrok’s Traffic Policy (OAuth/OIDC/SAML am Edge) und Tailscale’s ACL-geschützte Funnel unterschiedliche Fragen — die richtige Wahl hängt davon ab, ob Sie kontrollieren wollen, wer etwas exponiert, oder wer auf das bereits Exponierte zugreifen darf.

---

Weiterführende Literatur

• Tailscale Funnel — offizielle Dokumentation
• Tailscale Serve — offizielle Dokumentation
• Neu: Serve und Funnel (Tailscale Blog, CLI-Optimierung)
• Syntax-Referenz für Tailnet-Policy-Dateien
• Wie NAT-Traversal funktioniert (Tailscale Blog)
• Tailscale Peer Relays GA-Ankündigung
• Aperture by Tailscale — Dokumentation
• ngrok Preisgestaltung und Limits — offizielle Dokumentation
• ngrok Traffic Policy: Authentifizierung hinzufügen

---

Redaktionsänderungen

Korrekturen am Originalentwurf: 1. Funnel-Reifegrad — der Entwurf präsentierte Funnel als eine fertige, stabile Alternative zu ngrok. Tailscale-Dokumentation bezeichnet Funnel weiterhin als “derzeit in Beta” (seit März 2023 unverändert), daher wird dies jetzt explizit erwähnt. 2. NAT-Traversal-Mechanismus — der Entwurf beschrieb Tailscale’s Traversal als “STUN/ICE.” Tailscale nutzt STUN für Adressenerkennung, verwendet aber nicht den ICE/TURN-Standard; es nutzt sein eigenes Protokoll DERP (Designated Encrypted Relay for Packets), das eine TURN-ähnliche Rolle spielt, aber über HTTPS mit WireGuard-Schlüsseln läuft. Korrekt durchgehend. 3. CLI-Syntax — der Entwurf verwendete Vor-1.52-Befehle (tailscale serve https / http://127.0.0.1:3000, tailscale funnel 443 on). Ersetzt durch die aktuelle Ein-Befehls-Syntax (tailscale serve 3000, tailscale funnel 3000, tailscale funnel 3000 off) und fügte die tatsächlichen erlaubten Funnel-Ports (443, 8443, 10000) sowie die Loopback-Proxy-Beschränkung hinzu. 4. Vergleich Identität/Authentifizierung — der Entwurf implizierte, ngrok habe nur “ad-hoc”-Authentifizierung (Basic Auth/OAuth-Token) im Gegensatz zu Tailscale’s Enterprise-IdP-Integration. Tatsächlich unterstützt ngrok’s Traffic Policy OAuth, OIDC und JWT-Validierung am Edge, mit SAML SSO auf Enterprise — und, wichtig, Tailscale Funnel führt keine Per-Request-Authentifizierung bei öffentlichem Traffic durch (ACLs steuern, wer Funnel aktivieren darf, nicht wer ihn nutzt). Vergleich entsprechend angepasst. 5. Preise — aktuelle (Mitte 2026) Zahlen für beide Produkte ergänzt: ngrok Free/Hobbyist (~$8–10/Monat)/Pay-as-you-go ($20/Monat+Nutzung); Tailscale kostenloser Personal-Tarif plus Standard (~$8/Nutzer/Monat) und Premium (~$18/Nutzer/Monat). 6. ACL-Policy-Syntax — das Beispiel mit nodeAttrs bleibt, aber es wird erwähnt, dass Tailscale jetzt die grants-Syntax für neue Policies empfiehlt, da ACLs keine weiteren Features mehr erhalten.

Hinzugefügte Inhalte (nicht im Original): - Tailscale Peer Relays, die seit Februar 2026 allgemein verfügbar sind, als selbstgehostete Alternative zu geteilten DERP-Relays. - Aperture by Tailscale, ein identitätsbasiertes KI-Gateway für LLM/Agenten-Traffic, gestartet Februar 2026, im März als Self-Serve-Alpha. - Explizite Quellenliste für “Weiterführende Literatur”.