Vollständige Datenkontrolle: Selbstgehostete Tunnels mit frp, Zrok und Inlets

Unternehmenssicherheits-Compliance verbietet oft strikt das Routing interner Daten durch Drittanbieter-Server. Für Infrastruktur-Engineers und DevOps-Teams sind das Offenlegen lokaler Dienste, Webhook-Debugging oder der Zugriff auf private Kubernetes-Cluster tägliche Aufgaben. Doch die Nutzung kommerzieller SaaS-Tunnel kann echte Probleme bei Datenhoheit und Compliance verursachen.

Wenn die Sicherheitspolitik Ihrer Organisation vorschreibt, dass kein interner Datenverkehr einen Drittanbieterserver passieren darf, benötigen Sie eine selbstgehostete ngrok-Alternative. Durch den Einsatz leistungsstarker Open-Source-Tools können Teams sichere, private Tunnel aufbauen, ohne Geschwindigkeit zu opfern oder Compliance-Rahmen wie SOC 2, HIPAA oder FedRAMP zu verletzen.

Dieser Artikel behandelt die Datenhoheit bei selbstgehostetem Tunneling und geht dann auf drei Lösungen ein: den Open-Source-Reverse-Proxy frp, das Zero-Trust-Zrok-Netzwerk und die kommerzielle Inlets-Produktfamilie — inklusive der Online-Mythen um die “kostenlosen Open-Source-Inlets”, die inzwischen nicht mehr der Realität entsprechen.

1. Das Datenhoheits-Imperativ in modernen DevOps

Datenhoheit bedeutet, dass digitale Daten den Gesetzen und Governance-Strukturen der Jurisdiktion unterliegen, in der sie gesammelt und verarbeitet werden. Für Reverse-Proxies und Netzwerk-Tunnel heißt das, Kontrolle über die physischen und virtuellen Wege zu behalten, auf denen Ihre Daten reisen.

Das Problem mit SaaS-Tunneln. Kommerzielle Tunneling-Dienste installieren einen leichten Client auf Ihrer Maschine, der eine ausgehende Verbindung zu einem zentralen Relay des Anbieters öffnet. Der Anbieter stellt Ihnen dann eine öffentliche URL bereit, die den Traffic durch seine Infrastruktur leitet und zurück zu Ihrem lokalen Dienst führt. Das ist bequem, bringt aber echte Kompromisse für regulierte Teams:

• Metadaten-Exposition: Auch bei Ende-zu-Ende-Verschlüsselung sind Verbindungsmetadaten (IPs, Timing, Payload-Größen) für den Anbieter sichtbar.
• Compliance-Risiko: Gesundheits-, Finanz- und Regierungssektoren dürfen interne Anwendungsdaten oft nicht durch Multi-Tenant-Drittanbieterinfrastruktur routen.
• Anbietervertrauen: Ihre Pipelines sind von der Verfügbarkeit und den Rate-Limits eines Drittanbieters abhängig.

Selbstgehostete Alternativen kehren das um: Sie besitzen den Client, das Relay und die Verschlüsselungsschlüssel.

2. frp: Der leistungsstarke Open-Source-Reverse-Proxy

frp (Fast Reverse Proxy) ist meist das erste Tool, das Infrastruktur-Teams für eine hochkonfigurierbare, selbstgehostete ngrok-Alternative verwenden. Es ist in Go geschrieben, plattformübergreifend, und besteht aus zwei Komponenten: frps (der Server, auf einem öffentlichen Host Ihrer Kontrolle) und frpc (der Client, im privaten Netzwerk). Das Projekt hat rund 108.000 GitHub-Sterne und wird aktiv weiterentwickelt, die neueste stabile Version (v0.70.0) wurde im Juli 2026 veröffentlicht.

Protokoll- und Transportunterstützung. frp unterstützt TCP, UDP, HTTP und HTTPS standardmäßig, sodass Sie SSH, RDP, MySQL oder rohe TCP-Streams neben Web-Traffic tunneln können. Zwischen frpc und frps können Sie außerdem das Transportprotokoll wählen — Standard TCP, KCP (ein UDP-basiertes Protokoll, das bei Verlusten Resilienz gegen Overhead bietet) oder QUIC (ein modernes, multiplexendes UDP-Protokoll) — was für global verteilte Teams auf instabilen Netzwerken relevant ist.

