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”.

Warenkorb