Gateway-Route Backend HTTPS

Seit v1.41.11 honoriert der Home-Gateway-Container den bestehenden Backend HTTPS-Toggle auch für Gateway-Routen. Der Gateway spricht dann auf dem LAN-Hop HTTPS zum Ziel (z.B. DSM auf :5001, Fritzbox- UI auf :443, TR-064-Endpoint) statt plain HTTP.

Warum

Viele LAN-Dienste sind heute HTTPS-only:

• Synology DSM 7 (:5001 — HTTP-Port 5000 oft deaktiviert)
• Fritzbox mit MyFRITZ + eingeschaltetem „Nur HTTPS"
• Unraid / TrueNAS mit erzwungenem HTTPS
• Selbstgehostete Web-UIs hinter Caddy/Traefik im LAN
• Alte Router mit HTTPS-only Admin-Oberfläche

Ohne den Toggle konnte der Gateway-Container diese Dienste nicht erreichen — jeder Request scheiterte mit 400 Bad Request oder ähnlich.

Datenfluss

Browser ──HTTPS──▶ Caddy (VPS)
                     │
                     │ HTTP über WG-Tunnel
                     │ Header: X-Gateway-Target: <lan_host>:<lan_port>
                     │         X-Gateway-Target-Domain: <domain>
                     ▼
              Gateway-Container (Heimnetz)
                     │
                     │ scheme hängt am backend_https-Flag der Route:
                     │   backend_https = false → http://
                     │   backend_https = true  → https:// (rejectUnauthorized off)
                     ▼
                LAN-Target (z.B. 192.168.2.228:5001)

Der erste Hop (Caddy → Gateway) ist immer HTTP, weil er im WG-Tunnel verschlüsselt wird — TLS darauf wäre doppelt verschlüsselt ohne Mehrwert. Der zweite Hop (Gateway → LAN) hingegen verlässt den Tunnel und spricht direkt mit dem LAN-Ziel; dort zählt das Flag.

Aktivieren

1. Route im Admin-UI bearbeiten (oder neu anlegen)
2. Ziel-Typ auf Home Gateway (LAN) setzen
3. LAN-Host + LAN-Port eintragen
4. Den bestehenden Toggle Backend HTTPS aktivieren
5. Speichern

Der Gateway-Container bekommt die Änderung via Config-Sync (POST /api/config-changed vom Server → Gateway pollt sofort). Neue Routes greifen nach ~2 Sekunden.

Selbstsignierte Zertifikate

Der Gateway nutzt rejectUnauthorized: false (via http-proxy option secure: false). Damit akzeptiert er:

• Selbst-signierte Zertifikate (Standard bei DSM, Fritzbox, Pi-hole)
• Abgelaufene Zertifikate
• Hostname-Mismatches (z.B. IP statt Hostname im Request)

Warum ist das ok? Der Hop liegt komplett im Heim-LAN zwischen Gateway-Container und Ziel-Gerät. Die Strecke ist:

• nicht über das öffentliche Internet erreichbar
• bereits von WireGuard zum Gateway hin authentifiziert
• typisch eine Ethernet/WiFi-Verbindung zum Router im selben Raum

TLS-Pinning pro Route wäre UX-Overhead ohne Security-Gewinn.

Falls du's härter willst: Gateway-Ziele auf Fully-Qualified LAN- Domain-Names statt IPs setzen und im LAN einen ACME-Cert per DNS-01 ausstellen lassen (z.B. Caddy im LAN vor dem Target). Dann verifiziert der Gateway wieder sauber. Das geht heute schon, der Toggle bleibt aktiv (Gateway akzeptiert einfach auch valide Certs).

Compat / Hashing

Das Flag wird nur dann in der Config-Sync-JSON mitgeschickt, wenn es true ist:

...(r.backend_https ? { backend_https: true } : {}),

Effekt: Routes ohne das Flag produzieren den exakt identischen config-hash wie vor dem Feature — alte Gateway-Versionen divergieren nicht beim Upgrade des Servers. Nur Routes mit dem Flag aktiviert haben einen neuen Hash-Wert, was automatisch einen Re-Fetch der Config am Gateway auslöst.

Kein CONFIG_HASH_VERSION-Bump nötig.

Relevante Dateien

Server

• src/services/gateways.js — getGatewayConfig() ergänzt das Flag
• src/services/caddyConfig.js — TLS-Transport wird bei Gateway- Routen nie auf den Caddy→Gateway-Hop angewendet
• i18n: src/i18n/{de,en}.json Key routes.backend_https_desc

Gateway

• src/proxy/router.js — speichert backendHttps pro Route
• src/proxy/http.js — wählt http:// vs https:// basierend auf dem Flag, secure:false für self-signed

Tests

• Server: tests/gateways_getConfig.test.js
  • omits backend_https on routes without the flag
  • sends backend_https=true when route targets a HTTPS LAN service
• Gateway: tests/router.test.js
  • carries backend_https flag so LAN target can be HTTPS
  • backendHttps defaults to false when flag absent

Deploy-Reihenfolge

Die Änderungen sind abwärtskompatibel in beiden Richtungen:

• Neuer Server, alter Gateway: Server schickt backend_https=true bei gesetzten Routen. Alter Gateway ignoriert das unbekannte Feld, proxyt plain HTTP → User bekommt 400 wie vorher. Kein Crash.
• Alter Server, neuer Gateway: Server schickt das Feld nicht. Neuer Gateway defaulted auf false → plain HTTP. Identisches Verhalten wie vorher.

Für das volle Feature müssen beide Seiten aktualisiert sein, aber Teil-Upgrades brechen nichts.