Eine Konfigurationsanpassung, die es wert ist, hervorgehoben zu werden: frp hat das alte Format frps.ini / frpc.ini verlassen. Seit Version v0.52.0 ist TOML (neben YAML und JSON) das unterstützte Konfigurationsformat, INI ist veraltet, und neue Features sind nur in den neueren Formaten verfügbar. Aktuelle Konfigurationen sehen so aus:

# frpc.toml
serverAddr = "x.x.x.x"
serverPort = 7000

TLS ist standardmäßig aktiviert. Ältere Anleitungen (und der Entwurf, auf dem dieser Artikel basiert) erwähnten meist manuelles Setzen von tls_enable = true. Seit Version v0.50.0 ist transport.tls.enable standardmäßig auf true gesetzt, sodass der frpc-zu-frps-Verkehr out-of-the-box verschlüsselt ist; das Feld ist nur relevant, wenn Sie es explizit deaktivieren oder transport.tls.force = true auf dem Server setzen, um unverschlüsselte Clients abzulehnen.

P2P-Modus (XTCP), genauer gesagt. Die P2P-Fähigkeit von frp ist der Proxy-Typ xtcp, kein separater “Modus.” Es nutzt STUN-basiertes NAT-Hole-Punching, sodass, sobald ein direkter Pfad zwischen zwei Clients besteht, der tatsächliche Datenstrom frps umgeht und nur die initiale Verhandlung durch den Server läuft. Es funktioniert nicht bei jedem NAT-Typ, daher erlaubt frp die Konfiguration eines fallbackTo STCP-Visitors, der einspringt, wenn das Hole-Punching innerhalb eines Timeouts nicht gelingt — ein ehrlicheres Bild als “der Server sieht die Daten nie,” da frps immer noch an der Verbindungsaufnahme beteiligt ist.

Dashboard und API. Das frps-Dashboard erhält kontinuierliche Investitionen: Das Juli-2026-Release hat die API v2-Migration für Dashboards, Proxies, Serverübersicht und Detailansichten erweitert, inklusive paginierter Listen, Proxy-Traffic-Historie, Server-Systeminfos und Proxy-Typ-Filter — nützlich für Audit-Logs in regulierten Umgebungen.

Ein v2-Redesign ist im Gange, langsam. Der Maintainer arbeitet seit einiger Zeit an frp v2, das als modernisierter, Envoy-ähnlicher L4/L7-Proxy-Kern beschrieben wird, der nicht rückwärtskompatibel mit v1 sein wird. Stand Mitte 2026 ist es noch aktiv, aber langsam in Entwicklung — der Maintainer hat im Repo offen über den größeren Umfang als erwartet und fragmentierte Entwicklungszeiten gesprochen. Es gibt kein angekündigtes Veröffentlichungsdatum, planen Sie also noch keine Migrationen in die Produktion.

3. Zrok: Das Zero-Trust-Netzwerk-Overlay

Während frp ein Punkt-zu-Punkt-Reverse-Proxy ist, bewegen sich viele Unternehmensarchitekturen in Richtung Zero Trust Network Access (ZTNA). Hier kommt Zrok ins Spiel.

Auf OpenZiti aufgebaut. Zrok ist eine Open-Source-Plattform für Sharing und Tunneling von NetFoundry, basierend auf OpenZiti, einem Open-Source-Overlay-Netzwerk für Zero Trust. Anstatt Ports nur weiterzuleiten, geht Zrok von keinem impliziten Vertrauen aus: Zugriff basiert auf Identität, nicht IP, und selbst die Relay-Server können den durchgeleiteten Traffic nicht entschlüsseln, da die Verschlüsselung Ende-zu-Ende im OpenZiti-Netzwerk erfolgt.

Sharing-Modi. Zrok unterstützt zwei Hauptmodi:

• Öffentliches Sharing generiert eine HTTPS-URL, auf die jeder zugreifen kann — vergleichbar mit ngrok.
• Privates Sharing erstellt eine tokenbasierte Verbindung zwischen zwei authentifizierten Zrok-Clients, die niemals einen öffentlichen Endpunkt erzeugen. Abhängig vom Backend-Modus können private Shares HTTP proxyen, rohe TCP/UDP-Payloads weiterleiten (tcpTunnel/udpTunnel), einen SOCKS5-Dynamik-Proxy bereitstellen oder sogar einen Host-zu-Host-VPN-ähnlichen Tunnel über das OpenZiti-Overlay aufbauen.

