Das "No-Root" Enterprise-Compliance-Ansatz: Entwickler-Tunnel in 2026 absichern

Der Entwickler-Tunnel begann als Komfortlösung: eine schnelle Möglichkeit, einen lokalen Dev-Server öffentlich zugänglich zu machen, damit ein Webhook-Anbieter, ein Teamkollege oder ein Kunde ihn erreichen kann. Im Jahr 2026 fällt er klar in den Blickfeld des Sicherheitsteams. Zero-Trust-Programme und engere DevSecOps-Pipelines bedeuten, dass alles, was einen öffentlichen Weg in eine Workstation schafft, die gleiche Frage gestellt bekommt: Wer hat das genehmigt, und was kann es berühren?

Die populäre Antwort lautet “ohne Root ausführen.” Das ist ein guter Instinkt, aber nur die halbe Wahrheit. Einen Tunnel-Agenten als normalen Benutzer laufen zu lassen, reduziert tatsächlich den Schaden, den ein kompromittierter Agent anrichten kann. Es macht den Tunnel an sich nicht automatisch compliant, und wie wir weiter unten sehen, macht genau diese Eigenschaft diese Tools auch für Angreifer attraktiv. Dieser Leitfaden trennt, was rootless tunneling wirklich bringt, welche Tools es unterstützen, und wie ein verteidigungsfähiges Enterprise-Programm aussieht.

Warum Sicherheitsteams Entwickler-Tunnel genau prüfen

Tunnels sind nicht verdächtig, weil sie exotisch sind. Sie sind verdächtig, weil sie gewöhnlich, legitim und verschlüsselt sind.

• MITRE ATTCK katalogisiert Protocol Tunneling (T1572) als Technik zur Verschleierung von Traffic durch Einbettung in ein anderes Protokoll. Es listet auch ngrok als Software, die von Bedrohungsakteuren in mehreren Kampagnen genutzt wurde, unter anderem für laterale Bewegungen und Datenexfiltration.
• Cloudflares kostenloses TryCloudflare-Feature ist wiederholt Ziel von Missbrauch. Proofpoint berichtete 2024, dass Malware-Lieferungen darüber seit 2023 zugenommen haben. Securonix dokumentierte eine Kampagne 2025, bei der Payloads auf Subdomains von trycloudflare.com gehostet wurden. Cofense berichtete im März 2026, dass Vorfälle mit Cloudflare Tunnels und Workers 2025 ihren Höhepunkt erreichten.
• Noch im August 2026 berichteten Incident-Responder bei SpearTip von Beobachtungen, bei denen Angreifer Quick Tunnel-Subdomains nutzten, um Malware zu hosten, Payloads zu stage und Aktivitäten nach einer Kompromittierung zu unterstützen. Ihr Rat: Überwachen Sie ausgehende Verbindungen zu *.trycloudflare.com über DNS, Proxy, Firewall und EDR-Telemetrie.
• Angreifer können auch cloudflared auf einem kompromittierten Rechner nur mit einem Tunnel-Token ausführen, wie GuidePoint dokumentiert, und Erkennungsanbieter liefern mittlerweile Regeln dafür, z.B. Elastics vorgefertigte Potential Protocol Tunneling via Cloudflared-Regel.

Die Erkenntnis für Verteidiger: Ein Entwickler-Tunnel und ein Angreifer-Tunnel können auf der Leitung identisch aussehen. Die Policy muss sie unterscheiden anhand wer es genehmigt hat und wohin es verbindet, nicht anhand des Verhaltens.

Für eine CISO-Perspektive auf dasselbe Thema siehe unseren früheren Beitrag, Warum CISOs ngrok blockieren.

Was “No-Root” wirklich bringt

Ein Reverse-Tunnel ist eine Verbindung, die eine private Maschine nach außen zu einem öffentlichen Relay öffnet, das dann eingehenden Traffic wieder auf derselben Verbindung zurückschickt. Weil die private Maschine niemals eine eingehende Verbindung akzeptiert, funktioniert es hinter einem Heimrouter, einer Firmenfirewall oder Carrier-grade NAT (CGNAT), ohne Ports zu öffnen.

