Warum der Firewall-Checker nicht lügt
3CX verfügt über einen integrierten automatischen Firewall-Checker, der die Einrichtung Ihrer Firewall im Hinblick auf „Port Forwarding“ und auch „Port Preservation“ validiert.
Port Forwarding
3CX prüft, ob „Full Cone NAT“ auf dem Firewall-/Gateway-Gerät korrekt eingerichtet ist. Full Cone NAT ermöglicht es jeder externen Entität, sich mit 3CX zu verbinden, ohne dass die Firewall zunächst bestätigen muss, dass das tatsächliche Paket von 3CX stammt, bevor sie die Verbindung zulässt. Dies ist insbesondere für VoIP-Anbieter sehr wichtig, da der SIP-Server nicht derselbe Server (Quell-IP-Adresse) ist, der das Endaudio an Ihr System liefert. In manchen Fällen setzt die Firewall-Implementierung den eingehenden Datenverkehr als „nicht zulässig“ auf eine Verweigerungsliste, wodurch eine Verbindung zum Ziel verhindert wird, selbst wenn 3CX beginnt, Daten (Audio) an das Ziel zu senden.
Port Preservation
Die Porterhaltung ist ein weiterer wichtiger Faktor, der vom Firewall-Checker überprüft wird. Es erkennt, ob die Firewall den Port während der LAN-IP-zu-WAN-IP-Übersetzung ändert. Technisch gesehen sollte dies keine Rolle spielen, es hängt jedoch von der Implementierung des Anbieters ab, ob er auf den Transport-Quellport von 3CX antwortet, der im UDP-Header zu sehen ist, und nicht auf den im RFC definierten Port. Der RFC definiert, dass ein SIP-Server auf die definierte „Kontakt“-IP und den Port antworten MUSS, die im Inhalt der SIP-Nachricht enthalten sind. Um eventuelle Abweichungen auszuschließen, validiert der Firewall-Checker auch diese Zuordnung. Wenn eine SIP-Nachricht lokal von 3CX vom Quellport 5060 (Standard-SIP-Port) generiert und dann in die öffentliche IP-Adresse (WAN-IP) übersetzt wird, muss der Port, in diesem Fall 5060, unverändert bleiben.
Dazu führt der Firewall-Checker zwei unabhängige Tests mit dem ersten konfigurierten STUN-Server in Ihrem System durch. Standardmäßig ist dies auf stun.3cx.com eingestellt. Es wird dringend empfohlen, dies nicht zu ändern. Insgesamt ist der Firewall-Checker eine programmgesteuerte Möglichkeit, Ihre öffentliche IP-Adresse zu erkennen, ähnlich wie die Verwendung einer Website wie „Was ist meine IP“, wird jedoch erweitert, um auch den Port zu überprüfen.
Beispiele
Unten sehen Sie eine von der 3CX-Verwaltungskonsole gemeldete fehlgeschlagene Firewall-Prüfung und eine entsprechende Wireshark-Erfassung des Datenverkehrs. In dieser Anleitung erläutern wir die Schritte, die der Firewall-Checker durchführt, und zeigen Ihnen die Ergebnisse. Die Wireshark-Erfassung ist darauf beschränkt, nur „Port 3378 oder Port 3379“ anzuzeigen, auf dem dieser Test basierte. Für den Firewall-Checker ist es wichtig, dass die Windows-Firewall deaktiviert ist. Die Installation von 3CX führt zu Ausnahmen für einige 3CX-Anwendungen, jedoch nicht für den Firewall-Checker selbst!
Test 1
3CX stoppt die Dienste, um den lokalen Port freizugeben und ihn an den Firewall-Checker zu binden. Dieses Dokument konzentriert sich nur auf den ersten getesteten Port (5060), die Vorgehensweise ist jedoch für alle anderen Ports gleich.
Das Bild oben zeigt die folgenden Schritte:
- Der lokale 3CX-Server mit der IP-Adresse 192.168.3.159 sendet eine klassische Stun-Anfrage an stun.3cx.com mit der IP 198.50.247.220.
- Vom lokalen Port 5060 UDP.
- Auf 3478, den Standard-Stun-Server-Port.
- Voraussetzung, dass der STUN-Server seine IP oder den Port NICHT ändern sollte, um auf diese Anfrage zu antworten.
Jede Anfrage verfügt über eine eindeutige „Transaktions-ID“, um zuverlässig sicherzustellen, dass die empfangenen Daten zur ursprünglichen Anfrage gehören. In seltenen Fällen kann es vorkommen, dass der Server mehrere Anfragen sendet, jedoch nie eine Antwort erhält, wie unten gezeigt. Dies impliziert Folgendes:
a) Der ausgehende Datenverkehr wurde von der Firewall blockiert oder b) Es wurde kein Datenverkehr zurück an den Server weitergeleitet. Überprüfen Sie in beiden Fällen Ihre Firewall-Einstellungen!
Der Stun-Server antwortet dann mit:
- Eine bindende Antwort auf die Anfragen
- Definiert dann, dass die öffentliche IP und der öffentliche Port, von dem aus die Anfrage gesendet wurde, dem Port 5060 entsprechen und die IP-Adresse XX.XX.96.162 ist.
Basierend auf der vorherigen Definition funktioniert die Porterhaltung, da der Stun-Server die PBX auf dem definierten Port sehen kann. Wenn Sie im Feld „Mapped-Address“ einen anderen Port sehen, schlägt die Firewall-Prüfung fehl und die Porterhaltung funktioniert NICHT richtig. In diesem Fall müssen Sie sich an den Firewall-Hersteller wenden, um das Problem zu beheben.
Test 2
In Test 2 sendet der Server eine Anfrage an denselben Stun-Server wie zuvor.
Jedoch,
- Der 3CX-Server markiert die Anfrage als anders als zuvor und setzt „Change IP and Change Port“ auf (1). Das bedeutet, dass der Stun-Server seine Antwort an 3CX zurücksenden sollte, allerdings von einer IP-Adresse und einem Port, die der Firewall nun unbekannt sind und eine Antwort auf die Anfrage erwarten.
- Es ist klar, dass der Server dieselbe Anfrage dreimal gesendet hat, ohne eine Antwort vom Stun-Server zu erhalten. Dies weist darauf hin, dass Full-Cone-NAT nicht funktioniert.
Im Vergleich zu Test 1, bei dem der 3CX-Server aktiv Daten an den Stun-Server sendet und eine Antwort erhält, zeigt Test 2, dass die Daten von einer Quelle zurückkommen, mit der 3CX noch nie kommuniziert hat (d. h. dem Audioserver eines VoIP-Anbieters) und auch nicht in der Lage, jede Antwort zu erhalten. Wenden Sie sich in diesem Fall an den Firewall-Hersteller, um das Problem zu beheben.
Die richtige Antwort wäre, im zweiten Test Daten zu empfangen, wobei die „Mapped-Address“ für IP und Port genau die gleiche ist wie im Test 1.
Wenn Sie wissen möchten, woher der Datenverkehr gekommen sein sollte, überprüfen Sie Ihre Firewall-Protokolle auf die IP-Adressen der 3CX-Stun-Server. Die Antwort sollte von den 3CX-Stun-Servern kommen, gelangte jedoch nie zur NIC von 3CX.
SIP ALG Test (seit V15.5 SP1)
Zusätzlich zum bestehenden NAT-Test prüft 3CX, ob in der Firewall SIP ALG aktiviert ist. Kurz gesagt handelt es sich bei SIP ALG um Funktionen einiger Firewall-Geräte, die neben der Zugriffsliste von und nach IP/Ports auch den Inhalt der Pakete überprüfen. In diesem Fall SIP. Für den Administrator von 3CX kann dies zu zahlreichen Problemen führen. Da die Änderungen an den SIP-Nachrichten über einen Zwischenakteur vorgenommen werden, werden diese Änderungen in den auf 3CX erstellten Traces nicht angezeigt. Sie können jedoch zu Inkompatibilitätsproblemen mit externen IP-Telefonen oder VoIP-Anbietern führen.
Validierung: 3CX generiert eine generische INVITE-Nachricht und sendet sie an einen von 3CX gehosteten Onlinedienst. Mit Ausnahme der öffentlichen IP-Adresse werden alle anderen Informationen generisch wiedergegeben.
3CX local generiert einen CRC32-Hash-Wert aus der gesendeten Nachricht und erwartet im Gegenzug eine Antwort vom Cloud-Dienst, dass der Hash denselben Wert haben wird.
Wenn der Rückgabewert „X-CSREQ“ mit dem lokal berechneten Wert übereinstimmt, wird davon ausgegangen, dass SIP ALG die Nachricht nicht manipuliert hat oder nicht vorhanden ist. Wenn die Werte nicht übereinstimmen, zeigt der Test, dass ein Akteur zwischen 3CX und dem Onlinedienst den Inhalt verändert hat = SIP ALG.
Auf Validierungsbasis kann der erwartete Hash-Wert berechnet werden, vorausgesetzt, Wireshark hat den ausgehenden INVITE an den SIP-ALG-Erkennungsdienst erfasst.
Klicken Sie mit der rechten Maustaste auf die von 3CX gesendete Einladung, Kopieren, Bytes, Hex-Stream. Öffnen Sie: http://www.sunshine2k.de/coding/javascript/crc/crc_js.html
und fügen Sie den kopierten Hex-Stream in die CRC-Eingabedaten ein
Das angegebene Ergebnis muss mit dem zurückgegebenen Wert übereinstimmen.
Letztes Update
Dieses Dokument wurde zuletzt am 19. September 2023 aktualisiert.
