probleme bei redirect bei provisionierungslink

[kellermeister]

Ich habe ein Upgrade von v16 auf v18 auf einer onpremise windows installation gemacht.
eigene domain, eigenes Zertifikat. Aufruf der Admin-seite ohne Zertifkatsprobleme. Firewallcheck grünes Hakerl.

Folgendes Problem tritt nun auf: die Provisionierungslinks sind im Format
http://10.0.xxx.xx:5000/provisioning/xxx/cfg{mac}

auf der 3cx erfolgt ein (automatisches?) redirect auf
https://10.0.xxx.xx:5000/provisioning/xxx/cfg{mac}

Dieser schlägt fehl, weil auf port 5000 läuft http und nicht https (oder ist es ein adners Problem?)

Wenn ich das Telefon auf extern STUN umstelle ändert sich der provlink auf
https://FQDN/provisioning/rmrjcgurlfwr/cfg{mac}

und damit würde es funktionieren, jetzt stimmt der port (die 443 wird ja automatisch bei https ergänzt).

Gleiches Spiel bei der Firmware:
http://10.0.xxx.xx:5000/provisioning/rmrjcgurlfwr/firmware/snom/snomD345-10.1.84.15-SIP-r.bin -> FUNKT NICHT (im webbrowser)
aber https://FQDN/provisioning/rmrjcgurlfwr/firmware/snom/snomD345-10.1.84.15-SIP-r.bin -> FUNKT (im webbrowser)

Wie kann ich das fixen? Das Provisionieren des Telefon ist nicht möglich.

Wenn ich das Telefon resette und versuche der Nebenstelle zuzuweisen, dann kann man es nicht einbinden.

 

[bitn]

Hast du Split DNS eingerichtet?
Man kann ja auch ohne STUn umstellen die Schnittstelle das er den FQDN nimmt.

 

[kellermeister]

Hast du Split DNS eingerichtet?
Man kann ja auch ohne STUn umstellen die Schnittstelle das er den FQDN nimmt.

Split-DNS: ja.
Aber wie kann ich auf den Provisionierungslink Einfluss nehmen? der wird ja automatisch (falsch) gemacht.
Die Umstellung auf STUN ist nicht mein Ziel, das ist viel zu aufwändig.

 

[fxbastler]

Hallo,

auf der 3cx erfolgt ein (automatisches?) redirect auf
https://10.0.xxx.xx:5000/provisioning/xxx/cfg{mac}

So etwas passiert nicht automatisch. Wie kommst du zu dieser Annahme bzw. Aussage?

Wenn ich das Telefon auf extern STUN umstelle ändert sich der provlink auf
https://FQDN/provisioning/rmrjcgurlfwr/cfg{mac}

Ja, das ist so - wenn man in der 3CX den HTTPS Port auf 443 festgelegt hat. Aber wenn das Telefon lokal im gleichen Netzwerk wie die 3CX steht dann lass das und ändere diesen Punkt nicht mal eben so, zumindest diese Einstellung nicht speichern wenn sie nicht wirklich benötigt wird.

Aber wie kann ich auf den Provisionierungslink Einfluss nehmen?

Durch Anpassung der Ports der 3CX, durch Ändern der 'Schnittstelle' (in der jew. Nebenstelle unter Telefon-Provisionierung, dort steht auch der FQDN zur Provisionierung der NST. Telefone zur Verfügung), durch die Wahl des Standortes, teilw. gar durch die Wahl des Aufrufes der 3CX Verwaltungsoberfläche (z.B. wenn kein Aufruf per FQDN sondern per IP).

Die Umstellung auf STUN ist nicht mein Ziel, das ist viel zu aufwändig.

Wie @bitn schreibt: man kann die Provisionierungsschnittstelle ändern wenn man Split DNS ermöglicht. Damit ändert man nicht die Telefonprovisionierung auf STUN.

Keine Ahnung wieso hier und da bei dir Links mal per HTTP auf dem Port 5000 und dann wieder per HTTPS auf dem Port 5000 erreichbar sein sollen.

