SCCP-ALG
Das Skinny Client Control Protocol (SCCP) ist ein einfaches und leichtes Protokoll, das relativ wenig Computerverarbeitung erfordert. SCCP-Clients verwenden TCP/IP, um mit Call Manager-Anwendungen in einem Cluster zu kommunizieren.
Grundlegendes zu SCCP-ALGs
Das Skinny Client Control Protocol (SCCP) ist ein proprietäres Protokoll von Cisco zur Anrufsignalübertragung. Skinny basiert auf einer Call-Agent-basierten Call-Control-Architektur. Das Kontrollprotokoll verwendet binärcodte Frames, die auf TCP-Frames codiert sind, die an bekannte TCP-Portnummernziele gesendet werden, um RTP-Mediensitzungen einzurichten und abreißen zu können.
Das SCCP-Protokoll verhandelt auf dieselbe Weise wie andere Anrufsteuerungsprotokolle Die Parameter der Medienendpunkte – insbesondere die RtP-Portnummer (Real-Time Transport Protocol) und die IP-Adresse der Medienterminierung – durch Einbettung von Informationen in die Steuerpakete. Das SCCP Application Layer Gateway (ALG) analysiert diese Steuerpakete und ermöglicht den Datenfluss von Medien- und Steuerpaketen durch das System.
Die SCCP-ALG implementiert auch die Geschwindigkeitsbegrenzung von Anrufen und trägt dazu bei, kritische Ressourcen vor Überlastung und Denial-of-Service-Angriffen (DoS) zu schützen.
Die folgenden Funktionen werden vom SCCP ALG in Junos OS implementiert:
Validierung von SCCP-Protokolldateneinheiten
Übersetzung von eingebetteten IP-Adressen und Portnummern
Zuweisung von Firewall-Ressourcen (Pinholes und Gates) zur Weitergabe von Medien
Veraltete Leerlaufanrufe
Konfigurations-API für SCCP-ALG-Parameter
Betriebsmodus-API zur Anzeige von Zählern, Status und Statistiken
In der SCCP-Architektur übernimmt ein Proxy, der als Call Manager bekannt ist, den größten Teil der Verarbeitung. IP-Telefone, auch Endstationen genannt, führen den SCCP-Client aus und verbinden sich über TCP an Port 2000 mit einem primären (und, falls vorhanden, einem sekundären) Anrufmanager und registrieren sich beim primären Anrufmanager. Diese Verbindung wird dann verwendet, um Anrufe herzustellen, die an den Oder vom Client kommen.
Die SCCP-ALG unterstützt folgendes:
Anruffluss von einem SCCP-Client über den Call Manager zu einem anderen SCCP-Client.
Nahtloses Failover: Switches über alle laufenden Aufrufe an die Standby-Firewall während des Ausfalls der primären Firewall.
Voice-over-IP (VoIP) Signaling Payload Inspection: Untersucht die Nutzdaten eingehender VoIP-Signalübertragungspakete vollständig. Jeder fehlerhafte Paketangriff wird von der ALG blockiert.
SCCP Signaling Payload Inspection: Untersucht die Nutzdaten eingehender SCCP-Signalübertragungspakete vollständig. Jeder falschformierte Paketangriff wird von der ALG blockiert.
Zustandsbehaftete Verarbeitung: Ruft die entsprechenden VoIP-basierten Zustandscomputer auf, um die analysierten Informationen zu verarbeiten. Alle Nicht-Zustands- oder Out-of-Transaction-Pakete werden identifiziert und ordnungsgemäß gehandhabt.
Network Address Translation (NAT): Übersetzt alle eingebetteten IP-Adressen und Portinformationen in der Payload basierend auf den vorhandenen Routing-Informationen und Netzwerktopologien, falls erforderlich, mit der übersetzten IP-Adresse und Portnummer.
Erstellung und Verwaltung von Pinholes für VoIP-Datenverkehr: Identifiziert IP-Adressen und Portinformationen, die für Medien oder Signalübertragung verwendet werden, und öffnet (und schließt) dynamisch Pinholes, um die Medien sicher zu streamen.
Dieses Thema umfasst die folgenden Abschnitte:
- SCCP-Sicherheit
- SCCP-Komponenten
- SCCP-Transaktionen
- SCCP-Version
- SCCP-Steuernachrichten und RTP-Datenstrom
- SCCP-Meldungen
SCCP-Sicherheit
Das SCCP ALG umfasst die folgenden Sicherheitsfunktionen:
Zustandsgesteuerte Überprüfung von SCCP-Steuernachrichten über TCP und Validierung des Nachrichtenformats und Nachrichtenvalidität für den aktuellen Anrufstatus. Ungültige Nachrichten werden gelöscht.
Durchsetzung von Sicherheitsrichtlinien zwischen Cisco IP-Telefonen und Cisco Call Manager.
Schutz vor Ruffluten durch Geschwindigkeitsbegrenzung der Anzahl der von der ALG bearbeiteten Anrufe.
Nahtloses Failover von Anrufen, einschließlich der Anrufe, die im Falle eines Geräteausfalls in einer Cluster-Bereitstellung ausgeführt werden.
SCCP-Komponenten
Zu den wichtigsten Komponenten der SCCP-VoIP-Architektur gehören folgendes:
SCCP-Client
Der SCCP-Client läuft auf einem IP-Telefon, auch Endstation genannt, das SCCP für die Signalübertragung und das Tätigen von Anrufen verwendet. Damit ein SCCP-Client einen Anruf tätigen kann, muss er sich zuerst bei einem primären Und falls verfügbaren sekundären Anrufmanager registrieren. Die Verbindung zwischen dem Client und dem Call Manager erfolgt über TCP an Port 2000. Diese Verbindung wird dann verwendet, um Anrufe zum oder vom Client herzustellen. Die Übertragung von Medien erfolgt über RTP, UDP und IP.
Call Manager
Der Call Manager implementiert die SCCP Call Control Server-Software und hat die Gesamtkontrolle über alle Geräte und Kommunikation im SCCP VoIP-Netzwerk. Zu ihren Funktionen gehören das Definieren, Überwachen und Steuern von SCCP-Gruppen, Regionen von Zahlen und Routenpläne; Bereitstellung der Initialisierung, Zulassung und Registrierung von Geräten im Netzwerk; bereitstellung einer redundanten Datenbank mit Adressen, Telefonnummern und Nummernformaten; und den Kontakt mit den angerufenen Geräten oder deren Agenten zu initiieren, um logische Sitzungen zu erstellen, in denen die Sprachkommunikation fließen kann.
Cluster
Ein Cluster ist eine Sammlung von SCCP-Clients und ein Call Manager. Der Call Manager im Cluster erkennt alle SCCP-Clients im Cluster. Es kann mehr als einen Call Manager für die Sicherung in einem Cluster geben. Das Verhalten des Anrufmanagers variiert in jedem der folgenden Cluster-Szenarien:
Clusterintern, in dem der Call Manager jeden SCCP-Client erkennt und der Anruf zwischen SCCP-Clients desselben Clusters erfolgt.
Inter-Cluster, in dem der Call Manager für die Einrichtung des Anrufs mit einem anderen Call Manager kommunizieren muss, der H.323 verwendet.
Inter-Cluster-Anrufe, die den Gatekeeper zur Zugangskontrolle und Adressauflösung verwenden.
Das Verhalten des Anrufmanagers variiert auch mit den Anrufen zwischen einem SCCP-Client und einem Telefon in einem öffentlichen Telefonnetz (PSTN) und mit Anrufen zwischen einem SCCP-Client und einem Telefon in einer anderen administrativen Domäne, die H.323 verwendet.
SCCP-Transaktionen
SCCP-Transaktionen sind die Prozesse, die stattfinden müssen, damit ein SCCP-Aufruf fortgesetzt wird. SCCP-Transaktionen umfassen die folgenden Prozesse:
Client-Initialisierung
Zur Initialisierung muss der SCCP-Client die IP-Adresse des Anrufmanagers, seine eigene IP-Adresse und andere Informationen über das IP-Gateway und die DNS-Server festlegen. Die Initialisierung erfolgt über das lokale LAN. Der Client sendet eine DHCP-Anfrage (Dynamic Host Control Protocol), um eine IP-Adresse, die DNS-Serveradresse sowie den Namen und die Adresse des TFTP-Servers zu erhalten. Der Client benötigt den TFTP-Servernamen, um die Konfigurationsdatei mit dem Namen sepmacaddr.cnf herunterzuladen. Wenn der TFTP-Name nicht angegeben wird, verwendet der Client den Standarddateinamen im IP-Telefon. Der Client lädt dann die Konfigurationsdatei .cnf (xml) vom TFTP-Server herunter. CNF-Dateien enthalten die IP-Adresse oder Adressen des primären und sekundären Cisco Call Managers. Mit diesen Informationen kontaktiert der Kunde den Call Manager, um sich zu registrieren.
Client-Registrierung
Der SCCP-Client registriert sich nach der Initialisierung beim Anrufmanager über eine TCP-Verbindung am bekannten Standardport 2000. Der Client registriert sich, indem er dem Anrufmanager seine IP-Adresse, die MAC-Adresse des Telefons und andere Informationen wie Protokoll und Version zur Verfügung stellt. Der Client kann keine Anrufe initiieren oder empfangen, bevor er registriert ist. Keepalive-Nachrichten halten diese TCP-Verbindung zwischen dem Client und dem Anrufmanager offen, sodass der Client jederzeit Anrufe initiieren oder empfangen kann, sofern eine Richtlinie auf dem Gerät dies zulässt.
Anrufeinrichtung
Die Einrichtung von IP-Telefonanrufen mit SCCP wird immer vom Anrufmanager verwaltet. Nachrichten zur Anrufeinrichtung werden an den Anrufmanager gesendet, der Nachrichten zurückgibt, die dem Status des Anrufs entsprechen. Wenn die Anrufeinrichtung erfolgreich war und eine Richtlinie auf dem Gerät den Anruf zulässt, sendet der Anrufmanager die Nachrichten zur Medieneinrichtung an den Client.
Medieneinrichtung
Der Call Manager sendet die IP-Adresse und Portnummer der angerufenen Partei an den Anrufer. Der Anrufmanager sendet auch die Medien-IP-Adresse und die Portnummer der anrufenden Partei an den Angerufenen. Nach der Einrichtung der Medien werden Medien direkt zwischen Clients übertragen. Wenn der Anruf endet, wird der Call Manager informiert und beendet die Medienströme. Zu keinem Zeitpunkt während dieses Prozesses übergibt der Call Manager die Funktion der Anrufeinrichtung an den Client. Medien werden über RTP/UDP/IP direkt zwischen Clients gestreamt.
SCCP-Version
Ab Junos OS Version 12.1X46-D10 und Junos OS Version 17.3R1 unterstützt der SCCP-ALG SCCP-Versionen 16, 17 und 20 und mehrere SCCP-Meldungen wurden mit einem neuen Format aktualisiert. Cisco Call Manager (CM) Version 7 verwendet SCCP-Version 20.
SCCP-Steuernachrichten und RTP-Datenstrom
Abbildung 1 zeigt die SCCP-Steuernachrichten, die zum Einrichten und Abreißen eines einfachen Anrufs zwischen Telefon 1 und Telefon 2 verwendet wurden. Mit Ausnahme der OffHook-Nachricht, die den Anruf von Phone1 initiiert, und der OnHook-Nachricht, die das Ende des Anrufs signalisiert, werden alle Aspekte des Anrufs vom Anrufmanager gesteuert.
Anrufen
SCCP-Meldungen
In Tabelle 1, Tabelle 2, Tabelle 3 und Tabelle 4 werden die SCCP-Anrufmelde-IDs in den vier vom Gerät zulässigen Intervallen aufgeführt.
#define STATION_REGISTER_MESSAGE |
0x00000001 |
#define STATION_IP_PORT_MESSAGE |
0x00000002 |
#define STATION_ALARM_MESSAGE |
0x00000020 |
#define STATION_OPEN_RECEIVE_CHANNEL_ACK |
0x00000022 |
#define STATION_START_MEDIA_TRANSMISSION |
0x00000001 |
#define STATION_STOP_MEDIA_TRANSMISSION |
0x00000002 |
#define STATION_CALL_INFO_MESSAGE |
0x00000020 |
#define STATION_OPEN_RECEIVE_CHANNEL_ACK |
0x00000022 |
#define STATION_CLOSE_RECEIVE_CHANNEL |
0x00000106 |
#define STATION_REGISTER_TOKEN_REQ_MESSAGE |
0x00000029 |
#define STATION_MEDIA_TRANSMISSION_FAILURE |
0x0000002A |
#define STATION_OPEN_MULTIMEDIA_RECEIVE_CHANNEL_ACK |
0x00000031 |
#define STATION_OPEN_MULTIMEDIA_RECEIVE_CHANNEL |
0x00000131 |
#define STATION_START_MULTIMEDIA_TRANSMISSION |
0x00000132 |
#define STATION_STOP_MULTIMEDIA_TRANSMISSION |
0x00000133 |
#define STATION_CLOSE_MULTIMEDIA_RECEIVE_CHANNEL |
0x00000136 |
SCCP-ALG-Einschränkungen
Das SCCP ist ein proprietäres Protokoll von Cisco. Daher führt jede Änderung des Protokolls durch Cisco dazu, dass die SCCP-ALG-Implementierung kaputt geht. Es werden jedoch Problemumgehungen bereitgestellt, um die strikte Dekodierung zu umgehen und jede Protokolländerung ordnungsgemäß zu handhaben.
Bei Änderungen an den Richtlinien werden die Sitzungen ausfallen und wirken sich auf bereits etablierte SCCP-Aufrufe aus.
Die SCCP-ALG öffnet Pinholes, die während des Datenverkehrs oder der Medieninaktivität zusammenbrechen. Das bedeutet, dass bei einem vorübergehenden Verbindungsverlust die Mediensitzungen nicht wiederhergestellt werden.
Der Call Manager (CM) version 6.x und höher unterstützt im Chassis-Cluster-Modus keine TCP-Probe-Pakete. Infolgedessen brechen die vorhandenen SCCP-Sitzungen bei einem Failover aus. Sie können während des Failovers immer noch neue SCCP-Sitzungen erstellen.
Grundlegendes zu SCCP ALG Inaktiven Medien-Timeouts
Die Inaktive Timeout-Funktion hilft Ihnen, Netzwerkressourcen zu sparen und den Durchsatz zu maximieren.
Dieser Parameter gibt die maximale Dauer (in Sekunden) an, die ein Anruf ohne Mediendatenverkehr innerhalb einer Gruppe aktiv bleiben kann. Jedes Mal, wenn ein RtP-Paket (Real-Time Transport Protocol) oder rt-Time Control Protocol (RTCP) innerhalb eines Anrufs auftritt, wird dieser Timeout zurückgesetzt. Wenn der Zeitraum der Inaktivität diese Einstellung überschreitet, werden die Gates geschlossen, die das Skinny Client Control Protocol (SCCP) für Medien geöffnet hat. Die Standardeinstellung ist 120 Sekunden und der Bereich beträgt 10 bis 2550 Sekunden. Beachten Sie, dass bei einem Timeout, während Ressourcen für Medien (Sitzungen und Pinholes) entfernt werden, der Anruf nicht beendet wird.
SCCP ALG-Konfiguration – Übersicht
Das Skinny Client Control Protocol Application Layer Gateway (SCCP ALG) ist standardmäßig auf dem Gerät aktiviert– es ist keine Aktion erforderlich, um es zu aktivieren. Sie können jedoch den SCCP-ALG-Betrieb mithilfe der folgenden Anweisungen fein abstimmen:
Sparen Sie Netzwerkressourcen und maximieren Sie den Durchsatz. Anweisungen finden Sie unter Beispiel: Festlegen von SCCP ALG Inaktiven Medien-Timeouts.
Aktivieren Sie unbekannte Nachrichten, die übermittelt werden, wenn sich die Sitzung im Network Address Translation (NAT)-Modus und Im Routenmodus befindet. Anweisungen finden Sie unter Beispiel: Zulassen unbekannter SCCP-ALG-Nachrichtentypen.
Schützen Sie die SCCP-Clients vor Denial-of-Service(DoS)-Flood-Angriffen. Anweisungen finden Sie unter Beispiel: Konfigurieren von SCCP ALG DoS-Angriffsschutz.
Beispiel: Festlegen von SCCP ALG Inaktiven Medien-Timeouts
Dieses Beispiel zeigt, wie Sie den Wert für inaktive Medien-Timeouts für die SCCP-ALG festlegen.
Anforderungen
Bevor Sie beginnen, überprüfen Sie den Parameter, der verwendet wird, um anzugeben, wie lange ein Anruf maximal (in Sekunden) ohne Mediendatenverkehr innerhalb einer Gruppe aktiv bleiben kann. Siehe Grundlegendes zu SCCP ALG Inaktiven Medien-Timeouts.
Übersicht
Jedes Mal, wenn ein RTP- oder RTCP-Paket innerhalb eines Anrufs auftritt, wird dieser Timeout zurückgesetzt. Wenn der Zeitraum der Inaktivität diese Einstellung überschreitet, werden die Tore, die das SCCP für Medien geöffnet hat, geschlossen. In diesem Beispiel wird das Timeout für Medieninaktivität auf 90 Sekunden festgelegt.
Konfiguration
Verfahren
Gui-Schnellkonfiguration
Schritt-für-Schritt-Verfahren
So setzen Sie den inaktiven Timeout für die SCCP-ALG:
Wählen Sie Configure>Security>ALG aus.
Wählen Sie die Registerkarte SCCP aus.
Geben Sie im Feld Timeout für inaktive Medien die Eingabe ein
90.Klicken Sie auf OK , um Ihre Konfiguration zu überprüfen und als Kandidatenkonfiguration zu speichern.
Wenn Sie mit der Konfiguration des Geräts fertig sind, klicken Sie auf Commit-Optionen>Commit.
Schritt-für-Schritt-Verfahren
So setzen Sie den inaktiven Timeout für die SCCP-ALG:
Konfigurieren Sie den Wert des SCCP ALG inaktiven Medien-Timeouts.
[edit] user@host# set security alg sccp inactive-media-timeout 90
Wenn Sie mit der Konfiguration des Geräts fertig sind, bestätigen Sie die Konfiguration.
[edit] user@host# commit
Überprüfung
Geben Sie den Befehl ein, um zu überprüfen, ob die show security alg sccp Konfiguration ordnungsgemäß funktioniert.
Beispiel: Zulassen unbekannter SCCP-ALG-Nachrichtentypen
Dieses Beispiel zeigt, wie Sie die SCCP-ALG so konfigurieren, dass unbekannte SCCP-Nachrichtentypen sowohl im NAT- als auch im Routenmodus zugelassen werden.
Anforderungen
Legen Sie zunächst fest, ob neue und unbekannte SCCP-Nachrichtentypen für das Gerät berücksichtigt werden sollen.
Übersicht
Um die aktuelle Entwicklung des Skinny Client Control Protocol (SCCP) zu unterstützen, können Sie Datenverkehr zulassen, der neue SCCP-Nachrichtentypen enthält. Mit der unbekannten SCCP-Nachrichtentypfunktion können Sie das Gerät so konfigurieren, dass SCCP-Datenverkehr mit unbekannten Nachrichtentypen sowohl im Network Address Translation (NAT)-Modus als auch im Routenmodus akzeptiert wird.
Standardmäßig werden unbekannte (nicht unterstützte) Nachrichten abgezogen. Wir empfehlen nicht, unbekannte Nachrichten zuzulassen, da sie die Sicherheit gefährden können. In einer sicheren Test- oder Produktionsumgebung kann der unbekannte Befehl vom SCCP-Nachrichtentyp jedoch zur Lösung von Interoperabilitätsproblemen mit geräten unterschiedlichen Anbietern nützlich sein. Die Genehmigung unbekannter SCCP-Nachrichten kann Ihnen helfen, Ihr Netzwerk in Betrieb zu bringen, sodass Sie später Ihren Voice-over-IP -Datenverkehr (VoIP) analysieren können, um zu ermitteln, warum einige Nachrichten gelöscht wurden.
Beachten Sie, dass der unbekannte SCCP-Nachrichtentyp nur auf empfangene Pakete angewendet wird, die als unterstützte VoIP-Pakete identifiziert wurden. Wenn ein Paket nicht identifiziert werden kann, wird es immer gelöscht. Wenn ein Paket als unterstütztes Protokoll identifiziert wird und Sie das Gerät so konfiguriert haben, dass unbekannte Nachrichtentypen zugelassen werden, wird die Nachricht ohne Verarbeitung weitergeleitet.
Konfiguration
Verfahren
Gui-Schnellkonfiguration
Schritt-für-Schritt-Verfahren
So konfigurieren Sie die SCCP-ALG so, dass unbekannte Nachrichtentypen zugelassen werden:
Wählen Sie Configure>Security>ALG aus.
Wählen Sie die Registerkarte SCCP aus.
Aktivieren Sie das Kontrollkästchen "NAT anwenden zulassen" .
Aktivieren Sie das Kontrollkästchen "Routing zulassen" .
Klicken Sie auf OK , um Ihre Konfiguration zu überprüfen und als Kandidatenkonfiguration zu speichern.
Wenn Sie mit der Konfiguration des Geräts fertig sind, klicken Sie auf Commit-Optionen>Commit.
Schritt-für-Schritt-Verfahren
So konfigurieren Sie die SCCP-ALG so, dass unbekannte Nachrichtentypen zugelassen werden:
Lassen Sie unbekannte Nachrichtentypen passieren, wenn sich die Sitzung entweder im NAT-Modus oder im Routenmodus befindet.
[edit] user@host# set security alg sccp application-screen unknown-message permit-nat-applied permit-routed
Wenn Sie mit der Konfiguration des Geräts fertig sind, bestätigen Sie die Konfiguration.
[edit] user@host# commit
Überprüfung
Geben Sie den Befehl ein, um zu überprüfen, ob die show security alg sccp Konfiguration ordnungsgemäß funktioniert.
Beispiel: Konfigurieren von SCCP ALG DoS-Angriffsschutz
Dieses Beispiel zeigt, wie Sie den Verbindungsflutschutz für die SCCP-ALG konfigurieren.
Anforderungen
Legen Sie zunächst fest, ob das SCCP-Medien-Gateway vor DoS-Flood-Angriffen geschützt werden soll.
Übersicht
Sie können Skinny Client Control Protocol Application Layer Gateway (SCCP ALG)-Clients vor Denial-of-Service (DoS)-Flood-Angriffen schützen, indem Sie die Anzahl der Anrufe begrenzen, die sie verarbeiten möchten.
Wenn Sie den SCCP-Call Flood-Schutz konfigurieren, setzt die SCCP-ALG alle Anrufe ab, die den von Ihnen festgelegten Schwellenwert überschreiten. Der Bereich beträgt 2 bis 1000 Anrufe pro Sekunde pro Client, der Standard ist 20.
In diesem Beispiel ist das Gerät so konfiguriert, dass alle Anrufe über 500 pro Sekunde pro Client unterbrochen werden.
Konfiguration
Verfahren
Gui-Schnellkonfiguration
Schritt-für-Schritt-Verfahren
So konfigurieren Sie den Hochwasserschutz für die SCCP-ALG:
Wählen Sie Configure>Security>ALG aus.
Wählen Sie die Registerkarte SCCP aus.
Geben Sie im Feld Call Flood-Schwellenwert den Wert
500ein.Klicken Sie auf OK , um Ihre Konfiguration zu überprüfen und als Kandidatenkonfiguration zu speichern.
Wenn Sie mit der Konfiguration des Geräts fertig sind, klicken Sie auf Commit-Optionen>Commit.
Schritt-für-Schritt-Verfahren
So konfigurieren Sie den Hochwasserschutz für die SCCP-ALG:
Konfigurieren Sie den DoS-Angriffsschutz:
[edit] user@host# set security alg sccp application-screen call-flood threshold 500
Wenn Sie mit der Konfiguration des Geräts fertig sind, bestätigen Sie die Konfiguration.
[edit] user@host# commit
Überprüfung
Geben Sie den Befehl ein, um zu überprüfen, ob die show security alg sccp Konfiguration ordnungsgemäß funktioniert.
Beispiel: Konfigurieren des SCCP ALG-Anrufmanagers oder TFTP-Servers in der privaten Zone
Dieses Beispiel zeigt, wie Sie statische NAT an der ausgehenden Schnittstelle eines Geräts von Juniper Networks konfigurieren, damit sich Anrufer in einer öffentlichen Zone bei einem SCCP ALG-Call Manager oder einem TFTP-Server in einer privaten Zone registrieren können.
Anforderungen
Bevor Sie beginnen, verstehen Sie die NAT-Unterstützung mit SCCP ALG. Siehe Grundlegendes zu SCCP-ALGs.
Übersicht
In diesem Beispiel (siehe Abbildung 2) dient ein einzelnes Gerät als Call Manager oder TFTP-Server. Der Call Manager oder TFTP-Server und Phone1 sind an die private Zone angeschlossen, und phone2 ist an die öffentliche Zone angeschlossen. Sie konfigurieren einen statischen NAT-Regelsatz für den Call Manager- oder TFTP-Server, sodass phone2 beim Hochbooten den TFTP-Server kontaktiert und die IP-Adresse des Anrufmanagers erhält. Sie erstellen dann eine Richtlinie namens in-pol, um SCCP-Datenverkehr von der öffentlichen in die private Zone zu erlauben, und eine Richtlinie, die out-pol aufgerufen wird, damit phone1 telefonieren kann.
Wir empfehlen, die IP-Adresse des Call Managers, die sich in der TFTP-Serverkonfigurationsdatei (sep <mac_addr>.cnf) befindet, in die NAT-IP-Adresse des Call Managers zu ändern.
Topologie
Abbildung 2 zeigt den Call Manager oder TFTP-Server in der privaten Zone.
In diesem Beispiel konfigurieren Sie NAT wie folgt:
-
Erstellen Sie einen statischen NAT-Regelsatz namens "to-proxy" mit einer Regel namens phone2, um Pakete aus der öffentlichen Zone mit der Zieladresse 172.16.1.2/32 abzugleichen. Für übereinstimmende Pakete wird die Ziel-IP-Adresse in die private Adresse 10.1.1.4/32 übersetzt.
-
Konfigurieren Sie Proxy-ARP für die Adresse 172.16.1.2/32 auf der Schnittstelle ge-0/0/1.0. Auf diese Weise kann das System auf ARP-Anfragen reagieren, die über die Schnittstelle für diese Adressen eingehen.
-
Konfigurieren Sie einen zweiten Regelsatz namens Phones mit einer Regel namens phone1, um Schnittstellen-NAT für die Kommunikation von Phone1 zu Phone2 zu aktivieren.
Konfiguration
Verfahren
CLI-Schnellkonfiguration
Um diesen Abschnitt des Beispiels schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern alle erforderlichen Details, um ihre Netzwerkkonfiguration zu entsprechen, kopieren Sie die Befehle, fügen Sie sie auf Hierarchieebene in die [edit] CLI ein, und geben Sie dann aus dem Konfigurationsmodus ein commit .
set interfaces ge-0/0/0 unit 0 family inet address 10.1.1.1/24 set interfaces ge-0/0/1 unit 0 family inet address 172.16.1.1/24 set security zones security-zone private interfaces ge-0/0/0.0 set security zones security-zone public interfaces ge-0/0/1.0 set security address-book book1 address phone1 10.1.1.3/32 set security address-book book1 address cm-tftp_server 10.1.1.4/32 set security address-book book1 attach zone private set security address-book book2 address phone2 172.16.1.4/32 set security address-book book2 attach zone public set security nat source rule-set phones from zone private set security nat source rule-set phones to zone public set security nat source rule-set phones rule phone1 match source-address 10.1.1.3/32 set security nat source rule-set phones rule phone1 then source-nat interface set security nat static rule-set to-proxy from zone public set security nat static rule-set to-proxy rule phone2 match destination-address 172.16.1.2/32 set security nat static rule-set to-proxy rule phone2 then static-nat prefix 10.1.1.4/32 set security nat proxy-arp interface ge-0/0/1.0 address 172.16.1.2/32 set security policies from-zone public to-zone private policy in-pol match source-address phone2 set security policies from-zone public to-zone private policy in-pol match destination-address cm-tftp_server set security policies from-zone public to-zone private policy in-pol match destination-address phone1 set security policies from-zone public to-zone private policy in-pol match application junos-sccp set security policies from-zone public to-zone private policy in-pol then permit set security policies from-zone private to-zone public policy out-pol match source-address any set security policies from-zone private to-zone public policy out-pol match destination-address phone2 set security policies from-zone private to-zone public policy out-pol match application junos-sccp set security policies from-zone private to-zone public policy out-pol then permit set security policies from-zone private to-zone private policy tftp-pol match source-address any set security policies from-zone private to-zone private policy tftp-pol match destination-address any set security policies from-zone private to-zone private policy tftp-pol match application junos-tftp set security policies from-zone private to-zone private policy tftp-pol then permit
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Anweisungen dazu finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI-Benutzerhandbuch.
So konfigurieren Sie NAT für einen SCCP ALG Call Manager oder einen TFTP-Server in einer privaten Zone:
-
Konfigurieren Sie Schnittstellen.
[edit] user@host# set interfaces ge-0/0/0 unit 0 family inet address 10.1.1.1/24 user@host# set interfaces ge-0/0/1 unit 0 family inet address 172.16.1.1/24
-
Erstellen Sie Sicherheitszonen.
[edit security zones] user@host# set security-zone private interfaces ge-0/0/0.0 user@host# set security-zone public interfaces ge-0/0/1.0
-
Erstellen Sie Adressbücher und fügen Sie Zonen an.
[edit security address-book book1] user@host# set address phone1 10.1.1.3/32 user@host# set address cm-tftp_server 10.1.1.4/32 user@host# set attach zone private
[edits security address-book book2] user@host# set address phone2 172.16.1.4/32 user@host# set attach zone public
-
Erstellen Sie einen Regelsatz für statische NAT, und weisen Sie ihm eine Regel zu.
[edit security nat static rule-set to-proxy] user@host# set from zone public user@host# set rule phone2 match destination-address 172.16.1.2/32 user@host# set rule phone2 then static-nat prefix 10.1.1.4/32
-
Konfigurieren Sie Proxy-ARP.
[edit security nat] user@host# set proxy-arp interface ge-0/0/1.0 address 172.16.1.2/32
-
Konfigurieren Sie Schnittstellen-NAT für die Kommunikation von Phone1 zu Phone2.
[edit security nat source rule-set phones] user@host# set from zone private user@host# set to zone public user@host# set rule phone1 match source-address 10.1.1.3/32 user@host# set rule phone1 then source-nat interface
-
Konfigurieren Sie eine Richtlinie, um Datenverkehr von der öffentlichen Zone zur privaten Zone zuzulassen.
[edit security policies from-zone public to-zone private policy in-pol] user@host# set match source-address phone2 user@host# set match destination-address cm-tftp_server user@host# set match destination-address phone1 user@host# set match application junos-sccp user@host# set then permit
-
Konfigurieren Sie eine Richtlinie, um Datenverkehr von der privaten Zone zur öffentlichen Zone zuzulassen.
[edit security policies from-zone private to-zone public policy out-pol] user@host# set match source-address any user@host# set match destination-address phone2 user@host# set match application junos-sccp user@host# set then permit
-
Konfigurieren Sie eine Richtlinie, um Datenverkehr von phone1 zum CM/TFTP-Server zuzulassen.
[edit security policies from-zone private to-zone private policy tftp-pol] user@host# set match source-address any user@host# set match destination-address any user@host# set match application junos-tftp user@host# set then permit
Ergebnisse
Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie die show interfacesBefehle , show security zones, , show security address-bookshow security natund show security policies eingeben. Wenn in der Ausgabe die beabsichtigte Konfiguration nicht angezeigt wird, wiederholen Sie die Konfigurationsanweisungen in diesem Beispiel, um sie zu korrigieren.
[edit]
user@host# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 10.1.1.1/24;
}
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 172.16.1.1/24;
}
}
}
[edit]
user@host# show security zones
security-zone private {
interfaces {
ge-0/0/0.0;
}
}
security-zone public {
interfaces {
ge-0/0/1.0;
}
}
[edit]
user@host# show security address-book
book1 {
address phone1 10.1.1.3/32;
address cm-tftp_server 10.1.1.4/32;
attach {
zone private;
}
}
book2 {
address phone2 172.16.1.4/32;
attach {
zone public;
}
}
[edit]
user@host# show security nat
source {
rule-set phones {
from zone private;
to zone public;
rule phone1 {
match {
source-address 10.1.1.3/32;
}
then {
source-nat {
interface;
}
}
}
}
}
static {
rule-set to-proxy {
from zone public;
rule phone2 {
match {
destination-address 172.16.1.2/32;
}
then {
static-nat prefix 10.1.1.4/32;
}
}
}
}
proxy-arp {
interface ge-0/0/1.0 {
address {
172.16.1.2/32;
}
}
}
[edit]
user@host# show security policies
from-zone public to-zone private {
policy in-pol {
match {
source-address phone2;
destination-address cm-tftp_server;
destination-address phone1;
application junos-sccp;
}
then {
permit;
}
}
}
from-zone private to-zone public {
policy out-pol {
match {
source-address any;
destination-address phone2;
application junos-sccp;
}
then {
permit;
}
}
}
from-zone private to-zone private {
policy tftp-pol {
match {
source-address any;
destination-address any;
application junos-tftp;
}
then {
permit;
}
}
}
Wenn Sie mit der Konfiguration des Geräts fertig sind, geben Sie im Konfigurationsmodus ein commit .
Überprüfung
Führen Sie die folgenden Aufgaben durch, um zu bestätigen, dass die Konfiguration ordnungsgemäß funktioniert:
- Überprüfung der Verwendung von Quell-NAT-Regel
- Überprüfung der statischen NAT-Konfiguration
- SCCP-ALG überprüfen
- Überprüfung der Sicherheitsrichtlinien von SIP ALG
Überprüfung der Verwendung von Quell-NAT-Regel
Zweck
Stellen Sie sicher, dass Datenverkehr vorhanden ist, der der Quell-NAT-Regel entspricht.
Aktion
Geben Sie im Betriebsmodus den show security nat source rule all Befehl ein.
user@host> show security nat source rule all
Total rules: 1
Total referenced IPv4/IPv6 ip-prefixes: 3/0
source NAT rule: phone1 Rule-set: phones
Rule-Id : 3
Rule position : 2
From zone : private
To zone : public
Match
Source addresses : 10.1.1.3 - 10.1.1.3
Destination port : 0 - 0
Action : interface
Persistent NAT type : N/A
Persistent NAT mapping type : address-port-mapping
Inactivity timeout : 0
Max session number : 0
Translation hits : 0
Bedeutung
Das Translation hits Feld zeigt, dass es keinen Datenverkehr gibt, der der Quell-NAT-Regel entspricht.
Überprüfung der statischen NAT-Konfiguration
Zweck
Stellen Sie sicher, dass Datenverkehr vorhanden ist, der dem statischen NAT-Regelsatz entspricht.
Aktion
Geben Sie im Betriebsmodus den show security nat static rule phone2 Befehl ein.
user@host> show security nat static rule phone2
Static NAT rule: phone2 Rule-set: to-proxy Rule-Id : 1 Rule position : 1 From zone : public Destination addresses : 172.16.1.2 Host addresses : 10.1.1.4 Netmask : 32 Host routing-instance : N/A Translation hits : 0
Bedeutung
Das Translation hits Feld zeigt, dass es keinen Datenverkehr gibt, der dem Quell-NAT-Regelsatz entspricht.
SCCP-ALG überprüfen
Zweck
Stellen Sie sicher, dass SCCP-ALG aktiviert ist.
Aktion
Geben Sie im Betriebsmodus den show security alg status | match sccp Befehl ein.
user@host> show security alg status | match sccp
SCCP : Enabled
Bedeutung
Die Ausgabe zeigt den SCCP-ALG-Status wie folgt:
-
Aktiviert: Zeigt, dass SCCP-ALG aktiviert ist.
-
Deaktiviert: Zeigt, dass die SCCP-ALG deaktiviert ist.
Überprüfung der Sicherheitsrichtlinien von SIP ALG
Zweck
Stellen Sie sicher, dass die statische NAT zwischen öffentlicher und privater Zone festgelegt ist.
Aktion
Geben Sie im Betriebsmodus den show security policies Befehl ein.
user@host> show security policies
from-zone private to-zone public {
policy out-pol {
match {
source-address any;
destination-address phone2;
application junos-sccp;
}
then {
permit;
}
}
}
from-zone public to-zone private {
policy in-pol {
match {
source-address phone2;
destination-address [ cm-tftp_server phone1 ];
application junos-sccp;
}
then {
permit;
}
}
}
from-zone private to-zone private {
policy tftp-pol {
match {
source-address any;
destination-address any;
application junos-tftp;
}
then {
permit;
}
}
}
Bedeutung
Die Beispielausgabe zeigt, dass die statische NAT zwischen öffentlicher und privater Zone festgelegt ist.
Überprüfung der SCCP-ALG-Konfigurationen
- SCCP-ALG überprüfen
- Verifizieren von SCCP-ALG-Anrufen
- Überprüfung der SCCP-ALG-Anrufdetails
- Überprüfung der SCCP-ALG-Zähler
SCCP-ALG überprüfen
Zweck
Anzeige der SCCP-Verifizierungsoptionen.
Aktion
Geben Sie über die CLI den show security alg sccp Befehl ein.
user@host> show security alg sccp ? Possible completions: calls Show SCCP calls counters Show SCCP counters
Bedeutung
Die Ausgabe zeigt eine Liste aller SCCP-Verifizierungsparameter. Überprüfen Sie die folgenden Informationen:
Alle SCCP-Aufrufe
Zähler für alle SCCP-Aufrufe
Siehe auch
Verifizieren von SCCP-ALG-Anrufen
Zweck
Liste aller SCCP-Aufrufe anzeigen
Aktion
Geben Sie über die CLI den show security alg sccp calls Befehl ein.
user@host> show security alg sccp calls Possible completions: calls Show SCCP calls counters Show SCCP counters endpoints Show SCCP endpoints
Bedeutung
Die Ausgabe zeigt eine Liste aller SCCP-Verifizierungsparameter. Überprüfen Sie die folgenden Informationen:
Alle SCCP-Aufrufe
Zähler für alle SCCP c Alls
Informationen zu allen SCCP-Endgeräten
Überprüfung der SCCP-ALG-Anrufdetails
Zweck
Zeigt Details zu allen SCCP-Anrufen an.
Aktion
Geben Sie über die CLI den show security alg sccp calls detail Befehl ein.
user@host> show security alg sccp calls detail
Client IP address: 11.0.102.91
Client zone: 7
Call Manager IP: 13.0.99.226
Conference ID: 16789504
Resource manager group: 2048
SCCP channel information:
Media transmit channel address (IP address/Port): 0.0.0.0:0
Media transmit channel translated address (IP address/Port): 0.0.0.0:0
Media transmit channel pass-through party ID (PPID): 0
Media transmit channel resource ID: 0
Media receive channel address (IP address/Port): 11.0.102.91:20060
Media receive channel translated address (IP address/Port): 25.0.0.1:1032
Media receive channel pass-through party ID (PPID): 16934451
Media receive channel resource ID: 8185
Multimedia transmit channel address (IP address/Port): 0.0.0.0:0
Multimedia transmit channel translated address (IP address/Port): 0.0.0.0:0
Multimedia transmit channel pass-through party ID (PPID): 0
Multimedia transmit channel resource ID: 0
Multimedia receive channel address (IP address/Port): 0.0.0.0:0
Multimedia receive channel translated address (IP address/Port): 0.0.0.0:0
Multimedia receive channel pass-through party ID (PPID): 0
Multimedia receive channel resource ID: 0
Total number of calls = 1
Bedeutung
Die Ausgabe zeigt eine Liste aller SCCP-Verifizierungsparameter. Überprüfen Sie die folgenden Informationen:
Client-Zone
IP-Adresse des Call Managers: 13.0.99.226
Konferenz-ID
Resource Manager-Gruppe
SCCP-Kanalinformationen
Gesamtzahl der Anrufe
Überprüfung der SCCP-ALG-Zähler
Zweck
Eine Liste aller SCCP-Zähler anzeigen
Aktion
Wählen Sie in der J-Web-Schnittstelle Monitor>ALGs>SCCP>Counters aus. Geben Sie alternativ über die CLI den show security alg sccp counters Befehl ein.
user@host> show security alg sccp ounters SCCP call statistics: Active client sessions : 0 Active calls : 0 Total calls : 0 Packets received : 0 PDUs processed : 0 Current call rate : 0 Error counters: Packets dropped : 0 Decode errors : 0 Protocol errors : 0 Address translation errors : 0 Policy lookup errors : 0 Unknown PDUs : 0 Maximum calls exceeded : 0 Maximum call rate exceeded : 0 Initialization errors : 0 Internal errors : 0 Nonspecific error : 0 No active calls to delete : 0 No active client sessions to delete : 0 Session cookie create errors : 0 Invalid NAT cookie detected : 0
Bedeutung
Die Ausgabe zeigt eine Liste aller SCCP-Verifizierungsparameter. Überprüfen Sie die folgenden Informationen:
SCCP-Anrufstatistiken
Fehlerindikatoren