Dieses outbound-only Design ist auch der Grund, warum die meisten Tunnel-Clients keine besonderen Privilegien benötigen:

• Der ngrok-Agent stellt eine outbound TLS-Verbindung über Port 443 her, dem gleichen Port wie normales HTTPS.
• SSH-basierte Dienste wie localhost.run und Pinggy verwenden den bereits auf Ihrem Rechner vorhandenen SSH-Client, es ist also nichts Neues zu installieren oder zu erhöhen.
• bore’s Server akzeptiert standardmäßig nur Ports ab 1024, gemäß Dokumentation.
• Tailscales tsnet-Bibliothek läuft als selbstständiger Knoten innerhalb Ihres Prozesses auf einem User-Space-Netzwerkstack, ohne Root-Privilegien.

Wo erhöhte Privilegien wirklich sichtbar werden, ist an den Rändern: bei der Installation eines Agents als persistenten Systemdienst (z.B. Packetriots Daemon-Dokumentation), oder beim Binden der Anwendung, die Sie exponieren, an einen privilegierten lokalen Port.

Was ein rootless Agent für Sie tut. Wenn die exponierte Anwendung kompromittiert wird, erbt der Angreifer die Berechtigungen des Standard-Benutzerkontos, nicht die eines Administrator-Agents. Das Ausführen des Tunnel-Clients als Root ist fast nie notwendig, daher kostet eine Policy, die das verbietet, Entwickler kaum.

Was es nicht tut. Es sagt Ihnen nicht, ob der Tunnel autorisiert ist, wer ihn erreichen kann oder wohin der Traffic geht. Schlimmer noch: Die Eigenschaften, die rootless Tunnels für Entwickler freundlich machen (keine Installation, keine Admin-Rechte, outbound-only auf einem gängigen Port), sind genau das, was Angreifer ausnutzen. Betrachten Sie “läuft ohne Root” als notwendige Kontrolle, nicht als hinreichende. Die Kontrollen, die wirklich Compliance bringen, sind genehmigte Anbieter, authentifizierter Zugriff, zentrale Inventarisierung und Egress-Überwachung.

Rootless-Optionen 2026

SSH-basierte Dienste

SSH-Remote-Forwarding ist der ursprüngliche Reverse-Tunnel: Sie bitten einen entfernten SSH-Server, auf einem Port zu lauschen und den Traffic durch die Session an einen lokalen Port zurückzuschicken. Weil es den Standard-SSH-Client nutzt, gibt es keine Drittanbieter-Binärdatei, die genehmigt oder erhöht werden muss.

localhost.run bietet den schnellsten Einstieg. Ein Befehl, ohne Installation oder Anmeldung:

ssh -R 80:localhost:8080 nokey@localhost.run

Kostenlose Domains sind immer kostenlos, aber laut kostenloser Tier-Dokumentation sind sie beschränkt und rotieren regelmäßig, daher ungeeignet für Webhook-Tests, die eine stabile URL brauchen. Eine stabile lhr.rocks oder eigene Domain kostet $9 pro Monat bei Jahresabrechnung.

Pinggy ist eine weitere SSH-only-Option, die keine Binärdatei erfordert:

ssh -p 443 -R0:localhost:3000 free.pinggy.io

Laut Hilfe-Seite hat der kostenlose Plan eine 60-Minuten-Tunnel-Timeout, und jeder neue Tunnel erhält eine neue URL. Für eine dauerhafte URL oder eigene Domain ist ein kostenpflichtiger Plan notwendig (Pinggy listet kostenpflichtige Pläne ab 2,50 $/Monat). TCP- und TLS-Tunnel sind kostenlos verfügbar. Ein Compliance-Hinweis: Pinggy liest den Tunnel-Traffic, um sein Web Debugger-Feature zu betreiben.

