Selbsthosting für Datensouveränität: Der Open-Source-Ansatz im Reverse Proxying

Das unternehmerische Gebot: Warum Managed Tunnels nicht mehr ausreichen

Das Freigeben lokaler Dienste im Internet für Tests, Webhooks oder Remote-Zugriff ist im Software-Development und Infrastrukturmanagement Alltag. Seit Jahren sind SaaS-Anbieter wie ngrok und Cloudflare Tunnel die Standardlösung. Für Enterprise-Infrastruktur-Teams, Compliance-Beauftragte und Sicherheitsteams wird es jedoch zunehmend schwer, den internen Traffic durch einen Drittanbieter-Managed-SaaS-Anbieter unter strengen regulatorischen Vorgaben zu rechtfertigen.

Unternehmen, die unter GDPR, HIPAA, SOC 2 oder FedRAMP operieren, müssen eine Datensouveränitäts-Anforderung erfüllen: Daten sollen den Gesetzen und Governance-Strukturen der Jurisdiktion unterliegen, in der sie erhoben wurden. Wird ein Managed SaaS-Reverse-Proxy genutzt, werden Ihre internen APIs und Webhook-Payloads durch Server eines Drittanbieters geleitet, manchmal in einer anderen rechtlichen Jurisdiktion als Ihre eigene.

Dies hat zu einem Trend hin zu selbstgehosteten, produktionsreifen Tunneling-Tools geführt. Open-Source-Gateways wie frp (Fast Reverse Proxy), Zrok (aufgebaut auf OpenZiti Zero-Trust-Netzwerk) und Inlets für Kubernetes ermöglichen es Infrastruktur-Teams, den Gateway im eigenen Haus zu behalten — nicht nur, um SaaS-Abonnementkosten zu vermeiden, sondern auch, um Kontrolle darüber zu behalten, wo der Traffic endet und wer ihn inspizieren darf.

Dieser Beitrag betrachtet den aktuellen Stand dieser drei Tools, ihren Vergleich und wo die Compliance-Situation wirklich geklärt ist versus noch im Wandel.

---

1. Die Landschaft der Datensouveränität und Compliance

Das Problem mit SaaS-Reverse-Proxies

Tools wie managed ngrok installieren einen leichten Client im privaten Netzwerk, der einen ausgehenden Tunnel zu den Edge-Servern des Anbieters aufbaut. Der Anbieter generiert eine öffentliche URL, und der an diese URL gesendete Traffic wird durch die Infrastruktur des Anbieters zurück in Ihr Netzwerk geleitet. Das ist bequem, bringt aber echte Compliance-Überlegungen mit sich:

• Datenresidenz: Wenn ein Entwickler in Deutschland eine lokale API mit einem Managed-Tunnel testet, dessen Edge-Server in den USA sitzt, braucht dieser grenzüberschreitende Routing eine rechtlich zulässige Transfermechanismus. Es ist wichtig, hier präzise zu sein: Ein transatlantischer Transfer ist nicht automatisch illegal. Das EU–US Data Privacy Framework (DPF), das im Juli 2023 von der Europäischen Kommission verabschiedet wurde, bietet derzeit eine Rechtgrundlage für Transfers an zertifizierte US-Organisationen, überstand den ersten rechtlichen Angriff im EU-Gericht im September 2025. Die Geschichte des DPF ist jedoch geprägt von wiederholten Ungültigkeiten — es ersetzte Safe Harbor (2015 aufgehoben) und Privacy Shield (2020 im Schrems II-Urteil aufgehoben) — und eine weitere Klage liegt beim EuGH, mit Unsicherheiten durch ein US Supreme Court-Urteil im Juni 2026 zur Unabhängigkeit der FTC-Kommissare, das die europäische Datenschutzbehörde (EDPB) als relevant für die Aufsicht des DPF ansieht. Für Compliance-Teams ist diese Historie genau der Grund, warum manche Organisationen die grenzüberschreitende Frage ganz vermeiden und auf einen Rahmen verzichten, der bereits zweimal aufgehoben wurde.
• TLS-Termination am Edge: Bei Design terminieren L7 (HTTP) Managed Proxies TLS am Edge des Anbieters, entschlüsseln den Traffic, um ihn zum richtigen Tunnel zu routen, und verschlüsseln ihn dann wieder. Selbst bei einem vertrauenswürdigen Anbieter bedeutet das, dass ein Dritter die Schlüssel für den Transit-Traffic hält.
• Verfügbarkeitsbindung: Die Nutzung eines SaaS-Tunnel-Anbieters bindet Ihre internen Remote-Zugriffs- und Webhook-Tests an die Verfügbarkeit des Anbieters.
• Metered Pricing bei Skalierung: Nutzer- oder Bandbreiten-basierte SaaS-Preise können bei wachsendem Einsatz teuer werden.

