Selbsthosting für Datensouveränität: Der Open-Source-Shift bei Reverse Proxies und Ingress Tunnels

Einführung: Das Dilemma des Enterprise Ingress

In modernen cloud-nativen Architekturen stehen Entwickler und Betriebsteams häufig vor einer anhaltenden Herausforderung: Wie expose ich intern laufende Dienste, Staging-Umgebungen, Edge-Geräte oder lokale Kubernetes-Cluster sicher gegenüber externen Netzwerken oder Kundenverkehr?

Seit Jahren sind verwaltete Entwickler-Tools wie ngrok zum Standard geworden. Mit einem einfachen CLI-Befehl konnten Ingenieure NAT (Network Address Translation) umgehen, CGNAT (Carrier-Grade NAT) verhandeln und eine öffentliche HTTPS-URL direkt auf einen lokalen Port mappen.

Doch mit wachsendem Scale und reifen cloud-nativen Workloads führt die Abhängigkeit von Drittanbieter-SaaS-Ingress-Tunneln zu architektonischen und regulatorischen Reibungen. Wenn interner Traffic durch einen Drittanbieter-Managed SaaS-Server geleitet wird, sitzt die Infrastruktur des Anbieters direkt im Datenpfad — ein echtes Sicherheitsproblem für Enterprise-Architekten, Compliance-Manager und Infrastruktur-Ingenieure.

Datenschutzrahmenwerke wie GDPR, HIPAA, SOC 2 Typ II, PCI-DSS und die EU-NIS2-Richtlinie bestimmen, wie Organisationen Payload-Daten, Drittanbieter-Exposition und Incident-Response handhaben müssen — obwohl, wie unten erläutert, nicht alle dasselbe regeln. Es ist wichtig, präzise zu wissen, welche Gesetzgebung was regelt, bevor man die Architektur darauf aufbaut.

Die Alternative ist self-hosted Datensouveränität: Kontrolle über Control Plane und Data Plane, um Telemetrie von Drittanbietern zu eliminieren, Zero-Trust-Zugriffskontrolle durchzusetzen und Compliance-Anforderungen direkt zu erfüllen. Dieser Guide stellt vier produktionsreife Optionen vor — frp (Fast Reverse Proxy), zrok (built on OpenZiti), Inlets und den neueren Pangolin — und prüft sie anhand der jeweiligen Dokumentation und Source-Code-Stand August 2026.

1. Der regulatorische und architektonische Druck in Richtung Datensouveränität

Warum SaaS-Ingress-Tunnel die Compliance erschweren

Managed SaaS-Tunnelplattformen agieren als Multi-Tenant-Reverse-Proxy-Systeme. Wenn ein lokaler Agent einen Tunnel zu einer SaaS-Plattform erstellt:

• Traffic-Interception & Entschlüsselung: TLS endet häufig am Edge des SaaS-Anbieters, um Funktionen wie Request-Inspection, Webhook-Logging und Web-Dashboards zu ermöglichen. Das bedeutet, die Infrastruktur des Anbieters hält kurzzeitig entschlüsselte Anwendungsdaten im Speicher.
• Begrenzte Telemetrie- und Audit-Kontrolle: Organisationen können oft nicht vollständig verifizieren, wo Transit-Logs gespeichert werden oder wie lange Request/Response-Bodies auf Infrastruktur verbleiben, die sie nicht betreiben.
• Lieferketten- und Single-Point-of-Failure-Risiko: Ausfälle oder Sicherheitsvorfälle beim SaaS-Anbieter können die Verfügbarkeit und Vertraulichkeit interner Endpunkte beeinträchtigen.

Es ist wichtig zu verstehen, dass dies kein binäres Szenario ist — ngrok bietet beispielsweise Enterprise-Optionen wie “Bring Your Own Cloud” (BYOC) und dedizierte private Editionen, die innerhalb der eigenen Umgebung laufen, genau für diese Art von Bedenken. Selbsthosting bleibt die vollständigere Lösung für Teams, die Control- und Data Plane vollständig unter eigener Kontrolle haben wollen, ohne für eine Enterprise-Edition zu bezahlen. Es ist jedoch nicht der einzige Weg, Drittanbieter-Exposition zu reduzieren.

