Best Practice Testsystem

[mplad]

Hallo zusammen,

wir haben eine 3CX V20 Pro Version im lokalen Debian-Image am laufen. Die müsste an einen neuen Standort umgezogen werden. Der erste Testlauf verlief nicht gerade erfolgreich. Gibt es eine Möglichkeit, sich eine Testumgebung im Vorfeld zu generieren, inkl. FQDN, um erst einmal alle Settings (Firewall und Co.) zu testen ohne die laufende 3CX zu beeinflussen?
Gibt es hier eine günstige Vorgehensweise? Vielen Dank.

 

[fxbastler]

Gibt es eine Möglichkeit, sich eine Testumgebung im Vorfeld zu generieren, inkl. FQDN, um erst einmal alle Settings (Firewall und Co.) zu testen ohne die laufende 3CX zu beeinflussen?

Grundsätzlich ja. Mit einer weiteren 3CX Lizenz kann man sich eine neue Anlage bauen und mit der div. Dinge am neuen Standort testen. Aber bedenke: das ist dann ein anderer Lizenzschlüssel und anderer FQDN. Du muss selber entscheiden, inwieweit das Testkonstrukt tragfähig für die später real genutzte 3CX dort ist.
So etwas haben wir noch nie gemacht oder machen müssen. Ich wüsste auch keinen Grund.

Gibt es hier eine günstige Vorgehensweise?

Erkläre uns doch erst einmal die bisherige Vorgehensweise, was alles nicht funktioniert hat, woran es gescheitert ist und was - abgesehen vom phys. Standort - die wesentlichen techn. Änderungen nach dem Umzug sind.
Mir ist kein Grund bekannt woran so etwas scheitert. Es wird an Wissen fehlen. Mit der richtigen Beschreibung bekommst du das hier.

 

[mplad]

Grundlegend habe ich folgende Vorgehensweise angewandt:
Debian auf Hyper-VM aus Backup wiederhergestellt, im Linux die neue IP angepasst, sowie im 3CX selbst unter Netzwerk die neue interne und externe IP eingetragen.
Wir betreiben dies hinter einer Watchguard Firebox M290 und ich habe im Vorfeld alle Policies eingerichtet. (Analog zum ersten Standort, da dort die gleichen Geräte stehen)

Das Bild: Die 3CX läuft zwar, auch Anrufe kommen herein, aber ich kann nicht extern via FQDN connecten. Weder via Native-Client, noch Browser-App. DNS-Auflösung passt, externe IP ist pingbar, Checks mit Powershell via Test-NetConnection und Portcheck ist erreichbar. Nach entsprechender Portweiterleitungen wird zwar augenscheinlich eine Verbindung hergestellt, aber ich kann bspw. den Status einer Nebenstelle nicht ändern. Auch bringt der interne Firewall-Checker der 3CX Fehler, begonnen bei Port 5060 UDP + SIP ALG-Test.
Eine Frage: Muss die public IP für ausgehend + eingehend übereinstimmen? Hintergrund: Wir haben mehrere public IPs, aber da 3CX Ports benötigt, die bereits von anderen Diensten belegt sind, muss ich den FQDN auf eine weitere public IP schieben.

 

[bitn2]

Grundsätzlichen müssen die ausgehende als auch eingehende IP übereinstimmen. Das wird schon mal der erste Fehler sein. Portfreigaben nach Vorgabe erstellt?

 

[fxbastler]

Eine Frage: Muss die public IP für ausgehend + eingehend übereinstimmen?

ja

 

[mplad]

Ich kann mit Sicherheit den Outbound-Traffic auf die andere IP schieben. Und ja, Portfreigaben sollten passen. Die greifen bei eingehenden Verbindungen (FQDN) auf die jeweilige IP und leiten diese intern an die 3CX weiter. Erstellt nach Vorlage von Standort 1 und entsprechendem FAQ von 3CX. Ich kann das nur jetzt schlecht testen, denn mit Sicherheit entsteht dann ein Konflikt mit der noch laufenden 3CX an Standort 1. Daher auch meine Frage bezüglich separater Testumgebung.

 

[bitn2]

Mir ist auch noch nicht ganz klar wofür die separate Testumgebung sein soll. Die Firewall und Netzwerkumgebung kann man ja schlecht testen. Wenn die Portfreigaben korrekt sind und die aus und eingehende IP korrekt ist, dann funktioniert das problemlos.

 

[mplad]

Wofür? Ob FQDN erreichbar sind, Port-forwarding funktioniert, Checker durchlaufen, und das bevor man ein evtl. wichtige Live-Systeme umzieht. Was ist die Alternative? Netzwerk konfigurieren, alles einrichten und frei nach YOLO umziehen? Ich frag nur.

 

[bitn2]

Das kannst du ja nur vor Ort am Standort testen, wie soll das sonst gehen. Wenn du das korrekt einrichtest, brauchst du da auch nichts testen. Haben wir noch nie gebraucht.

 

[mplad]

Natürlich teste ich das vor Ort. Die "neue" VM ist auf dem Hypervisor am neuen Standort. Ich kann nur nicht im laufenden Betrieb testen, denn die 3CX läuft ja noch parallel auf dem Hypervisor am alten Standort, da der Umzug gestern (mit deaktivierter 3CX am Standort 1) nicht ganz so gut funktioniert hat und ich würde gern verstehen, wieso und weshalb.

 