Der “Bring Your Own Infrastructure” (BYOI)-Ansatz

Um die Abhängigkeit von Drittanbietern bei Transfermechanismen zu verringern, hosten manche Organisationen ihren Tunnel-Gateway selbst — auf Infrastruktur, die sie kontrollieren, und unter eigener Audit- und Zugriffskontroll-Regelung. Die drei unten vorgestellten Tools repräsentieren unterschiedliche Ansätze.

---

2. frp (Fast Reverse Proxy): Der Bare-Metal-Arbeitspferd

frp (fatedier/frp auf GitHub) ist ein in Go geschriebenes Reverse-Proxy-Tool zum Exponieren eines lokalen Servers hinter NAT oder Firewall. Es ist eines der am weitesten verbreiteten selbstgehosteten Tunneling-Tools: Mitte 2026 hat das Repository etwa 107.000 GitHub-Sterne, wird von über 180 öffentlichen Abhängigkeitsprojekten genutzt und ist unter Apache-2.0 lizenziert. Die aktuelle stabile Version ist v0.69.1.

Architektur und Datensouveränität

frp besteht aus zwei Komponenten: frps, dem Server, den Sie auf Ihrer Infrastruktur deployen, und frpc, dem Client auf der internen Maschine. Da Sie den Standort von frps wählen, kontrollieren Sie die Jurisdiktion, durch die der Traffic läuft — z.B. eu-central-1 hält den Hop innerhalb deutscher/EU-Grenzen.

Ein wichtiger Punkt für compliance-orientierte Leser: frp’s Transportverschlüsselung zwischen frpc und frps ist seit v0.50.0 standardmäßig TLS, aber Payload-Verschlüsselung und Kompression für einzelne Proxies (transport.useEncryption, transport.useCompression) sind standardmäßig deaktiviert und müssen explizit pro Proxy aktiviert werden. Selbsthosting von frp gibt Ihnen automatisch die Kontrolle über die Jurisdiktion; maximale Verschlüsselung erfordert jedoch Konfiguration.

Relevante Features für Enterprise-Anwendungen

• Protokollunterstützung: TCP, UDP, HTTP, HTTPS, und STCP.
• STCP und XTCP für null öffentliche Exposition: STCP (Secret TCP) erlaubt, einen Dienst bei frps zu registrieren, ohne einen öffentlichen Port zu öffnen — ein autorisierter Client muss einen vorab geteilten Schlüssel präsentieren. XTCP nutzt NAT-Hole-Punching via STUN, um eine direkte Peer-to-Peer-Verbindung zu versuchen, fallback auf STCP bei NAT-Typen, die das nicht unterstützen.
• Verbindungs-Pooling und Multiplexing: frps kann einen Pool vorab etablierter Verbindungen halten, um Latenz bei Anfragen zu reduzieren; TCP-Stream-Multiplexing ist seit v0.10.0 möglich.
• KCP- und QUIC-Transportmodi, ein SSH-Tunnel-Gateway (ab v0.53.0), das Clients erlaubt, via plain ssh -R zu verbinden, ohne frpc laufen zu lassen, sowie eine Alpha-Stage VirtualNet (TUN-basiert) für IP-Routing zwischen Peers.
• Konfigurationsformat: Ab v0.52.0 nutzt frp TOML, YAML oder JSON; das legacy INI-Format ist deprecated.

Hinweis: Die Maintainer arbeiten an einer in-progress, noch nicht veröffentlichten v2-Version — einem Envoy-ähnlichen L4/L7-Proxy-Kern — die in der README als deutlich komplexer als erwartet beschrieben wird, ohne festen Veröffentlichungstermin.

Wann frp wählen

frp eignet sich für Teams, die eine flexible, protokollunabhängige, vollständig selbstgehostete Relay-Lösung wollen und bereit sind, Server- und TLS-Konfiguration selbst zu verwalten. Es ist eine gute Alternative zu klassischen VPNs, wenn gezielter, pro-Service Remote-Zugriff statt vollständiger Netzwerkverbindung gefragt ist.

---

3. Zrok: Zero-Trust-Netzwerke auf Basis von OpenZiti