[ Traditioneller SaaS Tunnelfluss - Souveränitätsrisiko ]
Lokaler Dienst  ---  Lokaler Tunnel-Agent  ---  [ Managed SaaS Cloud ]  ---  Öffentlicher Nutzer / Client
                                                (TLS- termination 
                                                Datenpfad-Exposition)

[ Self-Hosted Tunnelfluss - Vollständige Datensouveränität ]
Lokaler Dienst  ---  Lokaler Tunnel-Agent  ---  [ Enterprise Self-Hosted Gateway ]  ---  Öffentlicher Nutzer / Client
                                                (Vollständige Kontrolle durch SecOps
                                                & Compliance)

Das regulatorische Umfeld richtig einschätzen

Es ist verlockend, GDPR, HIPAA, PCI-DSS, SOC 2 und NIS2 zusammenzufassen als “die Gründe für Datensouveränität”, aber sie erfüllen unterschiedliche Funktionen. Eine Verwechslung erschwert die richtige Kontrolle:

• GDPR regelt direkt wo personenbezogene Daten fließen und gespeichert werden — grenzüberschreitende Transferbeschränkungen und Datenresidenz sind Kernthemen.
• HIPAA betrifft geschützte Gesundheitsinformationen (PHI) im US-Gesundheitswesen — Zugriffskontrollen, Audit-Trails und Schutzmaßnahmen für PHI in Transit und Ruhe.
• PCI-DSS regelt speziell Kartendaten — Netzwerksegmentierung, Verschlüsselung in Transit und Zugriffsbeschränkungen.
• SOC 2 Typ II ist ein Vertrauenswürdigkeitsrahmen, der auf Trust-Service-Kriterien basiert (Sicherheit, Verfügbarkeit, Vertraulichkeit etc.) — es geht um die Wirksamkeit der Kontrollen über die Zeit, inklusive Vendor-Management.
• NIS2 (Richtlinie (EU) ²⁰²²⁄₂₅₅₅) ist eine Cybersecurity-Risiko-Management- und Incident-Reporting-Richtlinie für kritische und wichtige Einrichtungen in der EU — sie fordert Risikomanagement, 24h-Incident-Reporting, Lieferkettensicherheit und Management-Verantwortung. Es ist kein Datenresidenzgesetz wie GDPR, aber die Lieferkettenbestimmungen sind relevant für Third-Party-Exposure.

Der praktische Kern ist: Weniger Drittparteien im Datenpfad bedeuten geringeres Risiko in allen genannten Rahmenwerken — aber bei der Argumentation gegenüber Compliance-Teams sollte man die relevante Gesetzgebung zitieren.

Definition von Datensouveränität in Edge- und Tunneling-Architekturen

Um echte Datensouveränität bei Remote-Access und Service-Exposure zu erreichen, braucht es grundsätzlich:

1. Control-Plane-Isolation — Authentifizierungsrichtlinien, Identitätsanbieter-Integration und Routing-Konfiguration laufen vollständig im eigenen Infrastruktur.
2. Data-Plane-Isolation — Payload-Daten passieren nie eine unkontrollierte Drittpartei, mit Ende-zu-Ende-Verschlüsselung vom Client oder Ingress-Proxy bis zum Backend.
3. Auditierbarkeit & Zero-Trust-Governance — Verbindungsereignisse, Byte-Transfers und Autorisierungsentscheidungen fließen direkt in das eigene SIEM und die Identitätsverwaltung.

2. Technische Bewertungskriterien für eine self-hosted ngrok-Alternative

Bei der Auswahl einer self-hosted ngrok-Alternative sollten folgende Punkte gewichtet werden:

• Protokoll- und Layer-Flexibilität — Layer 7 (HTTP/1.1, HTTP/2, gRPC, WebSockets) sowie Layer 4 (TCP, UDP, Datenbankprotokolle)?
• Zero-Trust-Netzwerkzugriff (ZTNA) — basiert es auf offenen Ports oder läuft es outbound-only mit Identitätsprüfung?
• Kubernetes-native Fähigkeiten — Ingress-Controller-Integration, CRDs, automatisierte Provisionierung?
• Performance & Multiplexing-Overhead — Verbindungspooling, Keep-Alives, Latenz bei hoher Parallelität?
• Lizenzierung & Support — Open Source, source-available oder kommerziell, mit Support SLA?

3. Deep Dive in Self-Hosting-Lösungen

3.1 frp (Fast Reverse Proxy)

