Interne Dienste ohne VPN veröffentlichen

Interne Dienste sicher erreichbar machen - ohne Ports und ohne VPN für alle? WZ-IT baut souveräne Remote-Management-Plattformen mit getunnelten Reverse-Proxys und SSO. Zur Remote-Management-Plattform

Interne Dienste wie Web-Apps, Dashboards und APIs lassen sich sicher veröffentlichen, ohne einen einzigen Inbound-Port zu öffnen oder allen Nutzern ein VPN zu geben. Das Muster dahinter ist immer dasselbe: ein ausgehender (outbound) Tunnel von Ihrem internen Netz zu einem öffentlich erreichbaren, identitätsbewussten Reverse-Proxy. Der Proxy terminiert TLS und prüft jede Anfrage gegen Identität und Policy, bevor sie überhaupt den Dienst erreicht. Statt eine Firewall-Regel pro Dienst zu pflegen, einen Jump-Host zu betreiben oder jedem ein VPN-Profil zu geben, exponieren Sie genau eine Anwendung - identitätsgebunden und clientlos im Browser. Eine ausgereifte quelloffene Umsetzung dieses Musters ist Pangolin, stand Mitte 2026 bei Version 1.19.x.

Inhaltsverzeichnis

• Das Muster: Tunnel, Reverse-Proxy und Auth am Proxy
• Warum kein offener Inbound-Port nötig ist
• Pangolin als self-hosted Cloudflare-Tunnel-Alternative
• Authentifizierung am Proxy und IdP-Anbindung
• Intern oder öffentlich exponieren
• Cloudflare Tunnel, ngrok, frp und Inlets im Vergleich
• Reverse-Proxy-Expose vs. Mesh-VPN: wann was
• Sicherheit, Souveränität und Einsatz bei WZ-IT
• Weiterführende Guides

---

Das Muster: Tunnel, Reverse-Proxy und Auth am Proxy

Das Veröffentlichen ohne VPN besteht aus drei Bausteinen, die zusammenspielen:

• Ausgehender Tunnel: Ein schlanker Agent läuft am Standort oder im VPC, direkt neben dem Dienst. Er baut die Verbindung aktiv nach außen auf - es muss kein Port aus dem Internet erreichbar sein.
• Öffentlicher Reverse-Proxy: Auf einem öffentlich erreichbaren Knoten (typisch ein kleiner VPS) nimmt ein Reverse-Proxy die Requests entgegen, terminiert TLS (automatische Zertifikate) und leitet sie durch den Tunnel an den internen Dienst.
• Authentifizierung am Proxy: Bevor eine Anfrage den Dienst erreicht, erzwingt der Proxy Login und Policy. So wird auch eine Anwendung ohne eigene Benutzerverwaltung identitätsgebunden geschützt.

Der entscheidende Punkt: Die Authentifizierung sitzt vor dem Dienst, nicht im Dienst. Ein internes Dashboard ohne Login bekommt damit ein vorgelagertes SSO, ohne dass Sie den Code anfassen. Genau dafür ist ein identitätsbewusster Reverse-Proxy gedacht.

Warum kein offener Inbound-Port nötig ist

Klassisch würde man einen Dienst veröffentlichen, indem man einen Port in der Firewall freigibt oder ein Port-Forwarding einrichtet. Das exponiert die Anwendung direkt im Internet - inklusive aller ungepatchten Schwachstellen und automatisierten Scans.

Beim getunnelten Reverse-Proxy dreht sich die Richtung um. Der Agent im internen Netz initiiert die Verbindung outbound-only zum Proxy. Eingehende Verbindungen muss nur noch der öffentliche Proxy annehmen, üblicherweise auf Port 443 für HTTPS und UDP 51820 für die WireGuard-Tunnel. Ihr internes Netz hat null offene Inbound-Ports. Selbst wenn ein Angreifer den internen Dienst kennt, gibt es keinen Pfad, der nicht zuerst durch den authentifizierenden Proxy führt. Das ist dieselbe Logik wie beim outbound-only Mesh-VPN, das wir unter Was ist NetBird? beschreiben - nur auf einzelne HTTP-Dienste zugeschnitten.

