Bramka IoT za NAT-em bez otwierania portów: frp przez WebSocket na 443

Problem

Bramka stoi w budynku klienta: za routerem operatora, często za CGNAT-em LTE, w sieci, której nie administrujemy. Przekierowanie portów odpada – wymaga dostępu do routera, a SSH wystawione do internetu to zaproszenie dla botów. VPN site-to-site to dodatkowa konfiguracja po stronie klienta, a instalacja ma być typu „podłącz i działa”.

Odwracamy kierunek połączenia

Bramka sama łączy się na zewnątrz – tak jak przeglądarka. Używamy frp: na serwerze działa frps, na bramce frpc. Klient utrzymuje stałe połączenie i rejestruje tunel: „port 20013 na serwerze → port 22 u mnie”.

serverAddr = "gw.example.com"
serverPort = 443
transport.protocol = "wss"
auth.token = "…"            # z serwera, nigdy z repozytorium

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

Dlaczego WebSocket na 443

Wiele sieci firmowych przepuszcza tylko HTTP(S). frp tuneluje ruch w WebSockecie po TLS, więc dla firewalla to zwykłe połączenie HTTPS do naszej domeny. Na serwerze reverse proxy (u nas Caddy) kieruje ścieżkę WebSocket do frps, a resztę do API odczytów. Jedna domena, jeden port, jeden certyfikat.

Bezpieczeństwo

• Porty tuneli nie są publiczne. Słuchają tylko wewnątrz serwera; do bramki wchodzi się z serwera, jego kluczem: ssh gateway PB000000013.
• Sekrety nie trafiają na laptop instalatora. Skrypt instalacyjny robi jedno połączenie SSH, token frp czyta prosto z serwera i zapisuje go na bramce z prawami 600.
• Stały port z numeru bramki (PB000000013 → 20013). Konflikt widać od razu w logu: port already used.
• Ta sama wersja frpc i frps – mniej niespodzianek po aktualizacji.

Co z tego mamy

Serwis zdalny bez wizyty, aktualizacje aplikacji bramki, diagnostyka (journalctl -u frpc). Po stronie klienta wymagamy tylko dostępu do internetu.