frp ist ein ausgereiftes, leistungsstarkes Reverse-Proxy-Tool in Go, gepflegt von fatedier und Mitwirkenden. Es ist konzipiert, um lokale Server hinter NATs und Firewalls sichtbar zu machen. Es ist eines der am weitesten verbreiteten self-hosted Tunneling-Tools in Edge-Computing, IoT-Management und hybriden Enterprise-Umgebungen und ist wirklich open source unter der Apache License 2.0 — dieser Teil stimmt.

                   +----------------------------------+
                   |       Self-Hosted Cloud / VPS    |
                   |                                  |
   Client  =======|   frps (FRP Server)              |
 (Internet)        |   - Hört auf öffentlichen Ports   |
                   |   - TLS / Multiplexing            |
                   +----------------------------------+
                                    ^
                                    | Verschlüsselter Control- &
                                    | Daten-Tunnel (multiplexed)
                                    v
                   +----------------------------------+
                   |       Private Enterprise Netzwerk |
                   |                                  |
                   |   frpc (FRP Client)              |
                   |        |                         |
                   |        v                         |
                   |   Interne App / API / DB         |
                   +----------------------------------+

Architektur. frp nutzt ein Dual-Binary-Modell: frps läuft auf einem öffentlichen Server und übernimmt Port-Mapping sowie Routing; frpc läuft im privaten Netzwerk und initiiert eine outbound Verbindung zu frps, die eine persistente, multiplexed Verbindung aufrechterhält.

Transportoptionen. frp unterstützt mehr Transportschichten als nur TCP — aktuell akzeptiert das transport.protocol-Feld in der Konfiguration tcp, kcp (ein UDP-basiertes Low-Latency-Protokoll), quic, websocket und wss. QUIC ist besonders für hohe Latenz oder verlustreiche Links sinnvoll, da es Streams über UDP multiplexiert, ohne Head-of-Line-Blocking.

Proxy-Typen. frp unterstützt weiterhin:

• TCP / UDP — direkte Layer 4 Exposition für Datenbanken, SSH, eigene Sockets.
• HTTP / HTTPS — Layer 7 Exposition mit Domain-basiertem Virtual Hosting und Header/URL-Rewriting.
• STCP (Secret TCP) — erfordert, dass der Client einen gemeinsamen Schlüssel beweist, bevor der Traffic freigegeben wird, versteckt den Dienst vor Port-Scannern.
• XTCP (P2P TCP) — nutzt STUN-ähnliche Verhandlung für direkte Peer-to-Peer-Verbindungen, um Bandbreiten-intensive Workloads zu beschleunigen.

Neuere Features. frp arbeitet an einem Alpha-Stage VirtualNet-Feature, das einen featureGates = { VirtualNet = true }-Flag nutzt. Es erstellt eine TUN-Schnittstelle und macht IP-Routing zwischen Maschinen möglich, näher an einem Mesh-Netzwerk als an einem klassischen Reverse Proxy. Es erfordert erhöhte (Root/Admin-) Rechte und läuft auf Linux und macOS. Der Entwickler hat öffentlich angekündigt, an einer v2 zu arbeiten, die auf einem Envoy-ähnlichen, hochgradig erweiterbaren L4/L7-Proxy-Kern basiert, aber nicht kompatibel zu v1 ist und sich noch in der frühen Entwicklungsphase befindet — noch keine produktionsreife Architektur.

Konfigurationsbeispiel (aktuelles TOML-Format):

# frps.toml (Server)
bindPort = 7000
vhostHttpsPort = 443

auth.method = "token"
auth.token = "SUPER_SECRET_ENTERPRISE_TOKEN_CHANGE_ME"

webServer.addr = "127.0.0.1"
webServer.port = 7500
webServer.user = "admin"
webServer.password = "STRONG_DASHBOARD_PASSWORD"

transport.tls.force = true

# frpc.toml (Client)
serverAddr = "tunnel-gateway.yourcompany.com"
serverPort = 7000

auth.method = "token"
auth.token = "SUPER_SECRET_ENTERPRISE_TOKEN_CHANGE_ME"

transport.protocol = "quic"   # oder "tcp", "kcp", "websocket", "wss"
transport.tls.enable = true

[[proxies]]
name = "internal-api-service"
type = "https"
customDomains = ["api-staging.yourcompany.com"]