Pangolin als self-hosted Cloudflare-Tunnel-Alternative

Pangolin vom Anbieter Fossorial setzt dieses Muster vollständig self-hosted um und positioniert sich als quelloffene Alternative zu Cloudflare Tunnel. Die Architektur kombiniert vier Komponenten - Pangolins eigene Bausteine tragen Namen grabender Tiere, dazu kommt der etablierte Reverse-Proxy Traefik:

• Pangolin selbst: zentraler Server mit Dashboard, der Ressourcen, Nutzer und Policies verwaltet.
• Traefik: der eigentliche HTTP-Reverse-Proxy. Er terminiert TLS, holt Let's-Encrypt-Zertifikate und routet Requests.
• Gerbil: der WireGuard-Management-Server auf dem öffentlichen Knoten, der die Tunnel-Peers verwaltet.
• Newt: der user-space WireGuard-Tunnel-Client und TCP/UDP-Proxy, der am Standort läuft und die outbound-Verbindung aufbaut. Da Newt vollständig im User-Space arbeitet (netstack), braucht es weder Root noch ein Kernel-Modul.

Der Pfad einer Anfrage: Browser zu VPS über HTTPS, Traefik terminiert TLS, der Request läuft durch den von Gerbil verwalteten WireGuard-Tunnel zu Newt im internen Netz, und Newt reicht ihn an den Zieldienst weiter. Ein eingebautes Traefik-Plugin namens Badger authentifiziert dabei jede einzelne Anfrage gegen Pangolin.

Zur Lizenz und zum Stand: Pangolin ist mit Version 1.19.4 (26. Juni 2026) aktuell und dual lizenziert - die Community Edition unter AGPL-3, die Enterprise Edition unter der Fossorial Commercial License, die kostenlos für private/Hobby-Nutzung sowie für Unternehmen mit unter 100.000 USD Bruttojahresumsatz ist. Details zum Betrieb in unserer Pangolin-Expertise.

Authentifizierung am Proxy und IdP-Anbindung

Der Mehrwert gegenüber einem nackten Tunnel ist die identitätsgebundene Zugriffskontrolle. Pangolin folgt einem Zero-Trust-Modell: Nutzer erhalten Zugriff auf einzelne Ressourcen, nicht auf das ganze Netz. Pro Ressource lassen sich verschiedene Auth-Methoden erzwingen:

• SSO über die Pangolin-Sitzung mit organisationsweiten Berechtigungen,
• PIN oder Passwort als einfache Hürde vor dem Dienst,
• E-Mail-Whitelist mit OTP: nur freigegebene Adressen erhalten ein Einmalpasswort,
• temporäre, selbstzerstörende Freigabe-Links mit Ablaufzeit,
• dazu Access Tokens und Header-Auth für Maschinen-Zugriff.

Für unternehmensweites SSO bindet Pangolin beliebige OIDC/OAuth2-Identity-Provider an, darunter Authentik, Keycloak und Okta; in Cloud und Enterprise zusätzlich Google und Microsoft Entra ID. Mit Auto-Provisioning werden Nutzer beim ersten Login angelegt und Rollen zugewiesen. So nutzen Sie eine zentrale Identität für alle veröffentlichten Dienste, statt pro Anwendung Konten zu pflegen. Eingebaute Nutzer mit E-Mail/Passwort und 2FA (TOTP, WebAuthn) gibt es als Fallback.

Intern oder öffentlich exponieren

Nicht jeder Dienst soll für die Öffentlichkeit erreichbar sein. Das Muster kennt zwei Stufen:

• Öffentlich, aber authentifiziert: Der Dienst hängt am öffentlichen Proxy und wird per SSO oder einer der Resource-Auth-Methoden geschützt. Ideal für ein Kundenportal, ein Status-Dashboard oder eine API mit Token-Zugriff.
• Intern bzw. privat: Server, Datenbanken oder Admin-Oberflächen, die niemand öffentlich erreichen soll, bindet man über den Pangolin-Client an. Dieser stellt private Ressourcen wie SSH, RDP oder Datenbanken nur für berechtigte Geräte bereit - mit NAT-Traversal, ohne öffentliche Exposition.

