OT: Apache2, Nextcloud, Talk, coturn
Hallo zusammen, benutzt jemand von Euch die oben genannten Tools (unter OpenSUSE) und kann mir Tipps geben ? Aktuell benutze ich auf einem kleinen HP MicroServer einen Apache2, und Nextcloud. Auf der Fritzbox habe ich eine Portweiterleitung von 30443 auf 443 des HP Servers eingerichtet. Als Zertifikat benutze ich erst einmal ein selbst signiertes Zertifikat, auch wenn man das bei der erstmaligen Verbindung erst abnicken muss. Es sind wenige User, die das vom Internet aus nutzen. Das funktioniert soweit, wenn auch der Verbindungsaufbau im Firefox etwas lange dauert. Die Datensyncerei zu Linux, $MS und Android funktioniert auch. Nun habe ich in Nextcloud die App Talk aktiviert. Schreiben funktioniert soweit. Auch vom Internet aus. Audio/Video funktioniert im lokalen Netz, aber von Außen kommt keine Verbindung zustande, oder es dauert sehr lange. Besteht eine Verbindung ist die Sprachqualität sehr gut. Hilfe bei er Verbindung soll da ein TURN Server schaffen. Ist Audio(/Video) für meinen kleinen HP ProLiant MicroServer N36L überhaupt sinnvoll ? (CPU: AMD Athlon(tm) II Neo N36L Dual-Core; RAM: 8GB) Es gibt dazu einige Beschreibungen im Netz, beispielsweise [1] https://decatec.de/home-server/nextcloud-talk-mit-eigenem-turn-server-coturn... oder [2] https://help.nextcloud.com/t/howto-setup-nextcloud-talk-with-turn-server/307... Gibt es eine bessere Beschreibung ? Was mir jetzt nicht klar ist: Aktuell kommt die Verbindung von Außen ja beim HP Server auf Port 443 an und das ist doch der Apache2 (?) Wie wird das dann mit dem TURN Server? Wenn ich den coturn zum Laufen bekomme (auf Port 5349), müsste ich dann nur für den Talk Dienst meine DynDNS Addresse auf Port 5349 benutzen und für alle anderen Nextcloud-Apps weiterhin die DynDNS Addresse auf Port 443 ? Passen die coturn Settings von [1] auch für SUSE ? Vielen Dank für's Lesen und für Tipps. viele Grüße Werner Franke
Am Wed, 25 Oct 2023 10:37:28 +0200 schrieb Werner Franke <werner_franke@arcor.de>:
Ich weiß nicht, ob das in diesem Fall der Grund der Probleme ist, aber Media-Streams und NAT bieten Potential dafür. Nachdem die Fritzbox mit NAT arbeitet (was ich aus der "Portweiterleitung" schließe), gibt es erst mal ein Problem mit den Media-Streams, über die die Audio- und Videodaten transportiert werden. Die nutzen UDP und das funktioniert nun mal nur ausgehend, also würde man vielleicht draußen was hören, aber nicht drinnen. Damit das trotzdem funktioniert, hat die Fritzbox einige Tricks auf Lager, die auf Annahmen und temporären Forwarding-Rules beruht. Einfaches Bsp. sind DNS-Requests, die zwar ausgehend funktionieren, aber die, meist ebenfalls per UDP, eintreffende Antwort, kann von der Fritzbox nicht mehr zum anfragenden LAN-Client weitergeleitet werden. Damit das trotzdem funktioniert, richtet die Fritzbox aufgrund des Requests auf Port 53/udp temporär eine Portweiterleitung von der DNS-Server-IP, Port 53/udp zur LAN-Client-IP, Port 53/udp ein. Die meisten Fritzboxen können das auch für VoIP, aber inwieweit das auch für Media-Streams jenseits von SIP funktioniert, weiß ich nicht. Ein Problem könnte auch sein, wenn der eingehende Media-Stream mit anderen Ports arbeitet als der ausgehende. STUN- oder TURN-Server sollen helfen, die Probleme mit UDP und NAT weniger spekulativ zu lösen. Beide Typen müssen jedoch im public Internet stehen. Eventuell ist es einfacher, den openSUSE-Server ins Internet zu stellen, also PPPoE-Aufbau durch die Box und die Fritzbox als DSL-Modem. Oder man konfiguriert die Server-IP als Exposed-Host in der Fritzbox. Vermutlich muss man dabei jedwede VoIP- oder Remote-Management-Funktionen auf der Fritzbox ausschalten, damit wirklich alle Ports weitergeleitet werden. Zuvor solltest Du jedoch den Server "härten", also insbesondere restriktive Paketfilterregeln einrichten. Gruß, Tobias.
Am 25.10.23 um 12:20 schrieb Tobias Crefeld:
Hallo Tobias, ich verstehe nur Bahnhof. Ich möchte den Aufwand schon in Grenzen halten und das oben hört sich nicht danach an. Die Sache mit Audio und Video in Nextcloud brauche ich nicht wirklich. Ich mache das eigentlich nur, weil es schön wäre über den eigenen Server zu telefonieren und weil ich da wieder was dazulerne. Grüße Werner
Am Wed, 25 Oct 2023 17:14:01 +0200 schrieb Werner Franke <werner_franke@arcor.de>:
Audio- und Video-Telefonie über NAT ohne öffentlich erreichbaren 3rd-party-Server ist, technologisch gesehen, nicht trivial, aber möglich. Für diejenigen, denen das zu komplex ist, stellen ja jede Menge Provider ebendiese Server gegen kleines bis größeres Geld bereit. Gruß, Tobias.
Am Wed, 25 Oct 2023 10:37:28 +0200 schrieb Werner Franke <werner_franke@arcor.de>:
Ich weiß nicht, ob das in diesem Fall der Grund der Probleme ist, aber Media-Streams und NAT bieten Potential dafür. Nachdem die Fritzbox mit NAT arbeitet (was ich aus der "Portweiterleitung" schließe), gibt es erst mal ein Problem mit den Media-Streams, über die die Audio- und Videodaten transportiert werden. Die nutzen UDP und das funktioniert nun mal nur ausgehend, also würde man vielleicht draußen was hören, aber nicht drinnen. Damit das trotzdem funktioniert, hat die Fritzbox einige Tricks auf Lager, die auf Annahmen und temporären Forwarding-Rules beruht. Einfaches Bsp. sind DNS-Requests, die zwar ausgehend funktionieren, aber die, meist ebenfalls per UDP, eintreffende Antwort, kann von der Fritzbox nicht mehr zum anfragenden LAN-Client weitergeleitet werden. Damit das trotzdem funktioniert, richtet die Fritzbox aufgrund des Requests auf Port 53/udp temporär eine Portweiterleitung von der DNS-Server-IP, Port 53/udp zur LAN-Client-IP, Port 53/udp ein. Die meisten Fritzboxen können das auch für VoIP, aber inwieweit das auch für Media-Streams jenseits von SIP funktioniert, weiß ich nicht. Ein Problem könnte auch sein, wenn der eingehende Media-Stream mit anderen Ports arbeitet als der ausgehende. STUN- oder TURN-Server sollen helfen, die Probleme mit UDP und NAT weniger spekulativ zu lösen. Beide Typen müssen jedoch im public Internet stehen. Eventuell ist es einfacher, den openSUSE-Server ins Internet zu stellen, also PPPoE-Aufbau durch die Box und die Fritzbox als DSL-Modem. Oder man konfiguriert die Server-IP als Exposed-Host in der Fritzbox. Vermutlich muss man dabei jedwede VoIP- oder Remote-Management-Funktionen auf der Fritzbox ausschalten, damit wirklich alle Ports weitergeleitet werden. Zuvor solltest Du jedoch den Server "härten", also insbesondere restriktive Paketfilterregeln einrichten. Gruß, Tobias.
Am 25.10.23 um 12:20 schrieb Tobias Crefeld:
Hallo Tobias, ich verstehe nur Bahnhof. Ich möchte den Aufwand schon in Grenzen halten und das oben hört sich nicht danach an. Die Sache mit Audio und Video in Nextcloud brauche ich nicht wirklich. Ich mache das eigentlich nur, weil es schön wäre über den eigenen Server zu telefonieren und weil ich da wieder was dazulerne. Grüße Werner
Am Wed, 25 Oct 2023 17:14:01 +0200 schrieb Werner Franke <werner_franke@arcor.de>:
Audio- und Video-Telefonie über NAT ohne öffentlich erreichbaren 3rd-party-Server ist, technologisch gesehen, nicht trivial, aber möglich. Für diejenigen, denen das zu komplex ist, stellen ja jede Menge Provider ebendiese Server gegen kleines bis größeres Geld bereit. Gruß, Tobias.
participants (2)
-
Tobias Crefeld -
Werner Franke