Private MCU - status "rot" nach erfolgreicher(?) installation

[nobody]

Es begann etwas komisch, nämlich, die 3CX instanz (v20, enterprise, on premises), da stand lapidar bei den Einstellungen des Videokonferenz-MCU servers, dass diese Einstellung deaktiviert ist.
Einen Knopf zum aktivieren, den gab es nicht. Hinzufügen ging auch nicht.
Ich habe dann auf Verdacht in den Parametern gesucht, und da gibt es einen Parameter, genau für diesen Zweck, den habe ich auf 1 gesetzt.
Danach konnte ich den MCU anlegen, installieren, starten.
Der ist auch gestartet, denn ich sehe beide Dienste in der Konsole des Debian VM. Und der hat auch das richtige Zertifikat (auf die eigene domain), denn wenn ich mit dem openssl s_client eine Testverbindung mache, dann wird genau das Zertifikat incl. Chain angezeigt (auf port 80 gibts jedoch keine verbindung).
Aber in der Konsole der PBX, da steht "rot", und es steht die private IP Adresse, nicht die öffentliche Ip Adresse als IP Adresse des mcu-servers drin.
Ich habe dann mal einen internen DNS Eintrag angelegt, sodass auch intern der Name auf die interne IP aufgelöst wird.
Eintrag bleibt aber rot. Ist es richtig dass dort die interne adresse drinsteht?

und, wo gibt es logfiles, und was müsste da drin stehen?

 

[avraammich_3CX]

Hi @nobody,

sodass auch intern der Name auf die interne IP aufgelöst wird.
Eintrag bleibt aber rot. Ist es richtig dass dort die interne Adresse drinsteht?

die öffentliche IP Adresse der MCU sollte stehen.

wo gibt es logfiles, und was müsste da drin stehen?

3cxWebmeeting.log(Log level Ausführlich).

Du benötigst eine eingehende Verbindung auf Port 80 auf dem MCU server.

 

[nobody]

Danke,
Der aktuelle router dort kann vielleicht kein nat-loopback. Könnte das ein Problem sein? Aber so weit bin ich ja noch gar nicht.

Denn, tatsächlich auf den port 80, da lauscht keiner:
Das liegt aber nicht an einem Firewall oder einem geschlossen port (ich habe z.B. das LE zertifikat problemlos erstellt, und das braucht auch den Port 80).
Vielmehr hört schon auf dem mcu-server keiner zu.
netstat -anp:

tcp        0      0 127.0.0.1:5020          0.0.0.0:*               LISTEN      651/McuManager
tcp        0      0 127.0.0.1:5021          0.0.0.0:*               LISTEN      651/McuManager
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      650/3CXWMMcu
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      676/sshd: /usr/sbin

Die anleitung sagt, nehme ein Debian v12.
Ich habe ein minimal debian v12 genommen, setup mit basic tools + ssh server.
Ein firewall ist nicht installiert, Ich hab noch sudo und net-tools und curl installiert.
Vielleicht iptables noch installieren? es gibt in dem mcu verzeichnis einige shell scripte die iptables verwenden.
Fehlt vielleicht noch mehr? Soll man gar ein Desktop system installieren?

 

[fxbastler]

Alle Dienste laufen so wie sie sollen (systemctl status z.B.)? Was besagt das Log des MCU Server (journalctl -xe z.B.)

 

[nobody]

ich denke schon dass die dienste laufen.

root@pbx-mcu:/var/lib/3cxpbx/WebMeeting/Logs# systemctl | grep 3CX
  3CXWMMcu.service                                                                                                                                          loaded active running   3CX WebMeeting Mcu
  3CXWMMcuManager.service                                                                                                                                   loaded active running   3CX WebMeeting Mcu Manager

Nov 25 18:11:19 pbx-mcu systemd[718]: Startup finished in 175ms.
░░ Subject: User manager start-up is now complete
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The user manager instance for user 1000 has been started. All services queued
░░ for starting have been started. Note that other services might still be starting
░░ up or be started at any later time.
░░
░░ Startup of the manager took 175847 microseconds.
Nov 25 18:11:19 pbx-mcu systemd[1]: Started [email protected] - User Manager for UID 1000.
░░ Subject: A start job for unit [email protected] has finished successfully
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit [email protected] has finished successfully.

Auch nimmt der dienst anfragen an:
/var/lib/3cxpbx/WebMeeting/Logs/3CXWMMcu_20241125.log