So lässt sich pro Dienst entscheiden: clientlos im Browser für Web-Apps, oder client-basiert für Nicht-HTTP-Protokolle. Beides läuft über denselben outbound Tunnel.

Cloudflare Tunnel, ngrok, frp und Inlets im Vergleich

Cloudflare Tunnel ist der bekannteste Vertreter des Musters, aber cloud-gebunden: Ihr Verkehr läuft über die Cloudflare-Edge, Identität über Cloudflare Access. ngrok ist stark für Entwicklung und Demos, als dauerhafte Produktionslösung jedoch SaaS-gebunden. frp ist quelloffen und schnell, bringt aber keine Identitätsschicht mit - Authentifizierung müssen Sie selbst davorsetzen. Inlets ist ein kommerzieller self-hosted Tunnel. Pangolin ist die Option, die outbound Tunnel, Reverse-Proxy und integrierte Identität in einem self-hosted Stack bündelt.

Reverse-Proxy-Expose vs. Mesh-VPN: wann was

Getunnelter Reverse-Proxy und Mesh-VPN lösen verwandte, aber unterschiedliche Probleme:

• Reverse-Proxy-Expose (Pangolin): Sie wollen einzelne Web-Apps, Dashboards oder APIs gezielt bereitstellen - clientlos im Browser, mit SSO am Proxy, oft auch für externe Nutzer ohne installierte Software. Der Zugriff ist HTTP-zentriert und ressourcengranular.
• Mesh-VPN (NetBird): Sie wollen Geräten und Servern vollen Netzzugriff auf beliebige Protokolle geben - SSH, RDP, Datenbanken, interne Tools - so, als säßen sie im lokalen Netz. Das ist die richtige Schicht für Administratoren, CI-Runner oder Standort-zu-Standort-Verbindungen.

In der Praxis kombiniert man beides: Das Mesh-VPN bildet das verschlüsselte Netz-Backend, der getunnelte Reverse-Proxy stellt einzelne Dienste clientlos und identitätsgebunden bereit. Mehr zur clientlosen Variante unter Fernwartung ohne VPN-Client.

Sicherheit, Souveränität und Einsatz bei WZ-IT

Das Muster bringt drei handfeste Sicherheitsvorteile: kein offener Inbound-Port am Standort, identitätsgebundener Zugriff statt netzweiter Freigabe und ein vorgelagertes SSO auch für Anwendungen, die selbst keine Auth können. Betreiben Sie Proxy und Identity Provider self-hosted, bleiben Datenverkehr, Schlüssel und Identitäten in der eigenen Infrastruktur - z. B. auf einem VPS in der EU. Das ist relevant für regulierte Umgebungen und NIS2-konformen Fernzugriff. Dieser Beitrag ist allgemeine Information und keine Rechtsberatung.

Bei WZ-IT kombinieren wir genau diese Bausteine in souveränen Plattformen: ein Mesh-VPN als verschlüsseltes Backend, ein getunnelter Reverse-Proxy für clientlose Web-Zugriffe und ein zentraler Identity Provider wie Authentik für SSO über alle Dienste. Wie das produktiv aussieht, zeigt die Case Study ABCO Water Systems. Konzeption, Aufbau und Betrieb übernehmen wir auf Wunsch komplett im Rahmen unserer Remote-Management-Plattformen.

Weiterführende Guides

• Pangolin-Expertise - getunnelter Reverse-Proxy im Einsatz
• Was ist NetBird? - Mesh-VPN als Netz-Backend
• Fernwartung ohne VPN-Client - clientloser Browser-Zugriff
• Authentik-Expertise - SSO und Identity Provider self-hosted

Interne Dienste ohne Ports und ohne VPN für alle erreichbar machen? Lernen Sie uns kennen oder sehen Sie sich unsere Remote-Management-Plattformen an.