Keine eingehenden Ports, je. Alle Zrok-Verbindungen werden outbound ins Overlay aufgebaut, es sind keine Firewall-Änderungen, Port-Weiterleitungen oder öffentliche IPs erforderlich.

Ein Meilenstein 2026: Härtung. Ab OpenZiti 1.8 können Controller-APIs selbst als OpenZiti-Services gebunden werden — das Management-Plane, das das gesamte Netzwerk steuert, unterliegt nun der gleichen kryptografischen Identitätsprüfung wie die Workloads, was eine Angriffsklasse schließt, die zuvor eine separate Härtung des Steuerkanals erforderte.

Versionshinweis: Die stabile Version ist zrok v1.x (z. B. v1.1.11 Anfang 2026). Eine Next-Generation “zrok2” befindet sich in der frühen Entwicklung und ist noch nicht für den Produktionseinsatz empfohlen — interessant, falls Sie darauf stoßen.

Aufkommender Anwendungsfall: Zero-Trust-Tunnels für KI-Agenten. Eine der spannendsten Entwicklungen 2026 im OpenZiti-Ökosystem sind Community-Projekte, die Zero-Trust-Gateways für KI-Workloads bauen — inklusive MCP (Model Context Protocol)-Gateways, die MCP-Tools mit Per-Client-Isolation und mTLS aggregieren, sowie LLM-Gateways, die Provider mit Identitäts-basiertem Zugriff steuern. Wenn Ihre Infrastruktur KI-Coding-Agenten oder MCP-Server betrifft, ist das ein Bereich, den es zu beobachten gilt.

Selbsthostbar. Sowohl Zrok als auch OpenZiti sind unter Apache 2.0 lizenziert, sodass der voll selbstgehostete Weg — eigener OpenZiti-Controller und Zrok-Instanz — Teams mit Compliance-Anforderungen ohne wiederkehrende Gebühren offensteht, im Gegensatz zum verwalteten Service von NetFoundry zrok.io.

4. Kubernetes-Localhost-Tunneling: Der cloud-native Ansatz

Mit der Containerisierung stellt sich oft die Frage: Wie expose ich einen lokalen Dienst in einem entfernten Kubernetes-Cluster oder sichere den Zugriff auf einen internen Cluster-Dienst für eine lokale Entwicklungsmaschine?

Interne Cluster-Ressourcen (z. B. API im Staging, privates Dashboard) werden meist über Ingress-Controller, LoadBalancer-Services und öffentliche DNS-Einträge exponiert. Für schnelles Debugging greifen Teams oft zu kubectl port-forward, das aber bei längeren Verbindungen oder externem Teilen fragil ist. Hier füllen frp (mit manuellen Kubernetes-Manifests) und speziell entwickelte Tools wie Inlets die Lücke.

5. Inlets vs. frp: Das richtige Tunnel wählen — und eine Korrektur

Beim Vergleich selbstgehosteter Kubernetes-Tunnel-Optionen taucht oft “inlets vs. frp” auf. Beide Tools umgehen NAT und vermeiden SaaS-Abhängigkeit, doch ihre Geschäftsmodelle haben sich stärker auseinanderentwickelt, als ältere Vergleiche erkennen lassen.

Die Korrektur: Das ursprüngliche Open-Source-Projekt “inlets” (kostenlose OSS-Version) wurde eingestellt und erhält keine Updates mehr — der Quellcode bleibt auf GitHub in einem nur-Quellcode, nicht gepflegten Zustand. Es wurde durch inlets Pro ersetzt, das nur kommerziell erhältlich ist. Es gibt keine kostenlose Open-Source-Option mehr für Inlets, wie bei frp oder Zrok. Bei der Bewertung “kostenlos vs. bezahlt” sollte Inlets immer als “bezahlt” eingestuft werden.

Die aktuelle Produktfamilie von Inlets, entwickelt von OpenFaaS Ltd:

• inlets Pro — der Kern-HTTP/TCP-Tunnel-Client und -Server, für Einzelpersonen und kleine Teams.
• Inlets Uplink — eine Kubernetes-native, selbstgehostete Steuerungsebene für SaaS- und Service-Provider, die in Kundenumgebungen (private Datenbanken, interne APIs) zugreifen wollen, ohne ein vollständiges VPN pro Kunde aufzubauen. Es ist ein B2B-Connectivity-Muster, bei dem der Uplink-Client eine ausgehende, TLS- und WebSocket-basierte Verbindung von innen zu einem Server-Endpunkt herstellt, den Sie kontrollieren, und standardmäßig den Datenpfad privat hält.
• Inlets Cloud — eine vollständig verwaltete Lösung.