Stärken. Leichtgewichtig, Single-Binary-Laufzeit; keine externen Abhängigkeiten; geringer Ressourcenverbrauch; vielseitiges L4/L7-Routing plus P2P via XTCP; wirklich Apache-2.0 open source mit aktivem Maintainer und regelmäßigem Release-Zyklus.

Trade-offs. Keine integrierte Identitäts-/Zugriffsverwaltung — sichere L7-Routen für OIDC/OAuth2 erfordern weiterhin eine Kombination mit Nginx, Traefik, Caddy oder einem OAuth2-Proxy. Das VirtualNet-Feature ist Alpha und noch nicht produktionsreif.

3.2 zrok (Zero Trust, Built on OpenZiti)

zrok ist ein Open-Source-Projekt, gepflegt von NetFoundry, basiert auf OpenZiti, NetFoundrys Zero-Trust-Overlay-Netzwerk. Sowohl zrok als auch die OpenZiti-Foundation sind wirklich open source unter der Apache License 2.0 — bestätigt durch die Dokumentation von NetFoundry. NetFoundry verkauft separat eine Management-Suite und Enterprise-Support, die bei großem Betrieb helfen, die OpenZiti-Infrastruktur zu steuern, aber die Basis ist lizenzkostenfrei.

                                +---------------------------+
                                |      OpenZiti Fabric      |
                                |   (Self-Hosted Controller |
                                |       Ziti-Router)      |
                                +---------------------------+
                                        /           \
                 Outbound Control      /             \ Outbound Control
                  Data Channel       /               \  Data Channel
                                     v                 v
+-------------------------------+   +----------------------------------+
|   Client Device / Consumer    |   | Private Service Environment      |
|                               |   |                                  |
| zrok access (mTLS Ephemeral)  |===| zrok share (Dark Endpoint)       |
| Kein Inbound-Netzwerkangriff |   | Keine offenen Inbound-Firewall-Ports |
| Oberfläche                   |   | Native Micro-Segmentation        |
+-------------------------------+   +----------------------------------+

Das Modell. zrok eliminiert offene Inbound-Firewall-Ports. Sowohl die Freigabeseite (deine private API oder App) als auch der konsumierende Client etablieren outbound-only, mTLS-gesicherte Verbindungen in die OpenZiti-Infrastruktur — Zugriff erfolgt durch Identität, nicht durch IP oder offene Ports.

Freigabemodi. zrok unterstützt mehrere Backend-Modi, nicht nur HTTP-Proxy: - proxy — Weiterleitung an eine Zieladresse - web — dient ein Verzeichnis als statische Seite - drive — exponiert ein Verzeichnis als virtuelles Netzlaufwerk via WebDAV, mit zrok copy für One-Way-Sync

Self-Hosting, genau beschrieben. Ein produktiver Self-Hosting-Deployment ist kein “ein paar Docker-Container laufen lassen” — die aktuellen Anleitungen führen durch das Setup eines OpenZiti-Controllers und -Routers, dann den zrok-Controller, eine oder mehrere Frontends und eine Metrik-Bridge, unterstützt durch PostgreSQL, RabbitMQ und InfluxDB. Es ist ein echtes Multi-Komponenten-System, was genau die operative Trade-off ist, die die ursprüngliche Lizenzierungstabelle bereits (korrekt) markiert.

Ein Sicherheitsaspekt. Standardmäßig verwenden zrok-Sharing-Ports — öffentlich und privat — den sogenannten “open”-Modus: Jeder Nutzer, der das Share-Token kennt, kann darauf zugreifen. Mit dem --closed-Flag bei zrok share (zusammen mit --access-grant <email>) lässt sich ein privates Share nur für explizit autorisierte Identitäten einschränken. Für Zero-Trust-Ansätze sind --closed-Shares mit Zugriffsrechten die richtige Wahl — der Standard ist permissiver, als es auf den ersten Blick scheint.

CLI-Beispiel, korrigiert. Das ursprüngliche Beispiel war nah dran, verwendete aber ein nicht-repräsentatives Token-Format und ein unnötiges --bind-Flag. Hier eine realistischere Version:

# 1. CLI auf deine self-hosted Instanz zeigen und authentifizieren
zrok login --api-endpoint https://zrok.yourcompany-internal.net <api-token>

# 2. Privates Service-Share, beschränkt auf bestimmte Accounts
zrok share private --headless --closed --access-grant teammate@yourcompany.com 127.0.0.1:9090