Eine Warnung für Sicherheitsteams. Beide Dienste können über Port 443 oder Port 22 laufen, und Pinggy dokumentiert explizit Port 443. Das macht sie firewallfreundlich, aber bedeutet auch, dass portbasierte Egress-Regeln sie nicht von normalem HTTPS unterscheiden können. Kontrolle auf Domain- oder SNI-Ebene ist der realistische Hebel.

Selbstgehostete und Open-Source-Tools

Wenn Sie den Traffic nicht durch einen Drittanbieter schicken möchten, ist Self-Hosting eine Möglichkeit, den Außen-Relay aus der Datenpfad zu entfernen.

frp (Fast Reverse Proxy) ist die bekannteste Self-Hosting-Option. Es unterstützt TCP, UDP, HTTP und HTTPS Forwarding plus P2P-Modus, und sein Client und Server können über TCP, QUIC, KCP oder WebSocket kommunizieren. Neuere Versionen haben OIDC-Client-Optionen und detaillierte Prometheus-Metriken pro Proxy. Beachten Sie die Support-Policy: Ab v0.69.0 wird jede Minor-Version nur bis zu neun neueren Minor-Versionen unterstützt, planen Sie also regelmäßige Upgrades.

bore ist die minimalistische Alternative. Das README beschreibt etwa 400 Zeilen sicheren, asynchronen Rust-Codes, verteilt als einzelnes Binary für Client und Server, das nur TCP weiterleitet. Ein Server kann ein gemeinsames Geheimnis verlangen, verifiziert durch HMAC-Challenge-Response bei jeder Verbindung:

bore server --secret my_secret_string
bore local 8000 --to your-bore-host.example.com --secret my_secret_string

Die öffentliche Instanz bore.pub ist praktisch für Demos, aber für alles, was Compliance-relevant ist, betreiben Sie Ihren eigenen Server. Beachten Sie auch, dass bore rohen TCP weiterleitet; wenn Sie TLS benötigen, terminieren Sie es selbst.

zrok, aufgebaut auf dem OpenZiti-Overlay-Netzwerk und entwickelt von NetFoundry, ist Open Source und selbst-hostbar, mit einer kostenlosen gehosteten Instanz bei zrok.io. Es unterstützt sowohl öffentliche Shares (eine HTTPS-URL, die jeder öffnen kann) als auch private Shares (eine tokenbasierte Verbindung, die keinen öffentlichen Endpunkt schafft, zugänglich durch einen anderen zrok-Nutzer mit zrok access private). Bei einer gehosteten Instanz können Operatoren den Traffic für öffentliche Shares sehen, was das Datenschutzmodell von privaten Shares auf Ihrer Infrastruktur unterscheidet. Version 2.0, veröffentlicht im März 2026, ersetzte das alte Reserve/Release-Workflow durch Namespaces und Namen und benannte die CLI in zrok2 um.

Managed Edge-Services

Cloudflare Tunnel. Für schnelle Tests erstellt cloudflared eine öffentliche HTTPS-URL ohne Konto:

cloudflared tunnel --url http://localhost:8080

Lesen Sie aber das Kleingedruckte. Die Dokumentation sagt, diese schnellen Tunnel sind nur für Tests, mit einem Limit von 200 gleichzeitigen Anfragen und ohne Server-Sent Events (SSE). Alles, was geteilt oder langlebig sein soll, sollte einen benannten Tunnel verwenden, der ein Cloudflare-Konto erfordert. Quick Tunnels sind auch das exakte Feature, das die oben genannten Missbrauchsmeldungen beschreibt, weshalb viele Sicherheitsteams sie überwachen.

ngrok. ngrok bleibt der Referenzpunkt. Der kostenlose Plan erlaubt bis zu drei Online-Endpunkten, und der Pay-as-you-go-Plan hat eine Grundgebühr von 20 $/Monat, inklusive 20 $ Nutzungsvolumen. Für Unternehmen listet die Preisseite zentrale Verwaltung (SAML, OpenID Connect, SCIM, RBAC, Audit-Logs) und eine Self-Hosting-Option, die auf Datenresidenz und Compliance abzielt.