Verifizierte aktuelle Preise (von inlets.dev/pricing): Personal $25/Monat (5 Tunnel), Commercial $50/Monat (2 Tunnel + $25/Monat für weitere), Uplink $250/Monat pro Kubernetes-Cluster (10 Tunnel + $25/Monat für weitere). Jahresabrechnung bringt Rabatt. Damit sind die Preise aktueller und konkreter als die vage “$25–$50/Monat”-Angaben in älteren Beiträgen.

Kubernetes-Integration. Der inlets-operator nutzt eine Tunnel-Custom-Resource und überwacht Services vom Typ LoadBalancer, um automatisch eine Cloud-VM für den inlets Pro-Server bereitzustellen und dessen öffentliche IP an den Cluster anzuhängen — ein nützliches Muster für Heimlab- oder Bare-Metal-Cluster ohne native Cloud-LoadBalancer.

Wo frp bei Flexibilität und Kosten noch gewinnt. frp hat keinen nativen Kubernetes-Operator, das heißt, das Ausführen von frpc im Cluster erfordert eigene Deployment-, ConfigMap- und Service-Manifestationen. Dafür erhält man einen komplett kostenlosen, protocol-flexiblen Reverse-Proxy — inklusive KCP und QUIC für Netzwerke mit hohem Paketverlust — ohne Lizenzkosten in jeder Größenordnung.

Das Urteil, aktualisiert: Wenn Sie ein unterstütztes, Kubernetes-natives, kommerziell geführtes Produkt mit automatischer Bereitstellung suchen, ist Inlets (jetzt Inlets Pro/Uplink) die einfachere Wahl, zu den oben genannten Preisen. Wenn Sie eine kostenlose, protocol-flexible, voll selbstverwaltete Lösung wollen und bereit sind, eigene Kubernetes-Manifeste zu schreiben, bleibt frp unschlagbar im Preis. Der Unterschied ist: Es ist kein “kostenlos vs. bezahlt”-Vergleich mehr — es ist DIY kostenlos gegen kommerziell verwaltet.

6. Praxisbeispiel: Garantie der Souveränität

Schritt 1: Sicherstellen, dass der Relay-Knoten in einer rechtlich kontrollierten Jurisdiktion sitzt. Ob frps oder ein OpenZiti-Controller für Zrok, das Relay muss in Infrastruktur stehen, die unter Ihrer Organisation rechtlich fällt — z. B. ein europäisches Gesundheits-Tech-Unternehmen, das sein Relay in einer EU-Region hostet, um Datenübertragungen über Grenzen hinweg zu vermeiden.

Schritt 2: End-to-End-Verschlüsselung umsetzen. Bei frp ist TLS zwischen frpc und frps seit Version v0.50.0 standardmäßig aktiviert (transport.tls.enable), und neuere Releases machen es überflüssig, es pro-Proxy zu aktivieren. Bei Zrok ist End-to-End-Verschlüsselung im OpenZiti-Fabric integriert, sodass Daten kryptografisch geschützt sind, sobald sie den Quell-Client verlassen, bis sie das Ziel erreichen — und gemäß OpenZiti 1.8 ist die Steuerungsebene nun ebenso kryptografisch verifiziert.

Schritt 3: Granulare, identitätsbasierte Zugriffssteuerung. Mit Zrok’s privatem Sharing können Teams Zugriff auf eine bestimmte authentifizierte Zrok-Identität gewähren, anstatt einen öffentlichen Link zu teilen. Wenn jemand das Unternehmen verlässt, widerruft das sofort den Zugriff auf alle internen Tunnel, was Zugriffskontrolle an der Identität und nicht an einem Leak-Link bindet.

7. Fazit: Das Netzwerk zurückerobern

Der Komfort kommerzieller Tunnels ist unbestreitbar, doch für Teams mit echten regulatorischen Vorgaben überwiegt die Datenhoheit. Proprietären Code, interne Datenbanken oder unveröffentlichte Produktvorschauen durch die Infrastruktur eines Anbieters zu schicken, ist ein vermeidbares Risiko.

