Port-Tunneling

Dieser Artikel beschreibt die Funktion „Port-Tunneling“ des Panels – sie bildet Anwendungsports auf einem Tunnel-Server ohne öffentliche IP auf öffentliche Ports des Panel-Servers ab, damit Nutzer von außen zugreifen können.

In einem Satz verstanden

Dein Server steckt in einem internen Netz (ohne öffentliche IP) und darauf läuft eine Website oder eine Anwendung, die von außen niemand erreicht. Port-Tunneling heißt: „auf dem Panel-Server einen öffentlichen Port öffnen und die Zugriffe von außen über einen verschlüsselten Tunnel auf den Anwendungsport deines internen Servers transportieren“. Ergebnis: Ein Zugriff von außen auf Panel-Server-IP:Port entspricht dem Zugriff auf die Anwendung auf deinem internen Server.

Funktionsbeschreibung

Bei Servern ohne öffentliche IP, die über „Betrieb über Tunnel“ angebunden sind, lassen sich die dort laufenden Anwendungen (etwa Navidrome für Musik, Nextcloud als Cloud-Speicher, Memos für Notizen) von außen nicht erreichen. Das Port-Tunneling bildet diese Anwendungsports auf Ports des Panel-Servers (mit öffentlicher IP) ab, sodass externe Nutzer über „Panel-Server-IP:Port“ zugreifen.

Anwendungsfälle

• Auf einem Tunnel-Server läuft eine Webanwendung, die von außen erreichbar sein soll
• Dienste eines internen Geräts im öffentlichen Netz bereitstellen
• Einer Website, API oder einem Panel auf einem Gerät ohne öffentliche IP einen öffentlichen Zugang geben

Prinzip (wie die Daten fließen)

Externer Nutzer → öffentlicher Port des Panel-Servers (z. B. :9117) → verschlüsselter Tunnel → Anwendungsport des Tunnel-Servers (z. B. :9117)

Der externe Datenverkehr erreicht zuerst den Panel-Server (den einzigen Ort mit öffentlicher IP), wird dann über einen verschlüsselten Reverse-Tunnel zum internen Gerät gebracht und landet schließlich auf dem dort tatsächlich laufenden Anwendungsport.

Einheitlicher Kanal (alle Geräte, keine manuelle Auswahl):

Das Panel nutzt einheitlich den 4433-Reverse-Tunnel; beim Anlegen eines Tunnels muss man sich nicht um den zugrunde liegenden Kanal kümmern und nichts manuell auswählen.

> Ergänzung: Die Systemverwaltung von Android-/Termux-Geräten (Befehlsausführung, Terminal, Dateien) läuft über den stabilen SocketIO-Kanal; das Port-Tunneling dagegen nutzt einheitlich den 4433-Reverse-Tunnel – beide erfüllen ihre eigene Aufgabe und stören sich nicht.

Verwendung

1. Sicherstellen, dass das Zielgerät bereits über „Betrieb über Tunnel“ angebunden ist (Agent online)

2. „Port-Tunneling“ öffnen und auf „Tunnel hinzufügen“ klicken

3. Den Tunnel-Server (Agent) wählen und ausfüllen:

• Lauschender Port: öffentlicher Port des Panel-Servers (für den Zugriff von außen), zum Beispiel 9117
• Ziel-Port: Anwendungsport auf dem Tunnel-Server, zum Beispiel 8080

4. Nach dem Anlegen ist von außen http://Panel-Server-IP:Lauschender-Port erreichbar

Beispiel

Angenommen, die öffentliche IP des Panel-Servers ist 203.0.113.10 und auf einem Raspberry Pi im internen Netz läuft Navidrome (lauscht auf 4533):

• Lauschender Port: 4533
• Ziel-Port: 4533
• Nach dem Anlegen öffnet ein externer Nutzer mit http://203.0.113.10:4533 das Navidrome auf dem Raspberry Pi

Ressourcen-Obergrenzen

Darüber hinausgehende neue Verbindungen werden automatisch abgelehnt, laufende Tunnel sind nicht betroffen.

Zu beachten

1. Cloud-Firewall: Die Cloud-Firewall bzw. die Sicherheitsgruppe des Panel-Servers muss den entsprechenden lauschenden Port freigeben, sonst ist kein Zugriff von außen möglich.

2. Agent-Version: Für die Weiterleitung von Nicht-SSH-Ports (nicht 22) muss auf dem Tunnel-Server ein neuer Agent installiert sein (ältere Versionen unterstützen nur die Weiterleitung von Port 22). Sollen andere Ports weitergeleitet werden, den Agent neu installieren.

3. Agent online: Tunnel hängen davon ab, dass der Agent online bleibt. Ist der Agent offline, wird der Tunnel unterbrochen und nach dem Wiederverbinden automatisch wiederhergestellt.

4. Automatische Wiederherstellung nach Panel-Neustart: Nach einem Neustart des Panel-Dienstes werden Tunnel automatisch wiederhergestellt (ausgelöst beim Wiederverbinden des Agent).

5. Zieldienste auf Android müssen parallel arbeiten können: Ist ein auf Android getunnelter Zieldienst (etwa python3 -m http.server) einthreadig und mit keep-alive aktiviert, blockiert eine nicht geschlossene Verbindung die nachfolgenden Anfragen. Empfehlung: den Zieldienst mehrthreadig betreiben oder sicherstellen, dass Verbindungen zeitnah geschlossen werden.

Verwandte Dokumentation

• Betrieb über Tunnel — zuerst Geräte ohne öffentliche IP an das Panel anbinden
• Port-Weiterleitung — klassische Port-Weiterleitung für Server mit öffentlicher IP (die Unterschiede siehe unten)

Port-Tunneling vs. Port-Weiterleitung (was wählen)

In einem Satz: ohne öffentliche IP Tunnel nutzen, mit öffentlicher IP Weiterleitung.