Zrok wurde von NetFoundry entwickelt und basiert auf OpenZiti, NetFoundrys Open-Source-Zero-Trust-Netzwerk-Overlay. Statt Ports weiterzuleiten, etabliert Zrok eine identitätsbasierte, verschlüsselte Overlay-Verbindung zwischen Endpunkten — im OpenZiti-Modell gibt es keine hörenden Ports im öffentlichen Internet, Zugriff erfolgt durch kryptografische Identität statt IP-Adresse.

Ein bedeutender Versionswechsel: v2.0 / zrok2

Im März 2026 wurde Zrok mit einer bedeutenden Version 2.0 veröffentlicht. Falls Sie ältere Zrok-Tutorials kennen, hat sich die Kommando-Syntax geändert:

• Der Binary heißt jetzt zrok2, nicht mehr zrok. Beide können parallel installiert werden — v2 nutzt sein eigenes Environment-Verzeichnis (~/.zrok2), eigene Umgebungsvariablen (ZROK2_*) und eigene systemd-Einheiten, Upgrades stören also bestehende v1-Installationen nicht.
• Reserviertes Teilen wurde durch ein Namespace/Namensmodell ersetzt. Die alten Befehle zrok reserve, zrok release und zrok share reserved gibt es nicht mehr; zrok2 create share und zrok2 delete share verwalten nun sowohl öffentliche als auch private Shares, mit einem --share-token-Flag bei zrok2 share private für einen persistenten Vanity-Token.
• Ein neuer Befehl zrok2 access dynamicProxy wurde hinzugefügt, der Namenszuordnungen direkt vom Controller erhält, statt den Host-Header zu parsen.

Öffentliche vs. private Shares

Zrok unterstützt zwei Sharing-Modi:

1. Öffentliches Teilen (zrok2 share public <target>) generiert eine öffentliche HTTPS-URL — nützlich für Drittanbieter-Integrationen wie Stripe oder GitHub Webhooks, die einen konventionellen öffentlichen Endpunkt benötigen.
2. Privates Teilen (zrok2 share private <target>) erzeugt einen Share-Token statt einer URL. Ein Kollaborateur oder CI/CD-Pipeline führt zrok2 access private <token> aus, um den Dienst zu erreichen. Es wird kein öffentlicher DNS-Eintrag oder offener Port erstellt, der Traffic wird end-to-end über das OpenZiti-Netzwerk zwischen den Endpunkten übertragen — ein Router, der NAT umgeht, kann den Traffic nicht entschlüsseln, da die Schlüssel nur an den Endpunkten gehalten werden.

Zrok unterstützt auch einen “closed”-Modus (--closed, ab v0.4.26), der einen Share nur auf Umgebungen beschränkt, die vom Ersteller kontrolliert werden, sowie eine --access-grant-Option, um bestimmten zusätzlichen Konten Zugriff zu gewähren.

Gehostet vs. selbstgehostet, und Preisgestaltung

Zrok ist unter Apache-2.0 lizenziert und kann auf Linux, Docker oder Kubernetes selbstgehostet werden, oder als Managed-Service bei zrok.io genutzt werden (aktuell als “zrokNET” bei NetFoundry, mit einer kostenlosen Stufe: 5 GB/Tag, 25 Umgebungen, 50 Share-Backends, 50 Private-Access-Frontends). Selbsthosting hebt Nutzungslimits auf, erfordert aber den eigenen OpenZiti-Controller — ein deutlich höherer operativer Aufwand als das Deployen eines frp-Servers.

Wann Zrok wählen

Zrok passt zu Organisationen, die Zero-Trust, identitätsbasierten Zugriff wollen und private Shares nie ins öffentliche Internet stellen möchten. Da es eine neuere, aktiv weiterentwickelte Codebasis ist, sollten Teams bei einem Neustart oder Upgrade auf die v1→v2-Migration planen.

---

4. Inlets: Das Kubernetes-Tunneling-Produktportfolio

Inlets wurde von Alex Ellis entwickelt, dem Gründer von OpenFaaS. Es richtet sich an Teams, die Dienste aus Clustern ohne öffentliche IP exponieren wollen — Bare-Metal-Kubernetes, Raspberry Pi-Cluster oder Edge-Standorte — durch einen ausgehenden Tunnel vom privaten Cluster zu einem “Exit-Node” in einer öffentlichen Cloud-Region Ihrer Wahl.

Eine Lizenzkorrektur: Inlets ist kein Open-Source-Tunnel