[2024-11-25 18:05:33.369 +01:00] [W] [728] [SSLTCPSocket] triggerSessionDestroy, key=14, 165.227.75.45:52792, stream truncated, socket_cbk=read
[2024-11-25 18:05:33.465 +01:00] [W] [703] [SSLTCPSocket] triggerSessionDestroy, key=15, 165.227.75.45:52806, http request (SSL routines), socket_cbk=ssl_handshake
[2024-11-25 18:05:33.465 +01:00] [W] [703] [TCPServer] tcp 443 bad request (SSL routines) from socket 165.227.75.45:52806, key=15, socketlist_size=0
[2024-11-25 18:05:53.294 +01:00] [W] [718] [SSLTCPSocket] triggerSessionDestroy, key=16, 66.228.44.196:8518, stream truncated, socket_cbk=ssl_handshake
[2024-11-25 18:10:53.557 +01:00] [W] [702] [TCPServer] stop listen 0.0.0.0:443
[2024-11-25 18:10:53.557 +01:00] [E] [715] [TCPServer] accept error key=17 Operation canceled 125
[2024-11-25 18:11:05.245 +01:00] [C] [598] [DTLS_CTX] OpenSSL 3.1.7 3 Sep 2024
[2024-11-25 18:21:17.606 +01:00] [W] [656] [SSLTCPSocket] triggerSessionDestroy, key=0, xxx.xxx.xxx.x:64235, wrong version number (SSL routines), socket_cbk=ssl_handshake
[2024-11-25 18:21:17.606 +01:00] [W] [656] [TCPServer] tcp 443 bad request (SSL routines) from socket xxx.xxx.xxx.x:64235, key=0, socketlist_size=0

Ich hab noch iptables installiert, aber das hat auch nichts geändert.

aber nicht auf port 80, nur auf port 443
Im protokoll der Telefonanlage steht nichts - oder ich sehe nichts.

 

[fxbastler]

Das ist doch korrekt soweit ich das gelesen habe:

https://www.3cx.com/docs/mcu-quickstart/#:~:text=The%20PBX%20%26%20MCU%20must%20be%20able%20to%20reach%20each%20other%20on%20their%20respective%20HTTPS%20ports.

Deswegen wird doch ein Zertifikat für den MCU Server erstellt bzw. benötigt.

 

[nobody]

ein gültiges Zertifikat ist da, das kann hatte ich bereits geprüft.
Danke, avraammich_3CX, der sagte aber was von port 80.Scheint aber dann wohl nicht so zu sein.
Möglicherweise ist meine Vermutung richtig, dass das Problem damit zu tun hat dass der hier verwendete Router kein NAT loopback kann.
Ich nehme dann mal einen zweiten um das zu testen.

 

[fxbastler]

Danke, avraammich_3CX, der sagte aber was von port 80.Scheint aber dann wohl nicht so zu sein.

Wegen Zertifikat.

 

[nobody]

Du meinst 80 wegen der verifizierung mit LE?
ja port 80 ist geöffnet, ich hab ja auch ein zertifikat bekommen.

 

[fxbastler]

Möglicherweise ist meine Vermutung richtig, dass das Problem damit zu tun hat dass der hier verwendete Router kein NAT loopback kann.

Wozu brauchst du das? Steht der MCU Server hinter dem gleichen Router wie die 3CX?

 

[nobody]

Aber ja - warum nicht?

 

[fxbastler]

... und du hast nur eine öffentliche IP (bzw. IPv4)?

 

[fxbastler]

Was ist denn das für ein Router?

Die Frage mit den mehr. public IP ist noch offen.

 

[fxbastler]

Andersrum: schau dir auch das hier bitte an:

https://www.3cx.com/docs/mcu-network-configuration/

Vielleicht bekommst du den MCU damit manuell überzeugt.

 

[nobody]

ich habe 16IP Adressen.
Der Router ist ein Draytek 3912, und sollte sowas (NAt loopback) eigentlich können, ich hoffe mal das das nur ein Fehler der im Moment installieren Firmware ist - oder aber ein konfigurationfehler. Ich habe jedenfalls mit einer regel sichergestellt dass sowohl Tel. Anlage als auch der MCU ausgehenden Traffic über die jeweils zugeordnete IP schicken. Das hab ich auch verifiziert. Und eingehend passt auch allles. Den Rest muss der Hersteller klären.
Ich nehme erstmal einen zweiten Router dazu als default gateway für den MCU.

 

[fxbastler]

Sonst s.o., die entspr. JSON überprüfen und ggf. addr_main ändern.

 

[nobody]

hat nix gebracht (ich habe mal main und alt vertauscht), erstmal anderen router nehmen.Dann kann ich auschliessen dass es ein Problem mit dem Nat-Loopback ist. aber Danke für die Seite mit der Dokumentation - ich war reingefallen auf den Text der unten bei

https://www.3cx.de/docs/videokonferenzserver/

steht:
Debian 12 64-Bit-VM: 4–24 vCPUs, 4–16 GB RAM, 50 GB Speicherplatz, 50–500 Mb/S Downstream/200 Mb/s–1 Gb/s Upstream je nach Nutzung. Umfassendere Dokumentation und weiterführende Informationen werden zu einem späteren Zeitpunkt verfügbar sein.

und hab nicht daran gedacht die Fa. Google zu bemühen.

 

[fxbastler]

alt leer lassen

 

[nobody]

schade, auch nicht. Hier stimme ich mal der Fa. 3CX voll zu dass on premise installationen überraschende besonderheiten bereithalten können.

 

[bitn]

Ich hatte auch solche oder ähnliche Probleme ich glaube ich hab mir mit Host Einträgen geholfen.
Kann ich morgen mal nachschauen was ich da so veranstaltet habe.