# Ausgabe enthält ein Share-Token, z.B.: wr3hpf2z5fiy

# 3. Zugriff auf das private Share von autorisiertem Rechner
zrok access private wr3hpf2z5fiy

Stärken. Wirklich Zero-Open-Port-Modell mit nativer mTLS- und Micro-Segmentation; echtes Apache-2.0-Lizenzmodell; Backend-Modi jenseits HTTP (Dateien, WebDAV); integrierte Share-spezifische Berechtigungsmodi für feinere Zugriffskontrolle.

Trade-offs. Signifikant höhere operative Komplexität als ein Single-Binary-Reverse-Proxy — du betreibst ein verteiltes System (Controller, Router(s), Frontend(s), Message Broker, Metrik-Store), nicht nur einen Relay. Der Standard-Berechtigungsmodus ist permissiver, als es “Zero Trust”-Rahmenwerke implizieren, es sei denn, du schränkst es explizit ein.

3.3 Inlets

Hier war die größte Korrektur notwendig. Inlets Pro ist kein Open Source. Das ursprüngliche, HTTP-only “inlets OSS”-Projekt (v1/v2) war kostenlos und open source, aber das eigene GitHub-Repository beschreibt es jetzt als abgelöst und nicht mehr gepflegt. Das aktiv gewartete Produkt — inlets Pro, entwickelt von Alex Ellis (Gründer von OpenFaaS) — ist eine Closed-Source-Binärdatei, die unter einer kommerziellen Endbenutzer-Lizenzvereinbarung vertrieben wird: Du brauchst einen bezahlten Lizenzschlüssel oder Gumroad-Abonnement, um es zu nutzen, und der Source-Code ist nicht öffentlich. Die umgebende Tooling, inlets-operator (automatisiert Exit-Node-VMs für Kubernetes LoadBalancer-Services) und inletsctl (CLI zum Erstellen von Exit-Servern), sind separate Open-Source-Utilities, aber die Tunnel-Engine, die sie orchestrieren, ist kommerzielle Software, keine “Dual-Lizenz-Open-Source”.

+-------------------------------------------------------------------------+
|                  Öffentliche Cloud-VPS / Edge-Gateway                     |
|                                                                         |
|   +-----------------------------------------------------------------+   |
|   | inlets-pro Exit-Node (Empfängt öffentlichen Traffic)             |   |
|   | Hört auf Ports 80 / 443                                          |   |
|   +-----------------------------------------------------------------+   |
+-------------------------------------------------------------------------+
                                    ^
                                    | Sichere Control- &
                                    | Daten-Tunnel
                                    v
+-------------------------------------------------------------------------+
|                 Private Enterprise Kubernetes Cluster                   |
|                                                                         |
|   +-----------------------------------------------------------------+   |
|   | inlets-operator (automatisiert Exit-Nodes)                        |   |
|   +-----------------------------------------------------------------+   |
|                                   |                                     |
|   +-------------------------------+---------------------------------+   |
|   | inlets-pro Client (Multiplexing des Tunnels)                     |   |
|   +-----------------------------------------------------------------+   |
|                                   |                                     |
|                                   v                                     |
|   +-----------------------------------------------------------------+   |
|   | Ingress-Nginx / Traefik / Envoy Service (ClusterIP)             |   |
|   +-----------------------------------------------------------------+   |
+-------------------------------------------------------------------------+

Was es gut macht. inlets Pro tunnelt Layer-4-TCP-Daten über verschlüsselte WebSockets, was für Kubernetes-Ingress-Controller relevant ist, die rohes TCP für TLS-SNI, mTLS oder cert-manager-Automatisierung benötigen. Der inlets-operator überwacht Service-Objekte vom Typ LoadBalancer, stellt bei fehlendem Cloud-LB eine kleine VM bereit und verbindet den Tunnel automatisch — wirklich nützlich für Bare-Metal, On-Prem oder Edge-Kubernetes.

apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
  annotations:
    dev.inlets.operator/provider: "digitalocean"
    dev.inlets.operator/region: "ams3"
    dev.inlets.operator/plan: "s-1vcpu-1gb"
spec:
  type: LoadBalancer
  ports:
    - name: http
      port: 80
      targetPort: http
    - name: https
      port: 443
      targetPort: https
  selector:
    app.kubernetes.io/name: ingress-nginx

