ThinHoc Cloud Services
Portfreigaben
Notwendige Portfreigaben für die Nutzung Cloud-basierter ThinHoc Features
Einige der kollaborativen Features der ThinHoc-Plattform sind auf eine ungehinderte Verbindung zu unseren Servern angewiesen, um korrekt funktionieren zu können. Darunter fallen beispielsweise alle Dienste, die über share.thinhoc.com erreichbar sind (Screen Mirroring, Whiteboard) oder auch bestimmte Managementfunktionen wie die Fernsteuerung per Remoteverbindung aus der Geräteansicht von config.thinhoc.com.
Obwohl wir es uns zum Ziel gesetzt haben, unter den meisten Umständen mit möglichst wenigen explizit notwendigen Freigaben und nur mit häufig verwendeten und standardisierten Protokollen auszukommen, ist die manuelle Erstellung von Ausnahmeregeln in manchen Fällen unvermeidlich. Je nach Ihrer spezifischen Netzwerkinfrastruktur kann dies beispielsweise Ihre Firewall, Web-Proxies oder VLAN-Segmentierung betreffen. Im Zweifelsfall sprechen Sie Ihren IT-Administrator sowie den ThinHoc Support an, und wir werden gemeinsam eine Lösung finden.
Notwendige Portfreigaben und Proxy-Einstellungen
Eingehend
Es werden keine expliziten eingehenden Portfreigaben benötigt. Sämtliche Serververbindungen werden von lokalen ThinHoc OS-Maschinen nach außen hin aufgebaut. Die meisten Firewalls lassen eingehenden Traffic auf ausgehend aufgebauten Verbindungen zu, nur in wenigen Fällen muss hierfür eine explizite Regel erstellt werden.
Ausgehend
Manche Firewalls lassen ausgehende Verbindungen standardmäßig zu. In diesen Fällen ist keine weitere Einstellung notwendig.
Die ausgehenden Ports 80 und 443 (HTTP und HTTPS) werden in den meisten Fällen von Firewalls ohnehin zugelassen, da sie für normales Webbrowsing notwendig sind. Allerdings leiten manche Unternehmen den Traffic auf diesen Ports über einen separaten Proxyserver, etwa um Filterung oder Virenscans durchzuführen. In solchen Fällen kann eine zusätzliche Einstellung auf diesem Server notwendig sein. Die Hinterlegung eigener Zertifikate in ThinHoc OS zur Ermöglichung von HTTPS-“Man-in-the-Middle”-Szenarien wird aus Sicherheitsgründen nicht unterstützt.
| Port | Transportprotokoll | Anwendungsprotokoll | Kommentar | 80 | TCP | HTTP | für diverse Features notwendig, u.a. Webbrowser, Websocket-Verbindungen zum Cloud Management und anderen Diensten |
|---|---|---|---|
| 443 | TCP | HTTPS | für diverse Features notwendig, u.a. Webbrowser, Websocket-Verbindungen zum Cloud Management und anderen Diensten |
| 3478 | TCP und UDP | STUN / TURN | WebRTC-Verbindung für Screen Mirroring. Viele Videokonferenzanwendungen benötigen diesen Port ebenfalls. |
| 5349 | TCP und UDP | STUN / TURN over TLS | WebRTC-Verbindung für Screen Mirroring. Viele Videokonferenzanwendungen benötigen diesen Port ebenfalls. |
| 7844 | TCP und UDP | H2MUX, HTTP2 und QUIC | Cloudflare-Tunnel für Remote-Fernsteuerung via Cloud Management |
Interne Peer-to-Peer- und Multicast-Verbindungen
Manche latenzsensitive und bandbreitenintensive Anwendungen wie Screen Mirroring können für bessere Performance auch lokale Peer-to-Peer-Verbindungen aufbauen. Zwischen ThinHoc-Geräten und Screen Mirroring-Quellgeräten sollten daher für optimale Leistung folgende Verbindungen möglich sein:
| Port | Transportprotokoll | Anwendungsprotokoll | Kommentar | 5353 | UDP | mDNS (auch bekannt als Zeroconf oder Bonjour) | Für das Multicast-Announcement der auf einem ThinHoc verfügbaren Dienste, z.B. AirPlay |
|---|---|---|---|
| 6000 - 6001, 7011 | UDP | AirPlay | Für AirPlay-Streaming von Apple-Geräten im lokalen Netzwerk |
| 7000 - 7001, 7100 | TCP | AirPlay | Für AirPlay-Streaming von Apple-Geräten im lokalen Netzwerk |
| 7236, 7250 | TCP | MICE (Miracast over Infrastructure) | Für Miracast-Streaming, welches anstatt über WiFi-Direct über die vorhandene Netzwerkinfrastruktur laufen soll (Microsoft-spezifische Erweiterung des offenen Miracast-Protokolls). Dieses Feature wird voraussichtlich bis Q2/2023 implementiert. |
| 49152 - 65535 | TCP und UDP | STUN | Für WebRTC Peer-to-Peer-Verbindungen zwischen Geräten innerhalb des Netzwerks bei Nutzung von ThinHoc Share. Sollte diese Kommunikation nicht erfolgreich sein, findet ein Fallback auf eine Verbindung via externem Server statt. |
Spezifische IP-Whitelistings für WebRTC-Relay-Funktionalität
Falls ThinHoc Share Screen Mirroring keine direkte Peer-to-Peer-Verbindung zwischen Streamingquelle und -ziel herstellen kann, wird ein Fallback auf Relay über einen externen Anbieter durchgeführt. Eine aktuelle IP-Adressliste des externen Providers finden Sie hier: https://docs.xirsys.com/assets/whitelist.json. Die Freigabe der regional relevanten IPs (z.B. Frankfurt, Europe) sollte in den meisten Fällen ausreichen – problematisch könnte dies allerdings werden, falls Ihre IP-Geolokalisierung beispielsweise aufgrund der Nutzung eines ausländischen VPNs falsch wäre.
Weitere Hinweise zu WebRTC
Die Unterstützung und der gesamte Funktionsumfang des WebRTC-Protokolls sind von vielen Faktoren abhängig, unter anderem der Implementierung Ihres Browsers, Ihrer Netzwerktopologie, Ihres Internetproviders und Ihrer Firewall- oder Proxyeinstellungen.
Sie können folgende Website verwenden, um WebRTC in Ihrer Umgebung zu testen (externer Anbieter, funktioniert nicht bei aktiviertem Ad-Blocker): https://test.8x8.vc
Dort sollten nach Durchführung des Tests unter “Connectivity” so viele grüne Haken wie möglich vorliegen. “Reflexive connectivity” kann unter Umständen aufgrund äußerer, von Ihnen nicht kontrollierbarer Faktoren nicht möglich sein, zum Beispiel falls Ihr Internetprovider CG-NAT verwendet (hauptsächlich bei Mobilfunk oder TV-Kabelanschlüssen verbreitet). In diesem Fall wird der Fallback auf “Relay” (siehe auch oben) relevant.
Ihre Browserkonfiguration trägt ebenfalls viel zur (Nicht-)Funktionalität bei. Manche Organisationen deaktivieren WebRTC, und die Implementierungen verschiedener Browser unterscheiden sich voneinander. Unserer Erfahrung nach funktioniert Google Chrome in Standardkonfiguration am zuverlässigsten. Microsoft Edge schafft es gelegentlich nicht, lokale P2P-Verbindungen aufzubauen und nutzt dann den Relay-Fallback trotz ansonsten korrekter Einstellungen. Die Implementierungen diverser Features in Safari und Firefox sind gelegentlich nicht so vollständig wie in Chromium-basierten Browsern.
Überlegungen zu Netzwerksegmentierung, VLANs und Gäste-WLANs
Es sollte beachtet werden, dass bestimmte Funktionalitäten eine direkte Verbindung zwischen ThinHoc OS-Geräten und anderen Geräten im lokalen Netzwerk erfordern bzw. mit dieser Möglichkeit bessere Performance liefern. Wenn sich beispielsweise ThinHoc-Geräte, die als Screen Mirroring-Ziel dienen sollen, in einem eigenen, nicht vom restlichen Netzwerk aus erreichbaren VLAN befinden, oder das Notebook eines externen Mitarbeiters von einem abgeschotteten Gäste-WLAN aus als Quellgerät dienen soll, muss ein Fallback zur Verbindung über einen externen Server im Internet erfolgen. Dies hat bei Nutzung von ThinHoc Share potenziell Einbußen bei Latenz und Übertragungsqualität zur Folge. Die Nutzung von Drittanbieter-Protokollen wie beispielsweise AirPlay oder Miracast-over-Infrastructure kann in solchen Szenarien sogar gänzlich unmöglich sein. Für mehr Informationen hierzu beachten Sie bitte die obenstehende Sektion “Interne Peer-to-Peer- und Multicast-Verbindungen”.