Wichtig: Der inlets-pro Tunnel-Binary ist Closed-Source, kommerzielle Software. Laut FAQ des Projekts sind nur inlets-operator und inletsctl — die Orchestrierungstools, die Exit-Node-VMs provisionieren und den Tunnel konfigurieren — MIT-lizenziert. Das inlets-pro Binary, das den Traffic trägt, benötigt einen kostenpflichtigen Lizenzschlüssel (Personal, Commercial, Enterprise) von OpenFaaS Ltd., unter einer kommerziellen EULA, und läuft nur mit gültigem Schlüssel. Das ursprüngliche, vollständig Open-Source-Projekt inlets (nur HTTP, kein TLS-Automatisierung) existiert noch in der Historie, wird aber durch inlets-pro ersetzt und ist nicht mehr aktiv gepflegt.

Das schränkt die Datensouveränitäts-Debatte nicht grundsätzlich ein — Sie wählen weiterhin, wo der Exit-Node steht, und der Traffic kann Ende-zu-Ende verschlüsselt werden, ohne dass der Anbieter Schlüssel hält — aber es ist näher an ngrok’s kommerzielle Modell als an frp oder Zrok, die vollständig open source sind. Wenn “keine Vendor-Lizenzkosten” eine harte Anforderung sind, erfüllt Inlets das nicht; wenn “selbstgehosteter Exit-Node in eigener Jurisdiktion” gefragt ist, schon.

Datensouveränität und Architektur

Da Sie den Standort des Exit-Node in der Cloud wählen, kontrollieren Sie, wo der Traffic geografisch endet. Inlets unterstützt sowohl L4 (TCP) als auch L7 (HTTP); bei inlets-pro’s L4-Modus erfolgt TLS-termination innerhalb Ihres Clusters (z.B. bei einem internen Ingress-Controller), der Exit-Node relayed verschlüsselte Bytes, die er nicht inspizieren kann.

Der Inlets Operator

inlets-operator, der MIT-lizenzierte Kubernetes-Operator, überwacht Service-Objekte vom Typ LoadBalancer. Bei Erscheinen eines solchen setzt er eine leichte Exit-Node-VM bei einem Cloud-Anbieter Ihrer Wahl (DigitalOcean, Hetzner, AWS etc. via API) auf, konfiguriert den Tunnel und verbindet ihn mit dem internen Pod.

Das aktuelle Produktportfolio (2026)

Inlets hat sich vom ursprünglichen CLI-Tool zu einer kleinen Produktfamilie entwickelt: Inlets Pro (selbstgehostete Tunnels, lizenziert), Inlets Cloud (Managed-Tunnel mit HTTPS/SSH im Abonnement) und Uplink (neuer, Kubernetes-nativer Steuerungsknoten für SaaS-Anbieter, die viele Kundenumgebungen verbinden wollen). Das hier fokussierte Self-Hosting ist mit höherem operativen Aufwand verbunden.

Wann Inlets wählen

Inlets ist eine gute Wahl für Kubernetes-zentrierte Teams, die die operative Einfachheit eines automatisierten Exit-Node-Provisionings wollen und bereit sind, für eine kommerzielle Lizenz zu zahlen. Teams, die vor allem Kosten vermeiden wollen, sind mit frp oder Zrok besser bedient.

---

5. Die neue Front: Zero-Trust-Tunneling für KI-Agenten und MCP-Server

Datensouveränitäts-Tunneling wird zunehmend auf neue Traffic-Kategorien ausgeweitet: KI-Agenten und MCP (Model Context Protocol)-Server, die in interne Tools zurückgreifen. Das ist eine echte Neuerung ab 2026, noch keine etablierte Praxis, aber relevant.

Im März 2026 kündigte NetFoundry eine Erweiterung von OpenZiti zu einem “AI Enclave” an — Zero-Trust-Gateways speziell für Agenten- und LLM-Traffic:

• openziti/mcp-gateway aggregiert und exponiert MCP-Tools über das OpenZiti-Overlay (oder Zrok) statt eines lokal gebundenen stdio-Prozesses oder eines öffentlich hörenden HTTP-Endpunkts. Es erfordert zrok v2.0.x oder höher, was die enge Kopplung der Projekte widerspiegelt.
• Ein begleitender LLM-Gateway bietet einen OpenAI-kompatiblen Proxy mit semantischem Routing (OpenAI, Anthropic, Azure OpenAI, Bedrock, Vertex AI, Ollama etc.), authentifiziert mit derselben OpenZiti-Identität wie der MCP-Zugang — Ziel ist eine einzige Identität, ein Audit-Trail, für Modell- und Tool-Calls.
• ziti-mcp-server, ebenfalls im März 2026 veröffentlicht, ist ein MCP-Server — er exponiert rund 200 Tools, die die OpenZiti Management API abdecken, für MCP-kompatible Clients (Claude Desktop, Cursor etc.), und ermöglicht einem Agent, Identitäten, Dienste und Policies im Ziti-Netzwerk via natürliche Sprache zu verwalten, authentifiziert wie ein menschlicher Operator.