Was seit dem ursprünglichen Entwurf neu ist. Alex Ellis’ Team bietet jetzt auch Inlets Uplink, speziell für SaaS- und Plattform-Teams, die viele kundenseitige Tunnel vom Kubernetes-Control-Plane aus betreiben wollen — zu einem festen monatlichen Control-Plane-Gebühr plus pro-Tunnel-Gebühr, ebenfalls als kommerzielle Lizenz.

Stärken. Für Kubernetes gebaut, mit echtem Layer-4 TCP-Transparenz und cert-manager-Integration; automatisierte Exit-Node-Provisionierung in den wichtigsten Clouds; ein Unternehmen dahinter, das echten Support bietet.

Trade-offs. Es ist kommerzielle Software, die lizenziert werden muss, kein Open-Source-Produkt, das man auditieren, forken oder kostenlos betreiben kann — ein anderes Vertrauens- und Kostenmodell als frp oder zrok. Wenn “keine Drittanbieter-Abhängigkeit” das Ziel ist, sollte man die Beziehung von Inlets zu OpenFaaS Ltd als Exit-Node-Softwareanbieter abwägen, auch wenn der Traffic nie die eigene Infrastruktur verlässt.

3.4 Pangolin — Ein neuer, erwähnenswerter Neuzugang

Da sich die Tunneling-Landschaft seit dem ursprünglichen Entwurf weiterentwickelt hat, lohnt es, eine vierte Option zu nennen: Pangolin, eine self-hosted Tunnel- und Reverse-Proxy-Plattform, gebaut auf WireGuard (über einen benutzerdefinierten Userspace-Client namens Newt) und Traefik, mit integrierter Identitäts- und Zugriffsverwaltung, von Anfang an statt nur angehängt. Es positioniert sich direkt als self-hostable Alternative zu Cloudflare Tunnel und hat schnell an Bedeutung gewonnen — die Entwickler berichten von über 12.600 GitHub-Sternen und 140.000+ Installationen innerhalb von fünf Monaten nach Launch. Es ist Open Source, und das dahinterstehende Unternehmen bietet optional eine verwaltete Cloud-Koordinationsebene für Teams, die automatische Failover ohne Verzicht auf self-hosted Datenfluss wollen.

Wo es im Vergleich zu frp, zrok und Inlets passt. Pangolins Ansatz zielt genau auf die Lücke, die im obigen frp-Abschnitt genannt wurde — ein self-hosted Tunnel mit zentralisiertem SSO, rollenbasierter Zugriffskontrolle, TOTP und Ressourcen-spezifischen Zugriffsregeln out of the box, ohne separate OAuth2-Proxy- oder OpenZiti-Implementierung. Es handelt einige der Zero-Open-Port-Purity von zrok (der zentrale Server muss Verbindungen terminieren und erreichbar sein) auf, bietet aber ein deutlich einfacheres Betriebsmodell als OpenZiti. Im Vergleich zu frp bietet es integrierte Identitätsfeatures, die frp nativ nicht hat.

4. Architektonische Vergleichsmatrix

Fähigkeit	ngrok (SaaS)	frp	zrok (OpenZiti)	Inlets Pro	Pangolin
Datensouveränität	Eingeschränkt standardmäßig; BYOC/dedizierte Edition auf Enterprise-Plänen	Vollständige Kontrolle	Vollständige Kontrolle	Vollständige Kontrolle (Engine ist kommerzielle Software)	Vollständige Kontrolle
Lizenz	Proprietär SaaS	Open Source (Apache 2.0)	Open Source (Apache 2.0)	Kommerziell (Closed Source, Lizenzschlüssel)	Open Source
Netzwerk-Layer-Unterstützung	L4 & L7	L4 (TCP/UDP), L7 (HTTP/S), P2P, experimentell IP-Level VirtualNet	L4 & L7 über Zero-Trust-Fabric; auch Dateien/WebDAV	L4 TCP & L7 HTTP/WebSockets	L4 (WireGuard) & L7 (über Traefik)
Inbound-Firewall-Ports	Keine erforderlich (SaaS)	Erfordert offene Ports auf frps	Keine erforderlich (standardmäßig dark)	Erfordert offene Ports am Exit-Node	Keine erforderlich bei geschützten Ressourcen
Kubernetes-Integration	Custom Ingress Controller	Manuell / Helm	Operator / SDK	Native inlets-operator	Nicht Kubernetes-native
Identitäts-/Zugriffskontrolle	SaaS OAuth / IP-Allowlists	Token-Authentifizierung; benötigt externen IdP für SSO/OIDC	Native mTLS-Identitäten; Ressourcen-spezifische Berechtigungen	Lizenzschlüssel & TLS	Integrierte SSO, RBAC, TOTP
Deployment-Footprint	Cloud SaaS + lokaler Agent	Duale Single-Binary (frps/frpc)	Controller + Router + Frontends + Metrik-Stack	Exit-Node VM + Client	Zentraler Server + Traefik + Newt-Clients