[bitn2]

Ok, verstehe. Einen Test halte ich weiterhin für unnötig, wenn man sich an die Vorgaben hält und Netzwerk und Firewall korrekt konfiguriert. So wäre ein genereller Test nur mit einer Testlizenz möglich mit anderem FQDN usw. Ansonsten wäre der Umzug relativ einfach. Ich gehe mal von einem korrekt konfiguriertem Netzwerk/Firewall aus, dann ist das nur VM aufsetzen und Backup wiederherstellen. Gegebenenfalls die externe IP in der 3cx anpassen und fertig. Wichtig zu beachten sind die Endgeräte. Wenn die aktuell lokal angebunden sind (hoffentlich per FQDN) dann muss entweder ein VPN zum neuen Standort vorhanden sein oder die Geräte alle auf einen SBC umgestellt werden.

 

[mplad]

Soweit war ich gestern schon. Die Anlage lief ja, nur 2 Dinge nicht: 3CX Firewall-Checker und Client-Sessions von extern auf den FQDN. D.h. intern und via VPN alles erreichbar. Geh ich jedoch von extern, bspw. via Android App und Mobilfunknetz ohne VPN auf die 3CX, geht nichts. Dafür macht man ja, meines Wissens, unter anderem den Port 443 offen, um dort Verbindungen zuzulassen und die 3CX setzt die neue externe IP auf den FQDN, was ja auch funktioniert hat. Bei uns läuft alles auf den FQDN per Split-DNS. Intern wir die interne aufgelöst, und extern ist eben extern.

 

[bitn2]

Wenn das euer https Port ist, dann ja. Wenn du gestern aber zb die eingehende und ausgehende IP nicht gleich hattest, kann das schon mal nicht funktionieren.

 

[mplad]

Ich teste noch einmal mit gleichen IPs für Out- und Inbound sobald wieder ein Zeitfenster offen ist. Eventuell ist das ja die Fehlerursache.

 

[bitn2]

Wenn die sonstigen Firewalleinstellungen zum Thema Portweiterleitung und SIP Alg korrekt eingerichtet sind, sollte das funktionieren.

Das ist sogar ganz sicher eine Fehlerursache, wenn nicht noch was anderes dazwischen funkt.

 

[fxbastler]

Netzwerk konfigurieren, alles einrichten und frei nach YOLO umziehen? Ich frag nur.

Ja, so machen wir das immer und das funktioniert, bisher problemlos.

Bedenke beim Umzug: wenn ihr eine 3CX Pro habt und einen 3CX FQDN, dann dauert der ext. IP Wechsel. Hat denn die ext. Auflösung des FQDN nach dem Umzug auf die umgezogene IP funktioniert?

 

[mplad]

Ja, so machen wir das immer und das funktioniert, bisher problemlos.

Bedenke beim Umzug: wenn ihr eine 3CX Pro habt und einen 3CX FQDN, dann dauert der ext. IP Wechsel. Hat denn die ext. Auflösung des FQDN nach dem Umzug auf die umgezogene IP funktioniert?

Ja, das klappte innerhalb weniger Minuten. Daran lag es nicht. Ich denke, dass irgendetwas an der Firewall / Routing Config noch nicht in Gänze hinhaut. Eine andere Möglichkeit fällt mir hierzu aktuell nicht ein. Kann ich die kommenden Tage noch einmal testen. Ich kann leider nicht die komplette Telefonie in den Geschäftszeiten killen, solange ich auf Fehlersuche bin, leider.

 

[mbehrens]

Das Bild: Die 3CX läuft zwar, auch Anrufe kommen herein, aber ich kann nicht extern via FQDN connecten. Weder via Native-Client, noch Browser-App. DNS-Auflösung passt, externe IP ist pingbar, Checks mit Powershell via Test-NetConnection und Portcheck ist erreichbar. Nach entsprechender Portweiterleitungen wird zwar augenscheinlich eine Verbindung hergestellt, aber ich kann bspw. den Status einer Nebenstelle nicht ändern. Auch bringt der interne Firewall-Checker der 3CX Fehler, begonnen bei Port 5060 UDP + SIP ALG-Test.
Eine Frage: Muss die public IP für ausgehend + eingehend übereinstimmen? Hintergrund: Wir haben mehrere public IPs, aber da 3CX Ports benötigt, die bereits von anderen Diensten belegt sind, muss ich den FQDN auf eine weitere public IP schieben.

Scheinbar liegt eine Fehlkonfiguration der Firewall im Bereich des Policy Based Routing vor.

 

[mplad]

Guten Tag zusammen,
erst einmal vielen Dank für die Hilfe bis hierhin. Ein kurzes Update und eine Anschlussfrage: Der Firewall-Check der 3CX lief nun komplett ohne Fehler durch, nach dem ich jeden Outbound-Traffic vom 3CX Host über die korrekte Public-IP verschicke. Ein Problem besteht aber weiterhin, dass sich externe Clients via FQDN nicht connecten können. Dafür ist der Port 443 gedacht, korrekt? VG

 

[bitn2]

Wenn das dein https Port ist ist unter anderem dieser nötig. Das kannst nur du beantworten.