| 18 Jan 2021 |
 basisbit (senfcall.de) | fmw: was ist dein Ziel bzw welches Problem möchtest du damit lösen? | 22:32:11 |
 fmw | In reply to @basisbit:matrix.org
fmw: was ist dein Ziel bzw welches Problem möchtest du damit lösen? Es ist ein Versuch in einer langen Troubleshooting-Reihe. Ein Kunde möchte einen coturn server als "bbb proxy" verwenden, d.h. er hat einen coturn in seinem privaten Netz hinter dem Firewall, und macht NAT/Port-Mapping von aussen auf den coturn. Das funktioniert nur bedingt :) | 22:36:04 |
| fmw | In reply to @fmw:tedomum.net
Es ist ein Versuch in einer langen Troubleshooting-Reihe. Ein Kunde möchte einen coturn server als "bbb proxy" verwenden, d.h. er hat einen coturn in seinem privaten Netz hinter dem Firewall, und macht NAT/Port-Mapping von aussen auf den coturn. Das funktioniert nur bedingt :) Nach unserem Verständnis versucht der WebRTC im internen Netz erst mal STUN gegen den coturn, bekommt seine eigene private Adresse zurück, und glaubt danach, im offenen Internet zu sein. | 22:37:02 |
| fmw | In reply to @fmw:tedomum.net
Nach unserem Verständnis versucht der WebRTC im internen Netz erst mal STUN gegen den coturn, bekommt seine eigene private Adresse zurück, und glaubt danach, im offenen Internet zu sein. Wir haben versucht, mit no-stun den Stun-Teil des coturn zu deaktivieren, aber bislang ohne Erfolg. Die "iceTransportPolicy: relay" scheint auf den ersten Blick genau das zu tun, was der Kunde will: clients verwerfen alle direkten (falschen) Kandidaten, und erwägen nur (turn-)relays. | 22:38:56 |
| basisbit (senfcall.de) | ist der Coturn denn in "Besitz" des BBB Server Betreibers? | 22:39:30 |
| fmw | In reply to @basisbit:matrix.org
ist der Coturn denn in "Besitz" des BBB Server Betreibers? Ne, der steht beim Kunden im internen Netz. BBB Betreiber (wir) leistet Support. | 22:40:07 |
| basisbit (senfcall.de) | Okay, dann kann sich BBB nicht bei dem Coturn authentifizieren und der BBB Server versucht natürlich auch nicht sich zum Coturn Server zu verbinden. | 22:41:16 |
| fmw | Es ist noch ein http(s) Proxy im Spiel. Über den geht das Signaling. FreeSWitch kommt mit dem Setup klar. | 22:42:21 |
| fmw | Kurento nicht | 22:43:18 |
| basisbit (senfcall.de) | für den https Anteil vielleicht, solange der Webbrowser dem Zertifikat vertraut, für dTLS sollte das aber nicht funktionieren, da der BBB Client Fingerprint-Checking durchführt | 22:43:30 |
| fmw | Zerti ist im Coturn und im BBB hinterlegt | 22:44:01 |
| basisbit (senfcall.de) | kann der Kunde keine Firewallfreigaben zu den IP-Adressen eurer TURN Server einrichten? | 22:44:16 |
| basisbit (senfcall.de) | oder TLS auf 443 zu euren IP Adressen ungeöffnet durchleiten? | 22:44:33 |
| fmw | Nein, eigener Turnserver. | 22:44:34 |
| fmw | Und nein, http(s) proxy | 22:44:48 |
| fmw | Und nein, durch den Proxy kommt man nicht auf externe turnserver. Meistens jedenfalls. | 22:45:06 |
| basisbit (senfcall.de) | Es würde mich wundern, wenn ihr das bei euch zum funktionieren bringt. Das bricht viele Sicherheitskonzepte und macht Fingerprint-Checking unmöglich | 22:45:58 |
| fmw | Erzähl mehr zum fingerprint-checking. Meinst Du, weil der webproxy das ssl aufmacht? | 22:46:34 |
| fmw | wiegesagt, das Zerti im coturn kennt der bbb server, ist in der konfig hinterlegt. | 22:46:57 |
| basisbit (senfcall.de) | nein, weil das dTLS vom Webbrowser geprüft wird | 22:47:12 |
| fmw | Hast Du nen Pointer wo ich mich über die dTLS geschichte schlau machen kann? | 22:47:51 |
| basisbit (senfcall.de) | der coturn bricht die Verschlüsselung ja nicht auf, der verpackt nur und leitet weiter | 22:47:54 |
| fmw | genau | 22:48:00 |
| basisbit (senfcall.de) | https://webrtc-security.github.io/ | 22:48:24 |
| fmw | Danke, ich lese es mal genau durch. Allerdings ist das Verhalten des Kurento-Clients, dass er nur kurz STUN gegen den coturn macht und danach gar nicht erst versucht, TURN zu machen, sondern nur noch die nicht-relay kandidaten versucht, die alle am Firewall hängen bleiben. | 22:52:18 |
| fmw | Danke jedenfalls erstmal. | 22:52:37 |
| basisbit (senfcall.de) | Kurento sollte per trickle ICE diverse Kombinationen testen, probiert die ersten "erfolgreichen" Wege, und sollte aber wenn die Fehlschlagen automatisch ein Fallback über andere erfolgreiche Wege versuchen. | 23:22:08 |
 SWEETGOOD | In reply to @fmw:tedomum.net
Es ist ein Versuch in einer langen Troubleshooting-Reihe. Ein Kunde möchte einen coturn server als "bbb proxy" verwenden, d.h. er hat einen coturn in seinem privaten Netz hinter dem Firewall, und macht NAT/Port-Mapping von aussen auf den coturn. Das funktioniert nur bedingt :) Ich habe dieses Setup bereits erfolgreich umgesetzt :-) | 23:30:47 |
| SWEETGOOD | In reply to @sweetgood:matrix.sweetba.se
Also jetzt wie versprochen:
Der BBB-Server ist ganz normal nur mit interner IP konfiguriert (Tutorial für Betrieb hinter NAT-Firewall wurde also NICHT angewendet). Als STUN- und TURN-Server ist der coturn (welcher im gleichen internen IP-Adressbereich erreichbar ist) hinterlegt, allerdings mit der öffentlichen IP. So kommuniziert der BBB die öffentliche IP des coturn an den Client, der von extern kommt und der wiederum kann über den TURN-Server die Verbindung aufbauen. An sich ein super simples Szenario, was all die "NAT"-Albträume von BBB erstmal erledigt hat. Und das in kürzester Zeit. Denn die internen Clients erreichen den BBB-Server ja direkt.
Einziger Nachteil ist nur, dass jetzt alle externen Teilnehmer ausnahmslos über den coturn laufen, der also ein Nadelöhr bzw. einen "single point of failure" darstellt.
siehe hier. | 23:32:27 |
| SWEETGOOD | Und ein Hinweis noch, falls jemand den coturn mit der Anpassung "AmbientCapabilities=CAP_NET_BIND_SERVICE" im unitfile betreibt, um Ports unter 1024 zu verwenden. Diese Einstellung muss nach dem anstehenden Sicherheitsupdate wieder händisch gesetzt werden, sonst startet der coturn nicht mehr. Bin gerade auf den Bugreport gestoßen, der vmtl. genau damit zusammenhängt. https://bugs.launchpad.net/ubuntu/+source/coturn/+bug/1911860 | 23:33:59 |
