Netzwerk & Firewall
Die vollständige Allowlist mit Zielen und Ports, Testbefehle für Windows und macOS, Verhalten bei gesperrtem MQTT-Port, Proxy- und TLS-Inspection-Fallen.
Der Client baut ausschließlich ausgehende Verbindungen auf. Es werden keine eingehenden Ports gebraucht, kein VPN und kein Dienst, der lauscht.
Allowlist
| Ziel | Port | Protokoll | Zweck | Pflicht |
|---|---|---|---|---|
cczuytgdfutqqphpayzc.supabase.co |
443 | HTTPS | API, Chat-Stream, Befehle, Scan-Daten, Downloads | ja |
get.supersupport.ai |
443 | HTTPS | Installationsskripte, Download-Weiterleitungen | ja (Installation, Updates) |
mqtt.supersupport.ai |
8883 | MQTT über TLS | Push-Zustellung von Befehlen | nein (Fallback vorhanden) |
app.supersupport.ai |
443 | HTTPS | Admin-Dashboard im Browser | ja (nur für Admins) |
*.supersupport.ai und *.supabase.co sind bequem, aber die Einzelziele oben genügen.
Testbefehle
Windows (PowerShell)
Test-NetConnection cczuytgdfutqqphpayzc.supabase.co -Port 443
Test-NetConnection get.supersupport.ai -Port 443
Test-NetConnection mqtt.supersupport.ai -Port 8883
macOS / Linux
nc -vz cczuytgdfutqqphpayzc.supabase.co 443
nc -vz get.supersupport.ai 443
nc -vz mqtt.supersupport.ai 8883
Zusätzlich prüfen, ob HTTPS wirklich durchgeht, nicht nur der Port offen ist:
curl -sS -o /dev/null -w '%{http_code}\n' https://cczuytgdfutqqphpayzc.supabase.co/rest/v1/
Eine Antwort (auch 401) ist gut: die Verbindung steht. Ein Timeout ist das Problem.
Wenn Port 8883 gesperrt ist
Die App funktioniert weiter. Nach drei fehlgeschlagenen Verbindungsversuchen innerhalb einer Minute wechselt sie automatisch auf Abrufen über HTTPS; sobald der Push-Kanal wieder erreichbar ist, wird zurückgewechselt.
Auswirkung: Befehle kommen mit Verzögerung an statt sofort. Wenn 8883 in eurer Policy nicht durchgeht, ist das eine akzeptable Betriebsart, kein Grund, den Rollout zu verschieben.
Proxy
Der Client nutzt die Proxy-Einstellungen des Betriebssystems.
| Punkt | Hinweis |
|---|---|
| Authentifizierter Proxy | Muss über die Systemkonfiguration funktionieren; die App hat keine eigene Zugangsdaten-Eingabe |
| PAC-Datei | Wird über die Systemauflösung mitverwendet |
| MQTT über Proxy | Wird typischerweise nicht durchgeleitet, dann greift der HTTPS-Fallback |
TLS-Inspection
Häufigste Ursache für „Chat bricht mitten im Satz ab": Ein Inspection-Proxy puffert oder schneidet den laufenden Antwortstrom.
Empfehlung: *.supabase.co von der TLS-Inspection ausnehmen. Ist das nicht möglich, muss
der Proxy Server-Sent-Events ungepuffert durchlassen.
Kein Split-Tunnel nötig
Es gibt keine Anforderung an Standort-VPNs. Der Client funktioniert im Firmennetz, im Homeoffice und im Mobilfunknetz gleich, nur ausgehendes HTTPS wird gebraucht.
Symptome und Ursachen
| Symptom | Wahrscheinliche Ursache |
|---|---|
| Client meldet dauerhaft „Verbinde …" | 443 zum API-Host blockiert |
| Antwort bricht mitten im Satz ab | TLS-Inspection oder puffernder Proxy |
| Befehle kommen verzögert | 8883 blockiert, Fallback aktiv, funktional in Ordnung |
| Installation schlägt fehl, Client startet nicht | get.supersupport.ai blockiert |
| Nur einzelne Geräte betroffen | Standort- oder Subnetz-Policy, nicht die zentrale Regel |
| Downloads brechen ab | Download-Weiterleitung zum Storage auf *.supabase.co blockiert |
Für die Freigabeanfrage an das Netzwerkteam
Ausgehende TLS-Verbindungen von verwalteten Clients:
cczuytgdfutqqphpayzc.supabase.co:443,get.supersupport.ai:443,mqtt.supersupport.ai:8883. Keine eingehenden Regeln. Bitte*.supabase.covon der TLS-Inspection ausnehmen (Server-Sent-Events). Browserzugriff für Administratoren:app.supersupport.ai:443.