5. Sicherheits-Hardening-Blueprint für self-hosted Ingress Tunnels

Der Einsatz eines self-hosted Gateways verschiebt die Sicherheitssteuerung vollständig in dein internes SecOps-Team. Eine Checkliste für den produktiven Einsatz:

+---------------------------------------------------------------------------------------------------+
|                                PRODUCTION HARDENING CHECKLIST                                     |
+---------------------------------------------------------------------------------------------------+
|  [1] TLS 1.3 Strikte Durchsetzung   -- TLS 1.3 terminieren oder durchreichen; alte Chiffren deaktivieren. |
|  [2] Identity Proxy & OIDC        -- Öffentliche L7-Endpunkte hinter OAuth2-Proxy / Keycloak absichern. |
|  [3] Rate Limiting & DDoS        -- Verbindungs- und Burst-Limits via eBPF/Nginx durchsetzen. |
|  [4] Audit-Telemetrie-Integration  -- JSON-Logs direkt an SIEM schicken (Splunk/Datadog). |
|  [5] Least-Privilege-Segmentierung -- Tunnel-Agent-Prozesse isolieren (Docker, AppArmor, SELinux). |
+---------------------------------------------------------------------------------------------------+

1. OAuth2/OIDC am Gateway durchsetzen. Keine Admin-Panels oder unautorisierte Staging-APIs direkt exponieren. frps oder ein inlets-Exit-Node sollten mit OAuth2-Proxy, Authelia oder Authentik in Verbindung stehen, die dein Enterprise-IdP nutzen. (zrok und Pangolin setzen Identity-Checks näher an die Native-Implementierung — siehe oben.)
2. Blast Radius minimieren. Tunnel-Clients in isolierten Container-Netzwerken oder unprivilegierten Linux-Usern laufen lassen; Kubernetes NetworkPolicy-Objekte nutzen, um kompromittierte Pods vom Scannen anderer Dienste abzuhalten.
3. Zentrale Audit-Logs. Verbindungs- und Lifecycle-Logs (Source IP, TLS-Parameter, Byte-Zähler, Token-IDs) in einen unveränderlichen Log-Store oder SIEM streamen. [ Tunnel-Gateway ] --- [ Syslog / Vector Agent ] --- [ SIEM: Splunk / Elastic / Datadog ]

6. Strategische Empfehlungen

• Lokale Entwicklung, Staging, IoT-Fleets: frp bleibt der schnellste Weg zu einem leichten, kostenlosen, wirklich open-source Tunnel für interne APIs, SSH-Sockets oder Edge-Hardware.
• Strikte Zero-Trust / regulierte Umgebungen, in denen kein inbound Port erlaubt ist: zrok, vorausgesetzt, du konfigurierst --closed Shares bewusst und nutzt die --access-grant-Funktion, und bist bereit, die OpenZiti-Infrastruktur zu betreiben.
• Cloud-native, On-Prem, oder hybride Kubernetes-Ingress: Inlets Pro, mit dem Bewusstsein, dass es sich um kommerzielle Software handelt, nicht um eine Open-Source-Lösung.
• Kleine Teams oder Self-Hoster, die SSO-geschützten Zugriff wollen, ohne OpenZiti oder Kubernetes aufzusetzen: Pangolin ist der neueste und für diesen Anwendungsfall vermutlich die einfachste Option.

Fazit

Der Trend weg von verwalteten SaaS-Ingress-Tunneln ist real, aber die Gründe dafür verdienen die gleiche Sorgfalt wie die Architektur selbst. Nicht alle Compliance-Frameworks sagen, was man oft annimmt, und nicht jede “Open-Source-Alternative” ist wirklich open source — Inlets Pro ist hier das deutlichste Beispiel. frp, zrok und Pangolin sind echte Open Source-Lösungen, die den Datenpfad vollständig unter eigener Kontrolle haben; Inlets Pro kontrolliert den Datenpfad, während der Kern ein bezahltes, Closed-Source-Produkt bleibt. Das Wissen um den Unterschied ist entscheidend für eine präzise Compliance-Argumentation und vermeidet Sicherheits-Review-Probleme.