Für Leser, die den AI-Infrastruktur-Ansatz beim Tunneling verfolgen: Das ist das bisher klarste Beispiel, dass Vendoren für Zero-Trust-Tunneling spezielle Infrastruktur für Agenten-Traffic bauen, statt eine allgemeine Tunnel-Lösung umzunutzen. Es ist früh — diese Projekte wurden im selben Monat wie Zrok v2.0 veröffentlicht und entwickeln sich noch — aber ein klares Signal, dass die Zero-Trust-Tunneling-Anbieter Agent-zu-Tool-Konnektivität als eigenständiges Problem sehen, das spezielles Tooling erfordert, nicht nur “Webhook-Tunneling mit Extra-Schritten”.

---

6. Vergleichsmatrix

Feature/Anforderung	frp	Zrok (OpenZiti)	Inlets
Hauptanwendungsfall	Bare-Metal, generisches TCP/UDP-Tunneling	Zero-Trust, identitätsbasiertes öffentliches und privates Teilen	Kubernetes Ingress, Cloud-native L4/L7-Tunneling
Lizenzierung	Vollständig open source (Apache-2.0)	Vollständig open source (Apache-2.0)	Orchestrierungstools (inlets-operator, inletsctl) MIT; inlets-pro Tunnel-Binary geschlossen und kommerziell lizenziert
Sicherheitsmodell	Port-Forwarding; STCP/XTCP mit Pre-Shared-Keys	Zero-Trust-Overlay; E2EE zwischen Endpunkten bei privatem Teilen	Outbound WebSocket-Tunnel; L4-Pass-Through mit interner TLS- termination
Standardverschlüsselung	TLS zwischen frpc/frps seit v0.50.0; Payload-Verschlüsselung optional	End-to-End bei privatem Teilen per Design	Abhängig vom Tunnelmodus; L4-Modus bewahrt interne TLS-termination
Datensouveränität	Hoch — vollständig selbstgehostet, Region Ihrer Wahl	Hoch — selbstgehostet oder gehostet, E2EE bei privatem Teilen	Mittel bis hoch — Standort des Exit-Node, abhängig vom Anbieter
Kubernetes-native	Manuell konfiguriert	Containerisiert, Setup erforderlich	Native Operator mit automatischer Exit-Node-Provisionierung
Öffentliche IP erforderlich	Ja für frps	Nicht erforderlich bei privatem Teilen	Ja für den Exit-Node
Betriebliche Komplexität	Moderat	Höher — benötigt OpenZiti-Controller oder v1→v2-Migration	Niedrig bis moderat — automatisiert via Operator

---

7. Best Practices für eine selbstgehostete Tunneling-Strategie

1. Nicht davon ausgehen, dass Selbsthosting standardmäßig verschlüsselt ist. Wie bei frp zeigt, ist TLS auf Transportebene zwischen Client und Server standardmäßig aktiv, aber Payload-Verschlüsselung für einzelne Proxies oft nicht. Prüfen Sie die Defaults der Tools, statt “Selbsthosting” automatisch mit “maximal verschlüsselt” gleichzusetzen.
2. TLS intern terminieren, wo das Tool es unterstützt. Mit L4/TCP-Passthrough (frp, inlets-pro) und TLS-termination im internen Ingress reduzieren Sie das Risiko, dass der Relay-Server entschlüsselte Daten hält.
3. Relays im für Ihre Compliance-Anforderungen passenden Gebiet platzieren, und dokumentieren Sie warum — diese Dokumentation ist wichtig, falls Regulatoren oder Auditoren nach der Rechtfertigung fragen, insbesondere solange Frameworks wie das DPF noch anhängig sind.
4. Zugriffe regelmäßig auditieren. Bei frp prüfen Sie die allowPorts-Einstellung in der Server-Konfiguration. Bei Zrok die Zugriffsrechte der privaten Shares und rotieren Sie Share-Tokens regelmäßig.
5. Verkehr des Tunnels wie jeden anderen Ingress-Pfad überwachen. Logs in Ihr SIEM einspeisen, Bandbreitenmuster mit Prometheus oder OpenTelemetry verfolgen — Selbsthosting entfernt den Edge eines Vendors, aber der Tunnel ist weiterhin eine Brücke in Ihr privates Netzwerk und sollte entsprechend behandelt werden.