Ich weiss nur: wenn ich einen eigenen FQDN habe und ein eigenes LE Zertifikat dann liegen diese in einer Debian Installation unter /var/lib/3cxpbx/Bin/nginx/conf/Instance1 und sind somit nur für die Website aktiv. Erst mit Ablage dieser Zertifikate unter /var/lib/3cxpbx/Instance1/Bin/Cert/ wird verschlüsselte Kommunikation möglich (Secure SIP). Aber auch dann werden noch keine Links mit HTTPS zur Provisionierung erzeugt.

Wenn du unter Einstellungen / Parameter nach 5000 suchst - taucht da irgendwo ein HTTPS Link auf?

 

[kellermeister]

Das grundsächliche Problem besteht, aber die Ursachenforschung war durch eine fehlerhafte Beobachtung getrübt.

Fakt ist, das nach dem Update das Provisionieren und Firmewareupdaten nicht mehr funktioniert.

Nachdem ich SplitDNS verwende, habe ich die Provlinks getestet (just to be sure) ob die Namensauflösung auch im Subnet funktioniert. Die Namensauflösung funktioniert, aber der Browser hat automatisch die http auf https umfunktioniert. Ich habe vorher die 3cx-Admin-Seite aufgerufen (https!!) und mit dem HSTS-Mechanismus hat der hilfreiche Chrome alle folgenden Aufrufe automatisch auf https umgebessert. Die http-Links auf Port 5000 werden von der 3cx korrekt ausgeliefert, dieser "Fehler" war also ein Beobachtungsfehler.

Die Änderung der Provisionierungsschnittstelle (Wechsel zwischen IP und FQDN) hat in einer Split-DNS-Umgebung natürlich keine Auswirkungen wenn FQDN auf die IP zeigt. Der Wechsel ist aber eigentümlich, man muss die Provisierungsart zweimal wechseln um ans Ziel zu kommen, das ist aber ein GUI-Problem, sonst nichts.
(Mein Fehlersuchansatz mit dem Wechsel von lokal auf STUN verschleiert das Problem und kann ebenfalls ignoriert werden.)

So, damit "reduziert" sich das Problem wie folgt:
Die Telefone sind nach dem Upgrade nicht provisionierbar (können aber telefonieren, weil die alte Provisionierung ja noch im Telefon steckt!). Wenn man das Telefon von der Nebenstelle entfernt, das Telefon aus der Liste löscht, resettet und neu einbindet funktioniert alles wie gewollt, Firmware flasht, Provisionierung geht klar.

Jetzt habe ich bei der Telefonanlage alle (10) Apparate neu eingebunden - damit ist mein Testpotential erschöpft. Diese Woche habe ich noch 2 Anlagen auf meiner Liste.

Gibt es irgendetwas, das ich beim Upgrade-Prozess übersehen haben kann?

 

[fxbastler]

Gibt es irgendetwas, das ich beim Upgrade-Prozess übersehen haben kann?

An sich nicht.

Wurden denn irgendwelche Ports geändert? Das wäre der einzige Grund einige deiner geschilderten Probleme. Dann passiert so etwas. Da wir das seit geraumer Zeit machen weiss ich was danach so alles klemmt.

 

[kellermeister]

Ich hab meine ganzen Aufzeichnungen durchforstet und mir das Hirn zermartert.
Tatsächlich:
Es wurde ein Port geändert: und zwar war die alte 3CX auf 5000/5001 und die neue nun auf 5000/443

 

[fxbastler]

Bingo.

Genau das ist bei uns die Aufgabe des Monats (alle Anlagen so umzustellen) und genau das passiert dann. Darfste alle Endgeräte neu provisionieren die per HTTPS etwas brauchen.

 

[kellermeister]

OK, dann hats zumindest eine Erklärung.

Ich hab schon befürchtet die modifizierte Vorlage macht das Problem....Danke für die Bestätigung.