---

Quellen

• fatedier/frp — GitHub Repository, README, Releases
• frp offizielle Dokumentation (gofrp.org)
• zrok Überblick — NetFoundry Dokumentation
• zrok — Open Source Lizenzseite, NetFoundry Dokumentation
• zrok Self-Hosting Deployment Guide (Linux) — NetFoundry Dokumentation
• zrok Permission Modes — openziti/zrok GitHub Docs
• OpenZiti — Zero Trust Networking, Secured by Identity
• inlets PRO — GitHub Repository und Lizenzbedingungen
• inlets.dev — Produktseite
• Inlets Uplink Preisgestaltung — OpenFaaS Gumroad Listing
• Pangolin — GitHub Repository
• Pangolin — Y Combinator Launch Seite
• NIS2-Richtlinie — Europäische Kommission, Gestaltung Europas digitaler Zukunft
• ngrok BYOC / Private Edition — AWS Marketplace Listing

---

Changelog

Redaktionelle Überarbeitung — 28. August 2026

1. Entfernt die Meta-Beschreibung am Anfang des Entwurfs (nicht Teil des Artikels).
2. frp: Bestätigt Apache 2.0-Lizenz direkt anhand des fatedier/frp Repos (korrekter Upstream — nicht mit unabhängigen Forks verwechseln). Neue unterstützte Transportprotokolle (quic, kcp, websocket, wss) hinzugefügt, die im ursprünglichen Entwurf fehlten. Das Alpha-Feature VirtualNet (TUN-basiert) und Hinweise auf die in Arbeit befindliche, noch nicht kompatible frp v2-Version ergänzt, basierend auf README und Release-Notes.
3. zrok: Bestätigt Apache 2.0-Lizenz für zrok und die OpenZiti-Basis direkt anhand der NetFoundry-Dokumentation. Die vage Beschreibung “Docker Compose oder Kubernetes Charts” durch die tatsächlichen Komponenten ersetzt (Controller, Frontend, Metrik-Bridge, PostgreSQL, RabbitMQ, InfluxDB). Das CLI-Beispiel korrigiert (Token-Format, --closed/--access-grant) und einen Sicherheitsaspekt ergänzt: Standardmäßig sind zrok Shares im “open”-Modus, zugänglich für jeden auf der Instanz, nicht im “zero trust”-Modus.
4. Inlets: Größte Korrektur. Das ursprüngliche Bild beschreibt Inlets Pro fälschlicherweise als open-source. Es ist tatsächlich Closed-Source, kommerzielle Software, die eine Lizenz benötigt. Nur die alte, HTTP-only “inlets OSS”-Version und die Orchestrierungstools (inlets-operator, inletsctl) sind open source. Das Vergleichsbild und die Beschreibung entsprechend angepasst, inklusive der neuen Inlets Uplink-Produkte mit aktuellen Preisen.
5. Regulatorischer Rahmen: Klarstellung, dass GDPR, HIPAA, SOC 2, PCI-DSS und NIS2 unterschiedliche Bereiche regeln. NIS2 ist primär eine Cybersecurity-Richtlinie, kein Datenresidenzgesetz. GDPR ist das Gesetz, das Datenresidenzpflichten vorgibt.
6. ngrok: Ergänzung, dass ngrok BYOC und private Edition auf Enterprise-Plänen anbietet, was die ursprüngliche “SaaS bedeutet keine Kontrolle”-Darstellung relativiert.
7. Neuer Abschnitt 3.4 (Pangolin): Ein schnell wachsender, wirklich open-source self-hosted Tunnel/Reverse-Proxy mit WireGuard + Traefik, integrierter SSO/RBAC, der die Lücke im Vergleich zu frp schließt.
8. Architekturvergleich (Abschnitt 4): Aktualisiert, in Markdown-Tabellenform, inklusive aller genannten Punkte.
9. Strategische Empfehlungen (Abschnitt 6): Aktualisiert, um alle Änderungen widerzuspiegeln.

Die Quellen sind entsprechend aktualisiert und verlinken auf die jeweiligen Dokumentationen und Repositories.