Microsoft Dev Tunnels. Für Microsoft-zentrierte Organisationen ist dies eine der wenigen Optionen mit erstklassigen Admin-Kontrollen. Standardmäßig erfordert das Hosting oder Verbinden mit einem Tunnel Authentifizierung mit dem Konto, das es erstellt hat, und anonyme Zugriffe müssen explizit aktiviert werden. Administratoren können Gruppenrichtlinien implementieren, die anonymen Zugriff deaktivieren, Dev Tunnels ganz abschalten oder die Nutzung auf eine Allow-List von Microsoft Entra Tenant-IDs beschränken. Diese Richtlinien gelten für Visual Studio, VS Code Port Forwarding, die Remote - Tunnels Erweiterung und die devtunnel CLI. Microsoft veröffentlicht auch die Domains, die der Dienst nutzt (wie *.devtunnels.ms), sodass Sie ausgehenden Zugriff auf Netzwerkebene erlauben oder verweigern können.

Packetriot Spokes: Ein Managed Server für Teams

Einzelne Entwickler kommen mit SSH-Tricks oder Ein-Binär-Tools aus. Teams, die zentrale Kontrolle brauchen, setzen auf einen Server, den sie selbst verwalten. Ein Beispiel ist Spokes, der Server hinter Packetriot.

Laut Packetriot ist Spokes eine private Instanz desselben Tunneling-Servers, der packetriot.com betreibt, gebaut, um HTTP/S- und TCP-Tunnels für große Teams oder Geräteflotten zu verwalten und zu bedienen. Es skaliert auf Tausende von Tunnels pro Instanz, und der Standard-Client von Packetriot funktioniert ohne Änderungen. Wichtige Details:

• Zugriffsmodell. Administratoren verwalten Nutzer und Tokens, anstatt auf das Packetriot-Konto zu setzen. Spokes enthält einen eingebetteten SOCKSv5-Proxy sowie einen Upstream-Service-Monitor, laut Spokes-Dokumentation. Packetriot unterstützt auch OpenID Connect.
• Endpoint-Policy. Client-lokale Policies erlauben es einem lokalen IT-Admin, zu beschränken, welche Ziele und Ports Tunnel-Regeln anvisieren dürfen. Diese werden über die CLI verwaltet, sodass Remote-Regel-Updates vom Server sie nicht überschreiben können.
• Deployment. Offizieller Docker-Container, Kubernetes-Unterstützung sowie RPM- und DEB-Pakete. SQLite ist die Standard-Datenbank, mit Optionen für MariaDB und Postgres bei größeren Deployments.
• Lizenzierung. Jährlich, nach maximaler Tunnelzahl gestaffelt: $1.000 für 100 Tunnels, $2.000 für 250, $3.500 für 500, individuelle Preise ab 1.000 Tunnels. 30-Tage-Testlizenz verfügbar.
• Herkunft. Spokes wurde vom früheren Packetriot-Server Hubs abgeleitet, und Packetriot migrierte sein Netzwerk 2023 auf Spokes.

Packetriot positioniert die On-Premise-Option als Möglichkeit, die bereits vorhandenen Compliance-Prozesse wiederzuverwenden (es nennt HIPAA, GDPR, SOX und PCI), anstatt einen SaaS-Anbieter in den Datenpfad zu integrieren. Das ist ein architektonisch legitimer Punkt, aber behandeln Sie es als eine Anbieterbehauptung: Das Hosting des eigenen Tunnel-Servers ändert wer im Datenpfad ist, macht eine Organisation aber nicht automatisch compliant.

Kurzübersicht

