Netzwerk · Self-Hosting · Infrastruktur

Homeserver & Reverse Proxy

Sichere Remote-Erreichbarkeit selbst gehosteter Dienste ohne offene Ports am Router. Die Umsetzung erfolgte über einen Tunnel zwischen einem NAS und einem externen Proxyserver.

Kontext Privat / Homelab

Ziel Sichere Remote-Erreichbarkeit ohne Port-Freigabe

Kern-Takeaway Transparente Fehlerbehandlung schlägt stille Automatisierung

Docker frp Linux Shell Reverse Proxy

Ausgangslage & Ziel

Lokale Container-Dienste auf einem NAS, wie etwa Navidrome, sollen von außen erreichbar sein. Um das Heimnetzwerk abzusichern, sollen keine Ports am eigenen Router geöffnet werden. Ziel war der Aufbau eines verschlüsselten Tunnels zu einem gehosteten externen Server, der als SSL-Proxy dient und eingehende Anfragen sicher an das NAS weiterleitet.

Werkzeuge & Recherche

Grundlage für die Umsetzung waren die offizielle Dokumentation von frp, Standard-Linux-Tools zur Netzwerkdiagnose (nc, curl, netstat) sowie gezieltes Troubleshooting mit LLM-Assistenz.

Ein technisches Kernverständnis für Docker-Netzwerke und Linux-Berechtigungskonzepte war zwingend erforderlich, da auf dem externen Proxy-Server keine Root-Rechte zur Verfügung stehen.

Umsetzung & Methodik

Die Einrichtung erfolgte in drei wesentlichen Schritten auf Server- und Clientseite:

Vorbereitung des Remote-Servers: Einrichtung der Subdomains, Zuweisung der SSL-Zertifikate und Freigabe der benötigten Ports für die Kommunikation.
Bereitstellung: Start des frpc-Containers via Docker auf dem NAS. Die Port-Mappings und Subdomain-Informationen wurden in die lokale Konfiguration geschrieben.
Serverseitige Bereitstellung ohne Root-Rechte: Da auf dem Remote Server keine sudo-Rechte vorlagen, wurde der frps-Dienst manuell in einer von der SSH-Sitzung unabhängigen Shell gestartet.

Herausforderungen & Troubleshooting

Fehlersuche nach unangekündigtem Ausfall: Nach einem plötzlichen Tunnel-Abbruch lag der Verdacht zunächst auf den lokalen Docker- und frpc-Updates vom Vortag, da der Hosting-Anbieter keine Störungen meldete. Um ein lokales Container-Problem auszuschliessen, wurde der Client-Container komplett neu aufgesetzt.
Folgefehler bei Neuerstellung (502 Bad Gateway): Beim Neuaufsetzen lief der Container standardmäßig im Docker-Netzwerk bridge und konnte das NAS unter 127.0.0.1 nicht mehr erreichen. Das Umstellen auf den Netzwerkmodus host behob den 502-Fehler umgehend – der Tunnel blieb jedoch weiterhin offline.
Ursachenanalyse & Cronjob-Absicherung: Erst dadurch wurde klar, dass der Fehler serverseitig lag: Der ohne Root-Rechte gestartete frps-Prozess war vom Remote-Host (z. B. durch ein TTY-Session-Cleanup) beendet worden. Da Mangels Root-Rechten kein systemd-Dienst eingerichtet werden konnte, stellt nun ein serverseitiger Crontab-Check das automatische Neustarten sicher.
Bewusstes Beibehalten der Absturz-Konfiguration (loginFailExit): KI-Assistenten rieten dazu, loginFailExit = false zu setzen, damit der Container bei Verbindungsabbruch stumm im Hintergrund weiterläuft. Ich habe mich bewusst dagegen entschieden: Ein durchgehend grüner Container-Status hätte suggeriert, dass der Tunnel intakt ist, was die Fehlersuche fälschlicherweise auf die lokalen Dienste gelenkt hätte. Der Absturz-Loop (Status rot/gelb) liefert stattdessen das sofortige, klare Signal: Die lokalen Apps sind in Ordnung, das Problem liegt rein an der Verbindung zum Host.

Ergebnis & Wirkung

Der frpc-Tunnel läuft stabil und die lokalen Dienste sind zuverlässig über Subdomains erreichbar. Das Setup kommt ohne Systemeingriffe auf dem Hosting-Server aus, fängt serverseitige Abbrüche über Crontab ab und macht Netzwerkprobleme durch die beibehaltene Absturz-Konfiguration direkt im lokalen Dashboard sichtbar.