---

Fazit

Der Komfort Managed SaaS-Reverse-Proxies bringt echte Compliance-Herausforderungen für Organisationen mit sich, die strenge Datenschutzregeln einhalten müssen — aber die Situation ist komplexer als “SaaS-Tunnels sind illegal, selbstgehostete Tunnels sicher.” Grenzüberschreitende Transfers können rechtmäßig sein, etwa unter dem DPF, und Selbsthosting bedeutet nicht automatisch, dass der Traffic stärker verschlüsselt ist; beides muss anhand der konkreten Tool-Konfiguration geprüft werden.

Was jedoch sicher ist: frp, Zrok und Inlets geben Infrastruktur-Teams die Kontrolle, wo der Tunnel endet, und bei Zrok sogar, ganz auf einen öffentlichen Endpunkt zu verzichten. Von den dreien sind frp und Zrok wirklich open source ohne Lizenzkosten; Inlets setzt auf eine kommerzielle Lizenz, bietet dafür aber eine automatisierte Kubernetes-Integration mit Support. Welche Lösung passt, hängt ab von Prioritäten: Protokollflexibilität (frp), Zero-Trust-Identitätszugriff (Zrok) oder Kubernetes-native Automatisierung mit Vendor-Support (Inlets).

---

Changelog

Korrekturen: - Entfernung der Annahme, dass Routing durch einen US-basierten SaaS-Tunnel automatisch illegal ist unter GDPR/Schrems II. Ergänzung um den Kontext des EU–US Data Privacy Framework (Juli 2023, bestätigt September 2025, Berufung beim CJEU, erneute Prüfung durch EDPB seit Juni 2026). - Klarstellung, dass nur inlets-operator und inletsctl MIT-lizenziert sind; inlets-pro ist Closed-Source und erfordert eine kostenpflichtige Lizenz. - Aktualisierung der Zrok-Kommandos und Konzepte: Version 2.0 im März 2026, Umbenennung in zrok2, Austausch des reservierten Teilens durch Namespace/Namenssystem, Wegfall von zrok reserve etc. - Klarstellung, dass frp’s TLS auf Transportebene seit v0.50.0 aktiv ist, Payload-Verschlüsselung aber optional bleibt. - Editorial: neutrale, sachliche Beschreibungen statt werblicher Formulierungen.

Neu: - Aktuelle Fakten zu frp: ca. 107k GitHub-Sterne, Apache-2.0, Version v0.69.1 (Juni 2026), Konfigurationsformat seit v0.52.0 von INI auf TOML/YAML/JSON, SSH-Gateway (v0.53.0), Alpha VirtualNet (v0.62.0), in-progress frp v2. - Neuer Abschnitt 5: 2026 Zero-Trust-Infrastruktur für KI-Agenten und MCP-Server: openziti/mcp-gateway, OpenAI-kompatibler LLM-Gateway, ziti-mcp-server (über 200 Tools, Management API), alle von NetFoundry im März 2026 vorgestellt. - Produktlinien-Details bei Inlets: Inlets Cloud (Managed), Uplink (Kubernetes-Steuerung), sowie der Fokus auf self-hosted inlets-pro. - Zrok’s “closed”-Modus (--closed, --access-grant) für eingeschränkten Zugriff. - Lizenz-Row in der Vergleichsmatrix für bessere Übersicht.

Quellen: - github.com/fatedier/frp (README, Releases) - github.com/openziti/zrok (README, CHANGELOG, Releases) - blog.openziti.io (“Introducing zrok v2.0”) - netfoundry.io/docs (zrok-Übersicht, private Shares, v1→v2 Migration) - zrok.io/pricing - inlets.dev (Produktseiten, FAQ) - github.com/inlets/inlets-pro (EULA.md) - github.com/inlets/inlets-operator - prnewswire.com (NetFoundry AI-Enclave-Ankündigung) - github.com/openziti/mcp-gateway - blog.openziti.io (ziti-mcp-server) - Rechtliche Analysen zum EU–US Data Privacy Framework (Recording Law, EuropeanMartech, Skadden, IAPP)