Tool	Modell	Privilegien	Achtung
localhost.run	SSH zu Relay	Stock SSH-Client	Kostenlose Domains rotieren, sind limitiert
Pinggy	SSH zu Relay	Stock SSH-Client	Kostenlose Tunnels 60 Minuten; liest Traffic für Debugger
Cloudflare Quick Tunnel	Gehosteter Edge, cloudflared	Benutzer-Programm	Nur Test; 200 gleichzeitige Anfragen; kein SSE; Missbrauchsziele
ngrok	Gehosteter Edge (Self-Hosting bei Enterprise)	Outbound TLS auf 443	Kostenlos auf 3 Endpunkte limitiert
Microsoft Dev Tunnels	Gehostet, tenant-abhängig	devtunnel CLI oder IDE	Beste Admin-Kontrollen, Microsoft-Ökosystem
frp	Self-hosted	Client- und Server-Binaries	Eigene Patches; häufige Minor-Releases
bore	Self-hosted	Ein Binary	Nur TCP, kein integriertes TLS
zrok	Gehostet oder self-hosted	Benutzer-Client	v2 CLI umbenannt in zrok2; öffentlich vs. privat in Datenschutz
Packetriot Spokes	Self-hosted oder vendor-managed	Standard-Client	Lizenz nach Tunnelzahl; Vendor-Vertrieb

Tunnel im Anwendungscode integrieren

Ein anderer Ansatz, um die Anzahl der separaten Tunnel-Binärdateien zu reduzieren, ist die direkte Integration des Tunneling in die Anwendung. Es gibt heute mehrere dokumentierte Optionen:

• ngrok Agent SDKs. ngrok veröffentlicht Agent SDKs für Go, JavaScript, Python und Rust, mit denen Sie Endpunkte aus Ihrem eigenen Code erstellen können; eingehende Verbindungen werden behandelt, als hätten Sie eine Socket-Verbindung auf einem lokalen Port geöffnet. Sie empfehlen sie, wenn Sie keinen separaten Agent-Prozess verwalten oder den Agent in Ihre Software einbinden wollen. Das Go SDK ist bei v2 (golang.ngrok.com/ngrok/v2).
• Tailscale tsnet. In Go integriert tsnet einen vollständigen Tailscale-Knoten in Ihren Prozess, ohne Root-Rechte. Es kann auch die App über Tailscale Funnel öffentlich machen, via ListenFunnel, das aktuell TCP auf Ports 443, 8443 und 10000 unterstützt und HTTPS in der Admin-Konsole aktiviert haben muss.
• zrok und OpenZiti SDKs. Die Dokumentation von zrok beschreibt die direkte Integration des Share-Features in Ihren Code durch das Go SDK, sodass eine Anwendung Dienste direkt an die Overlay-Netzwerke binden kann, ohne einen separaten Client.

Hinweis zur Namensgebung: Sie könnten “TunnelAPI 2.0” in Tool-Übersichten sehen. Das ist ein Produkt eines Anbieters für gehostetes Tunneling und API-Gateway, kein Branchenstandard für eingebettetes Tunneling, also nicht als Compliance-Basis behandeln.

Ehrliche Sicherheitsimplikationen. Das Einbetten entfernt eine separat installierte Binärdatei und bindet die Lebensdauer des Tunnels an den Anwendungsprozess, was bei Inventarisierung und Bereinigung helfen kann. Es ändert aber auch wo die Erkennung erfolgen muss. Ein im Anwendungscode erstellter Tunnel erscheint nicht als “ngrok”- oder “cloudflared”-Prozess, also funktionieren Prozessname-Regeln nicht. Netzwerksichtbarkeit (DNS, Proxy-Logs, Ziel-Whitelist) wird zum zuverlässigen Kontrollmittel. Ob Mutual TLS oder andere Authentifizierungsmethoden durchgesetzt werden, hängt vom Produkt und dessen Konfiguration ab, nicht vom Embedding.

Aufbau eines complianten Tunneling-Programms