frp bleibt das kostenlose, protocol-flexible Schweizer Taschenmesser für allgemeines Netzwerk-Tunneling, jetzt mit moderner TOML-Konfiguration, standardmäßig aktiviertem TLS und kontinuierlicher Dashboard-Weiterentwicklung. Zrok, auf OpenZiti gebaut, ist die beste Wahl für Zero-Trust, identitätsbasierte Freigabe — öffentlich oder privat — ohne eingehende Ports, und gewinnt zunehmend an Bedeutung bei neuen Zero-Trust-Tunneln für KI-Agenten und MCP-Workloads. Inlets ist eine ernsthafte Option, wenn Sie ein Kubernetes-natives, kommerziell unterstütztes Tunnel suchen und bereit sind, dafür zu bezahlen — aber seien Sie sich bewusst, dass die Ära der “kostenlosen Open-Source-Inlets” vorbei ist; heute sind die Produktlinien Pro/Uplink/Cloud zu den oben genannten Preisen verfügbar.

Die Kontrolle über Ihr Netzwerk zurückzugewinnen bedeutet, den gesamten Lebenszyklus Ihres Traffics zu besitzen — und genau zu wissen, was jedes Tool kostet, in Geld oder in operativem Aufwand.

---

Changelog

Korrekturen und Ergänzungen basierend auf aktuellen Quellen (gofrp.org, github.com/fatedier/frp, github.com/openziti/zrok, inlets.dev, docs.inlets.dev), Juli 2026:

• Entfernt alle SEO/Metadaten-Artefakte und die zusammenhängende Titel-Formatierung aus dem Quellentwurf; in sauberes Markdown mit korrekten Überschriften umgestaltet.
• Korrigiert das frp-Konfigurationsformat: Ersetzt INI-basierte frps.ini/frpc.ini-Beispiele durch das aktuelle TOML-Format; INI ist seit frp v0.52.0 veraltet.
• Korrigiert die TLS-Aussage: transport.tls.enable ist seit frp v0.50.0 standardmäßig auf true gesetzt, nicht mehr manuell tls_enable = true erforderlich.
• Verfeinert die Erklärung zu P2P/XTCP: Klargestellt, dass frps noch an STUN-basiertes Hole-Punching beteiligt ist, auch wenn der Datenverkehr direkt transferiert wird, und dass STCP-Fallback bei NAT-Typen, bei denen das Punching scheitert, existiert.
• Aktualisiert die frp-Version/Release-Details: Bestätigt die neueste stabile Version v0.70.0 (Juli 2026) und die laufende, noch unvollständige v2-Umsetzung.
• Korrigiert die Beschreibung des privaten Shareings bei Zrok: Es ist tokenbasiert zwischen authentifizierten Clients, mit konkreten Backend-Modi (Proxy, tcpTunnel/udpTunnel, socks, vpn) statt einer generischen Beschreibung.
• Hinzugefügt die Härtungs-Details zu OpenZiti 1.8 (2026), die im Originalentwurf nicht enthalten waren.
• Hinzugefügt einen Versionshinweis zu zrok v1.1.11 vs. die in Entwicklung befindliche “zrok2.”.
• Hinzugefügt einen Abschnitt zu Zero-Trust-MCP/LLM-Gateways auf OpenZiti/Zrok — eine echte neue und relevante Entwicklung 2026, die im Originalentwurf nicht behandelt wurde.
• Wesentliche Korrektur im Abschnitt Inlets: Der ursprüngliche Entwurf deutete an, Inlets habe einen kostenlosen Open-Source-Kern mit kostenpflichtigem “Inlets Pro”-Addon. Tatsächlich wurde das OSS-Projekt eingestellt, und Inlets ist nur noch kommerziell (Pro/Uplink/Cloud).
• Ersetzt die vagen Preisangaben “$25–$50/Monat” durch verifizierte aktuelle Zahlen von inlets.dev/pricing: Personal $25/Monat (5 Tunnel), Commercial $50/Monat (2 Tunnel + $25/Monat für weitere), Uplink $250/Monat pro Cluster (10 Tunnel + $25/Monat für weitere).
• Verfeinert die Beschreibung von Inlets Uplink: Es ist ein B2B/SaaS-Pattern (Zugriff auf Kunden-Private-Netzwerke/Services), nicht speziell zum Exponieren eines Kubernetes-Control-Planes.
• Aktualisiert das Fazit, um die korrigierte Einordnung von Free vs. Paid bei allen drei Tools widerzuspiegeln.