IoT-Gateway hinter NAT ohne offene Ports: frp über WebSocket auf 443

Das Problem

Das Gateway steht beim Kunden: hinter dem Router des Providers, oft hinter LTE-CGNAT, in einem Netz, das wir nicht verwalten. Portweiterleitung scheidet aus – dafür braucht man Zugriff auf den Router, und ein offener SSH-Port lädt jeden Bot ein. Ein Site-to-Site-VPN bedeutet Zusatzaufwand beim Kunden, die Installation soll aber Plug-and-Play sein.

Die Richtung umdrehen

Das Gateway baut die Verbindung selbst nach außen auf – wie ein Browser. Wir nutzen frp: frps läuft auf dem Server, frpc auf dem Gateway. Der Client hält eine dauerhafte Verbindung und meldet einen Tunnel an: „Port 20013 auf dem Server → Port 22 bei mir“.

serverAddr = "gw.example.com"
serverPort = 443
transport.protocol = "wss"
auth.token = "…"            # vom Server, nie aus dem Repo

[[proxies]]
name = "PB000000013-ssh"
type = "tcp"
localIP = "127.0.0.1"
localPort = 22
remotePort = 20013

Warum WebSocket auf 443

Viele Firmennetze lassen nur HTTP(S) durch. frp tunnelt den Verkehr in einem WebSocket über TLS – für die Firewall ist das eine normale HTTPS-Verbindung zu unserer Domain. Auf dem Server leitet der Reverse Proxy (bei uns Caddy) den WebSocket-Pfad an frps und alles andere an die Messdaten-API. Eine Domain, ein Port, ein Zertifikat.

Sicherheit

• Tunnel-Ports sind nicht öffentlich. Sie lauschen nur innerhalb des Servers; auf das Gateway kommt man vom Server aus, mit dessen Schlüssel: ssh gateway PB000000013.
• Geheimnisse landen nie auf dem Laptop des Installateurs. Das Setup-Skript nutzt eine einzige SSH-Sitzung, liest den frp-Token direkt vom Server und speichert ihn auf dem Gateway mit Rechten 600.
• Fester Port aus der Gateway-Nummer (PB000000013 → 20013). Ein Konflikt steht sofort im Log: port already used.
• Gleiche Version von frpc und frps – weniger Überraschungen nach Updates.

Was wir davon haben

Fernwartung ohne Vor-Ort-Termin, Updates der Gateway-App, Diagnose (journalctl -u frpc). Vom Kunden brauchen wir nur einen Internetzugang.