Der Übergang von ad-hoc Tunneln zu einem gesteuerten Modell funktioniert am besten schrittweise. Entwickler werden eine Blockade umgehen, die keine Alternativen bietet.

1. Inventarisieren Sie bestehende Tunnel. Nutzen Sie EDR, DNS und Proxy-Telemetrie, um Tunnel-Agenten und Domains zu erkennen. Beginnen Sie mit bekannten Zielen (*.trycloudflare.com, ngrok-Domains, *.devtunnels.ms) und bestehenden Erkennungsregeln wie der Elastic-Regel oben. Markieren Sie alles mit erhöhten Privilegien.
2. Schreiben Sie eine akzeptable Nutzungsrichtlinie. Unprivilegiertes Ausführen, Authentifizierung bei jedem exponierten URL, keine anonymen oder dauerhaften öffentlichen Tunnel. Ein Tunnel-URL allein ist kein Zugriffskontrollmittel: Ohne Authentifizierung am Edge kann jeder, der den Link hat, die App erreichen.
3. Bieten Sie genehmigte Alternativen an. Passen Sie das Tool an den Bedarf an. Microsoft-Teams können Dev Tunnels mit Tenant-Beschränkungen durch Gruppenrichtlinien standardisieren. Teams, die zentrale Kontrolle brauchen, können eine Self-Hosting-Lösung wie Packetriot Spokes, frp oder zrok verwenden, oder ein Enterprise-Paket eines Managed Providers. Für gelegentliche Webhook-Tests entscheiden Sie, ob SSH-basierte Dienste erlaubt sind.
4. Durchsetzung auf Netzwerkebene. Da diese Dienste gängige Ports nutzen, fügen Sie Domain- oder SNI-basierte Egress-Kontrollen und Alarme für nicht genehmigte Tunnelziele hinzu. Alles, was erlaubt ist, sollte auf Ziel-Whitelist stehen.
5. Integrieren Sie Identität. Verknüpfen Sie genehmigte Infrastruktur mit Ihrem Identitätsanbieter, damit Tunnel-Erstellung einer Person zugeordnet werden kann. Spokes-Tokens, Dev Tunnels Entra-Beschränkungen, ngrok Enterprise SSO – all das erfüllt diesen Zweck.
6. Standardisieren Sie interne Tools. Wenn Ihr Plattform-Team Tunneling in Frameworks oder CLI integriert, bauen Sie auf genehmigten SDKs auf (ngrok, tsnet, zrok/OpenZiti), damit der genehmigte Weg auch der einfachste ist.

Fazit

“No root” ist die richtige Standardoption für jeden Tunnel-Client und kostet Entwickler kaum. Aber rootless ist der Anfang der Diskussion, nicht das Ende. Die gleichen niedrigen Einstiegshürden, die unprivilegierte Tunnels angenehm machen, sind auch bei Angreifern beliebt. Deshalb kombinieren ausgereifte Programme geringst-Privileg-Execution mit genehmigten Anbietern, authentifiziertem Zugriff, zentraler Inventarisierung und Egress-Überwachung. Wählen Sie Tools, mit denen Sie nachweisen können, wer einen Tunnel geöffnet hat, wohin, und wie lange. Das ist es, was Prüfer wirklich verlangen.

---

Fact-Check-Änderungen (vor Veröffentlichung entfernen)

Jede Aussage im Originalentwurf wurde anhand von Herstellerdokumentationen oder Primärquellen bis zum 29. September 2026 geprüft. Wichtigste Änderungen:

1. “TunnelAPI 2.0” als Standard entfernt und ersetzt. Der Entwurf beschrieb “TunnelAPI 2.0”-Standards für eingebettete Tunnels in Anwendungen, mit mTLS und ephemerem Routing. Solche Standards existieren nicht. TunnelAPI (2.0) ist ein Produkt eines Anbieters für gehostetes Tunneling und API-Gateway, gelistet in den awesome-tunneling Verzeichnissen neben einem 1.0-Tool mit arm CLI. Die Behauptungen zu eingebetteter Bibliothek, mTLS und “keine listening ports” hatten keine Quellen. Der Abschnitt wurde um echte eingebettete Optionen (ngrok Agent SDKs, Tailscale tsnet, zrok/OpenZiti SDKs) neu geschrieben und enthält eine kurze Klarstellung zum Namen.
2. EDR-Narrativ umgekehrt. Der Entwurf behauptete, EDR-Plattformen (CrowdStrike, SentinelOne, Defender) “killen” Tunnel-Agenten mit erhöhten Rechten und dass rootless Tunnels EDR-Konflikte vermeiden. Es gibt keine Quellen für vendor-spezifisches Verhalten, die Belege deuten eher auf das Gegenteil hin: MITRE, Proofpoint, Securonix, Cofense, SpearTip und GuidePoint zeigen, dass Nutzer-Levels-Tunnels (nur Token oder SSH) von Angreifern genutzt werden. Der Text wurde angepasst, um rootless als notwendig, aber nicht ausreichend darzustellen, inklusive Elastics Erkennungsregel.
3. Untersützte Privilegien-Behauptungen entfernt. Aussagen wie “Tools benötigen Root, um Ports <1024 zu binden, Systemzertifikate zu intercepten oder Dienste zu registrieren” wurden ohne Quellen entfernt. Reverse-Tunnel-Clients verbinden outbound und benötigen meist keine Privilegien. Jetzt nur dort beschrieben, wo es dokumentiert ist (Systemdienst, privilegierte Ports).
4. Packetriot Spokes. Deployment-Optionen (Docker, Kubernetes, RPM/DEB), SQLite-Standard, HTTP/S und TCP, “Tausende Tunnels”, und die Aufzählung der Regulierungslisten stimmen mit Packetriot-Enterprise überein. Der Begriff “dominiert den Markt 2026” wurde entfernt (keine Markanteilquelle), ebenso die Aussage zu Audit-Logs, stattdessen auf die Fähigkeit zur Traffic-Überwachung hingewiesen. Die Compliance-Reduktion ist eine Herstellerbehauptung. Preise, 30-Tage-Test, lokale Policies, Token-Management, SOCKS5, OIDC, Hubs-to-Spokes wurden ergänzt.
5. bore. “Unter 1.000 Zeilen” durch “etwa 400 Zeilen” ersetzt, bestätigt durch README. TCP-only, Single-Binary, HMAC-Secret, Ports ab 1024, Warnung vor bore.pub Server.
6. zrok. Korrektur: zrok bietet sowohl öffentliche als auch private Shares. Bei gehosteten Instanzen sichtbar für Operatoren. Version 2.0 (März 2026) umbenannt in zrok2.
7. Cloudflare Tunnel. Schnellbefehl bestätigt. Limits (Test, 200 Anfragen, kein SSE). Named Tunnels benötigen Konto.
8. Pinggy. Befehl, TCP/TLS, 60 Minuten Timeout, Traffic-Lesen, Preise.
9. localhost.run. Befehl, kostenlose Domains, $9/Monat für eigene Domain.
10. frp. Unterstützte Protokolle, OIDC, Support-Policy.
11. Sicherheits-Teams. Statt “blacklist” wird auf Überwachung (SpearTip) und Microsoft-Admin-Kontrollen verwiesen.
12. Neue Abschnitte: MITRE ATT&CK, Microsoft-Gruppenrichtlinien, ngrok-Plan, Vergleichstabelle, Schritte für compliantes Programm.

Unbeachtete / vendor-überprüfungsbedürftige Punkte: - ngrok Free Tier (2h Sessions, zufällige URLs) widerspricht ngrok-Website; keine Aufnahme. - cloudflared-Systemdienst-Installation nicht verifiziert, nur allgemein erwähnt. - Pinggy UDP-Unterstützung nicht erneut geprüft, daher nicht erwähnt.

Hiermit ist die Übersetzung abgeschlossen.