ALG-Anwendungen
Konfigurieren von Anwendungseigenschaften
Um Anwendungseigenschaften zu konfigurieren, schließen Sie die application
Anweisung auf der [edit applications]
Hierarchieebene ein:
[edit applications] application application-name { application-protocol protocol-name; child-inactivity-timeout seconds; destination-port port-number; gate-timeout seconds; icmp-code value; icmp-type value; inactivity-timeout value; protocol type; rpc-program-number number; snmp-command command; source-port port-number; ttl-threshold value; uuid hex-value; }
Sie können Anwendungsobjekte gruppieren, indem Sie die application-set
Anweisung konfigurieren. Weitere Informationen finden Sie unter Konfigurieren von Anwendungssätzen.
Dieser Abschnitt enthält die folgenden Aufgaben zum Konfigurieren von Anwendungen:
- Konfigurieren eines Anwendungsprotokolls
- Konfigurieren des Netzwerkprotokolls
- Konfigurieren des ICMP-Codes und -Typs
- Konfigurieren von Quell- und Zielports
- Konfigurieren der Zeitüberschreitung bei Inaktivität
- Konfigurieren einer IKE ALG-Anwendung
- Konfigurieren von SIP
- Konfigurieren eines SNMP-Befehls für den Paketabgleich
- Konfigurieren einer RPC-Programmnummer
- Konfigurieren des TTL-Schwellenwerts
- Konfigurieren eines Universal Unique Identifier
Konfigurieren eines Anwendungsprotokolls
Mit der application-protocol
Anweisung können Sie angeben, welche der unterstützten Anwendungsprotokolle (ALGs) konfiguriert und in eine Anwendungsmenge für die Dienstverarbeitung aufgenommen werden sollen. Um Anwendungsprotokolle zu konfigurieren, fügen Sie die application-protocol
Anweisung auf der [edit applications application application-name]
Hierarchieebene ein:
[edit applications application application-name] application-protocol protocol-name;
Tabelle 1 zeigt eine Liste der unterstützten Protokolle. Weitere Informationen zu bestimmten Protokollen finden Sie unter ALG-Beschreibungen.
Protokollname |
CLI-Wert |
Kommentare |
---|---|---|
Bootstrap-Protokoll (BOOTP) |
|
Unterstützt BOOTP und DHCP (Dynamic Host Configuration Protocol). |
Verteilte Computing-Umgebung (DCE) Remote Procedure Call (RPC) |
|
Erfordert, dass die |
DCE RPC-Portübersicht |
|
Erfordert, dass die |
Domainnamensystem (DNS) |
|
Erfordert, dass die |
Exec |
|
Erfordert, dass die |
FTP |
|
Erfordert, dass die |
H.323 |
|
– |
IKE ALG |
|
Erfordert, dass die |
Internet Control Message Protocol (ICMP) |
|
Erfordert, dass die |
Internet Inter-ORB-Protokoll |
|
– |
IP |
|
– |
Einloggen |
|
– |
NetBIOS |
|
Erfordert, dass die |
NetShow |
|
Erfordert, dass die |
Punkt-zu-Punkt-Tunneling-Protokoll |
|
– |
RealAudio |
|
– |
Echtzeit-Streaming-Protokoll (RTSP) |
|
Erfordert, dass die |
RPC User Datagram Protocol (UDP) oder TCP |
|
Erfordert, dass die |
RPC-Portzuordnung |
|
Erfordert, dass die |
Muschel |
|
Erfordert, dass die |
Sitzungsinitiierungsprotokoll |
|
– |
SNMP |
|
Erfordert, dass die |
SQLNet |
|
Erfordert, dass die |
Vortragsprogramm |
|
|
Route verfolgen |
|
Erfordert, dass die |
Trivial FTP (TFTP) |
|
Erfordert, dass die |
WinFrame |
|
– |
Sie können Gateways auf Anwendungsebene (ALGs) für ICMP konfigurieren und die Route unter Stateful-Firewall-, NAT- oder CoS-Regeln verfolgen, wenn im selben Servicesatz zweimal NAT konfiguriert ist. Diese ALGs können nicht auf Datenströme angewendet werden, die vom Packet Gateway Controller Protocol (PGCP) erstellt wurden. Twice NAT unterstützt keine anderen ALGs. NAT wendet nur die IP-Adresse und die TCP- oder UDP-Header an, nicht aber die Nutzlast.
Weitere Informationen zur Konfiguration von zweifachem NAT finden Sie unter Übersicht über die Junos Address Aware-Netzwerkadressierung.
Konfigurieren des Netzwerkprotokolls
Mit der protocol
Anweisung können Sie angeben, mit welchem der unterstützten Netzwerkprotokolle in einer Anwendungsdefinition abgeglichen werden soll. Um Netzwerkprotokolle zu konfigurieren, fügen Sie die protocol
Anweisung auf der [edit applications application application-name]
Hierarchieebene ein:
[edit applications application application-name] protocol type;
Sie geben den Protokolltyp als numerischen Wert an. Für die gebräuchlichsten Protokolle werden Textnamen auch in der Befehlszeilenschnittstelle (CLI) unterstützt. Tabelle 2 zeigt eine Liste der unterstützten Protokolle.
Netzwerkprotokolltyp |
CLI-Wert |
Kommentare |
---|---|---|
IP-Sicherheit (IPsec) Authentifizierungsheader (AH) |
|
– |
External Gateway Protocol (EGP) |
|
– |
IPsec-Kapselung Security Payload (ESP) |
|
– |
Generic-Routing-Encapsulation (GR) |
|
– |
ICMP |
|
Erfordert den |
ICMPv6 |
|
Erfordert den |
Internet Group Management Protocol (IGMP) |
|
– |
IP in IP |
|
– |
OSPF |
|
– |
Protokollunabhängiges Multicast (PIM) |
|
– |
Resource Reservation Protocol (RSVP) |
|
– |
TCP |
|
Erfordert einen Wert für |
UDP |
|
Erfordert einen Wert für |
Eine vollständige Liste der möglichen numerischen Werte finden Sie unter RFC 1700, Zugewiesene Nummern (für die Internet Protocol Suite).
IP-Version 6 (IPv6) wird als Netzwerkprotokoll in Anwendungsdefinitionen nicht unterstützt.
Standardmäßig kann sich die Funktion "Twice NAT" auf IP-, TCP- und UDP-Header auswirken, die in die Nutzlast von ICMP-Fehlermeldungen eingebettet sind. Sie können die protocol tcp
and-Anweisungen protocol udp
in die application-Anweisung für zwei NAT-Konfigurationen einschließen. Weitere Informationen zur Konfiguration von zweifachem NAT finden Sie unter Übersicht über die Junos Address Aware-Netzwerkadressierung.
Konfigurieren des ICMP-Codes und -Typs
Der ICMP-Code und -Typ bieten in Verbindung mit dem Netzwerkprotokoll zusätzliche Spezifikationen für den Paketabgleich in einer Anwendungsdefinition. Um ICMP-Einstellungen zu konfigurieren, schließen Sie die icmp-code
and-Anweisungen icmp-type
auf der [edit applications application application-name]
Hierarchieebene ein:
[edit applications application application-name] icmp-code value; icmp-type value;
Sie können nur einen ICMP-Code und -Typwert einschließen. Die application-protocol
Anweisung muss den Wert icmp
haben. Tabelle 3 zeigt eine Liste der unterstützten ICMP-Werte.
CLI-Statement |
Beschreibung |
---|---|
|
Dieser Wert oder dieses Schlüsselwort enthält spezifischere Informationen als Anstelle des numerischen Werts können Sie eines der folgenden Textsynonyme angeben (die Feldwerte werden ebenfalls aufgelistet). Die Schlüsselwörter sind nach dem ICMP-Typ gruppiert, dem sie zugeordnet sind: Parameter-Problem: Weiterleitung: Zeitüberschreitung: nicht erreichbar: |
|
Normalerweise geben Sie diese Übereinstimmung in Verbindung mit der Anstelle des numerischen Wertes können Sie eines der folgenden Textsynonyme angeben (die Feldwerte werden ebenfalls aufgelistet): |
Wenn Sie eine Schnittstelle mit einem Eingabe-Firewall-Filter konfigurieren, der eine Ablehnungsaktion enthält, und mit einem Servicesatz, der Stateful-Firewall-Regeln enthält, führt der Router den Eingabe-Firewall-Filter aus, bevor die Stateful-Firewall-Regeln für das Paket ausgeführt werden. Wenn die Packet Forwarding Engine eine ICMP-Fehlermeldung über die Schnittstelle sendet, verwerfen die zustandsbehafteten Firewall-Regeln das Paket möglicherweise, weil es nicht in Eingaberichtung erkannt wurde.
Mögliche Problemumgehungen bestehen darin, einen Weiterleitungstabellenfilter zum Ausführen der Ablehnungsaktion einzuschließen, da dieser Filtertyp nach der zustandsbehafteten Firewall in Eingaberichtung ausgeführt wird, oder einen Ausgabedienstfilter einzuschließen, um zu verhindern, dass die lokal generierten ICMP-Pakete an den zustandsbehafteten Firewalldienst gesendet werden.
Konfigurieren von Quell- und Zielports
Der TCP- oder UDP-Quell- und -Zielport bieten in Verbindung mit dem Netzwerkprotokoll zusätzliche Spezifikationen für den Paketabgleich in einer Anwendungsdefinition. Um Ports zu konfigurieren, schließen Sie die destination-port
and-Anweisungen source-port
auf der [edit applications application application-name]
Hierarchieebene ein:
[edit applications application application-name] destination-port value; source-port value;
Sie müssen einen Quell- oder Zielport definieren. Normalerweise geben Sie diese Übereinstimmung in Verbindung mit der protocol
match-Anweisung an, um zu bestimmen, welches Protokoll auf dem Port verwendet wird; Einschränkungen finden Sie in Tabelle 1.
Sie können entweder einen numerischen Wert oder eines der in Tabelle 4 aufgeführten Textsynonyme angeben.
Portname |
Entsprechende Portnummer |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Weitere Informationen zu Übereinstimmungskriterien finden Sie im Benutzerhandbuch für Routing-Richtlinien, Firewall-Filter und Datenverkehrsrichtlinien.
Konfigurieren der Zeitüberschreitung bei Inaktivität
Sie können einen Timeoutzeitraum für die Inaktivität der Anwendung angeben. Wenn die Software während der Dauer keine Aktivität erkannt hat, wird der Flow ungültig, wenn der Timer abläuft. Um einen Timeoutzeitraum zu konfigurieren, fügen Sie die inactivity-timeout
Anweisung auf der [edit applications application application-name]
Hierarchieebene ein:
[edit applications application application-name] inactivity-timeout seconds;
Der Standardwert ist 30 Sekunden. Der Wert, den Sie für eine Anwendung konfigurieren, überschreibt alle globalen Werte, die auf der [edit interfaces interface-name service-options]
Hierarchieebene konfiguriert sind. Weitere Informationen finden Sie unter Konfigurieren von Standard-Timeout-Einstellungen für Dienstschnittstellen.
Konfigurieren einer IKE ALG-Anwendung
Vor Junos OS-Version 17.4R1 wurde Network Address Translation-Traversal (NAT-T) für die IPsec-Funktionen der Junos VPN Site Secure-Suite auf den Routern der MX-Serie nicht unterstützt. Das IKE ALG ermöglicht die Weiterleitung von IKEv1- und IPsec-Paketen durch NAPT-44- und NAT64-Filter zwischen IPsec-Peers, die nicht NAT-T-kompatibel sind. Dieses ALG unterstützt nur den ESP-Tunnelmodus. Sie können die vordefinierte IKE ALG-Anwendung junos-ike
verwenden, die über vordefinierte Werte für den Zielport (500), das Inaktivitäts-Timeout (30 Sekunden), das Gate-Timeout (120 Sekunden) und das Idle-Timeout der ESP-Sitzung (800 Sekunden) verfügt. Wenn Sie das IKE ALG mit anderen Werten als der vordefinierten junos-ike
Anwendung verwenden möchten, müssen Sie eine neue IKE ALG-Anwendung konfigurieren.
So konfigurieren Sie eine IKE ALG-Anwendung:
Geben Sie einen Namen für die Anwendung an.
[edit applications] user@host# set application junos-ike
Geben Sie den IKE-ALG an.
[edit applications application junos-ike] user@host# set application-protocol ike-esp-nat
Geben Sie das UDP-Protokoll an.
[edit applications application junos-ike] user@host# set protocol udp
Geben Sie 500 als Zielport an.
[edit applications application junos-ike] user@host# set destination-port 500
-
Geben Sie die Anzahl der Sekunden an, die die IKE-Sitzung inaktiv ist, bevor sie gelöscht wird. Der Standardwert ist 30 Sekunden.
[edit applications application junos-ike] user@host# set inactivity-timeout seconds
Geben Sie die Anzahl der Sekunden an, die vergehen können, nachdem IKE die Sicherheitszuordnung zwischen dem IPsec-Client und dem Server hergestellt hat und bevor der ESP-Datenverkehr in beide Richtungen beginnt. Wenn der ESP-Datenverkehr nicht vor diesem Timeout-Wert gestartet wurde, werden die ESP-Gatter gelöscht und der ESP-Datenverkehr blockiert. Der Standardwert ist 120 Sekunden.
[edit applications application junos-ike] user@host# set gate-timeout seconds
Geben Sie die Zeitüberschreitung für den Leerlauf der ESP-Sitzung (IPsec-Datenverkehr) in Sekunden an. Wird in dieser Zeit kein IPsec-Datenverkehr auf der ESP-Sitzung übergeben, wird die Sitzung gelöscht. Der Standardwert ist 800 Sekunden.
[edit applications application junos-ike] user@host# set child-inactivity-timeout seconds
Konfigurieren von SIP
Das Session Initiation Protocol (SIP) ist ein generalisiertes Protokoll für die Kommunikation zwischen Endgeräten, die an Internetdiensten wie Telefonie, Fax, Videokonferenzen, Instant Messaging und Dateiaustausch beteiligt sind.
Das Junos OS stellt ALG-Services in Übereinstimmung mit dem in RFC 3261, SIP, Session Initiation Protocol beschriebenen Standard bereit. Die SIP-Datenströme unter dem Junos OS werden in RFC 3665, Beispiele für grundlegende Anrufabläufe im Session Initiation Protocol (SIP) beschrieben.
Vor der Implementierung von Junos OS SIP ALG sollten Sie sich mit bestimmten Einschränkungen vertraut machen, die unter Einschränkungen von Junos OS SIP ALG erläutert werden
Die Verwendung von NAT in Verbindung mit dem SIP-ALG führt aufgrund der Adressübersetzung zu Änderungen in den SIP-Header-Feldern. Eine Erläuterung dieser Übersetzungen finden Sie unter SIP ALG-Interaktion mit Network Address Translation.
Um SIP auf Adaptive Services Interfaces zu implementieren, konfigurieren Sie die Anweisung application-protocol
auf Hierarchieebene [edit applications application application-name]
mit dem Wert sip
. Weitere Hinweise zu dieser Anweisung finden Sie unter Konfigurieren eines Anwendungsprotokolls. Darüber hinaus gibt es zwei weitere Anweisungen, die Sie konfigurieren können, um die Implementierung von SIP zu ändern:
Sie können den Router so konfigurieren, dass er alle eingehenden SIP-Anrufe für die Endgeräte annimmt, die sich hinter der NAT-Firewall befinden. Wenn sich ein Gerät hinter der Firewall bei dem Proxy außerhalb der Firewall registriert, behält der AS- oder Multiservices-PIC den Registrierungsstatus bei. Wenn die
learn-sip-register
Anweisung aktiviert ist, kann der Router diese Informationen verwenden, um eingehende Anrufe anzunehmen. Wenn diese Anweisung nicht konfiguriert ist, werden keine eingehenden Aufrufe akzeptiert. Nur die Geräte hinter der Firewall können Geräte außerhalb der Firewall anrufen.Um die SIP-Registrierung zu konfigurieren, schließen Sie die
learn-sip-register
Anweisung auf der[edit applications application application-name]
Hierarchieebene ein:[edit applications application application-name] learn-sip-register;
Anmerkung:Die
learn-sip-register
Erklärung gilt nicht für die Next-Gen-Services MX-SPC3.Sie können das SIP-Register auch manuell überprüfen, indem Sie den
show services stateful-firewall sip-register
Befehl eingeben. Weitere Informationen finden Sie in der Befehlsreferenz zu Junos OS-Systemen und Services. Dershow services stateful-firewall sip-register
Befehl wird für Services der nächsten Generation nicht unterstützt.Sie können einen Timeoutzeitraum für die Dauer von SIP-Anrufen angeben, die in der Warteschleife gehalten werden. Wenn ein Anruf gehalten wird, gibt es keine Aktivität, und Flows können nach Ablauf des konfigurierten
inactivity-timeout
Zeitraums eine Zeitüberschreitung aufweisen, was zu einem Teardown des Anrufzustands führt. Um dies zu vermeiden, wird der Flow-Timer auf densip-call-hold-timeout
Zyklus zurückgesetzt, wenn ein Anruf gehalten wird, um den Anrufstatus und die Abläufe länger als deninactivity-timeout
Zeitraum beizubehalten.Anmerkung:Die
sip-call-hold-timeout
Erklärung gilt nicht für die Next-Gen-Services MX-SPC3.Um einen Timeoutzeitraum zu konfigurieren, fügen Sie die
sip-call-hold-timeout
Anweisung auf der[edit applications application application-name]
Hierarchieebene ein:[edit applications application application-name] sip-call-hold-timeout seconds;
Der Standardwert ist 7200 Sekunden und der Bereich liegt zwischen 0 und 36.000 Sekunden (10 Stunden).
SIP ALG-Interaktion mit Network Address Translation
Das NAT-Protokoll (Network Address Translation) ermöglicht es mehreren Hosts in einem privaten Subnetz, eine einzige öffentliche IP-Adresse für den Zugriff auf das Internet gemeinsam zu nutzen. Bei ausgehendem Datenverkehr ersetzt NAT die private IP-Adresse des Hosts im privaten Subnetz durch die öffentliche IP-Adresse. Bei eingehendem Datenverkehr wird die öffentliche IP-Adresse wieder in die private Adresse konvertiert, und die Nachricht wird an den entsprechenden Host im privaten Subnetz weitergeleitet.
Die Verwendung von NAT mit dem SIP-Dienst (Session Initiation Protocol) ist komplizierter, da SIP-Nachrichten sowohl in den SIP-Headern als auch im SIP-Text IP-Adressen enthalten. Wenn Sie NAT mit dem SIP-Dienst verwenden, enthalten die SIP-Header Informationen über den Anrufer und den Empfänger, und das Gerät übersetzt diese Informationen, um sie vor dem externen Netzwerk zu verbergen. Der SIP-Text enthält die SDP-Informationen (Session Description Protocol), die IP-Adressen und Portnummern für die Übertragung der Medien enthalten. Das Gerät übersetzt SDP-Informationen für die Zuweisung von Ressourcen zum Senden und Empfangen der Medien.
Wie IP-Adressen und Portnummern in SIP-Nachrichten ersetzt werden, hängt von der Richtung der Nachricht ab. Bei einer ausgehenden Nachricht werden die private IP-Adresse und die Portnummer des Clients durch die öffentliche IP-Adresse und die Portnummer der Firewall von Juniper Networks ersetzt. Bei einer eingehenden Nachricht wird die öffentliche Adresse der Firewall durch die private Adresse des Clients ersetzt.
Wenn eine INVITE-Nachricht über die Firewall gesendet wird, sammelt das SIP-Anwendungsebene-Gateway (ALG) Informationen aus dem Nachrichtenheader in einer Anruftabelle, die zum Weiterleiten nachfolgender Nachrichten an den richtigen Endpunkt verwendet wird. Wenn eine neue Nachricht eintrifft, z. B. eine Bestätigung oder 200 OK, vergleicht das ALG die Felder "Von:", "An:" und "Anruf-ID:" mit der Anruftabelle, um den Anrufkontext der Nachricht zu identifizieren. Wenn eine neue INVITE-Nachricht eintrifft, die dem bestehenden Aufruf entspricht, verarbeitet ALG diese als REINVITE.
Wenn eine Nachricht mit SDP-Informationen eintrifft, weist das ALG Ports zu und erstellt eine NAT-Zuordnung zwischen ihnen und den Ports im SDP. Da das SDP sequenzielle Ports für die RTP- (Real-Time Transport Protocol)- und RTCP-Kanäle (Real-Time Control Protocol) benötigt, stellt das ALG aufeinanderfolgende Ports mit geraden und ungeraden Ports bereit. Wenn ein Portpaar nicht gefunden werden kann, wird die SIP-Nachricht verworfen.
Dieses Thema enthält die folgenden Abschnitte:
Ausgehende Anrufe
Wenn ein SIP-Anruf mit einer SIP-Anforderungsnachricht vom internen zum externen Netzwerk initiiert wird, ersetzt NAT die IP-Adressen und Portnummern im SDP und bindet die IP-Adressen und Portnummern an die Firewall von Juniper Networks. Die SIP-Headerfelder "Via", "Contact", "Route" und "Record-Route" (sofern vorhanden) sind ebenfalls an die IP-Adresse der Firewall gebunden. Das ALG speichert diese Zuordnungen für die Verwendung in erneuten Übertragungen und für SIP-Antwortnachrichten.
Das SIP-ALG öffnet dann Lochblenden in der Firewall, um Medien über das Gerät auf den dynamisch zugewiesenen Ports zuzulassen, die basierend auf Informationen im SDP und in den Headerfeldern "Via", "Contact" und "Record-Route" ausgehandelt werden. Die Pinholes ermöglichen es eingehenden Paketen auch, die IP-Adressen und Ports "Contact", "Via" und "Record-Route" zu erreichen. Bei der Verarbeitung von Rückdatenverkehr fügt das ALG die ursprünglichen SIP-Felder "Contact", "Via", "Route" und "Record-Route" wieder in Pakete ein.
Eingehende Anrufe
Eingehende Anrufe werden vom öffentlichen Netzwerk an öffentliche statische NAT-Adressen oder an Schnittstellen-IP-Adressen auf dem Gerät initiiert. Statische NATs sind statisch konfigurierte IP-Adressen, die auf interne Hosts verweisen. Schnittstellen-IP-Adressen werden dynamisch von der ALG aufgezeichnet, während sie REGISTER-Nachrichten überwacht, die von internen Hosts an den SIP-Registrar gesendet werden. Wenn das Gerät ein eingehendes SIP-Paket empfängt, richtet es eine Sitzung ein und leitet die Nutzlast des Pakets an das SIP-ALG weiter.
Das ALG prüft die SIP-Anforderungsnachricht (zunächst INVITE) und öffnet auf Basis der Informationen im SDP Tore für ausgehende Medien. Wenn eine 200 OK-Antwortnachricht eintrifft, führt das SIP-ALG NAT für die IP-Adressen und Ports aus und öffnet Pinholes in ausgehender Richtung. (Die geöffneten Tore haben eine kurze Gültigkeitsdauer und treten ab, wenn eine 200 OK-Antwortnachricht nicht schnell empfangen wird.)
Wenn eine 200 OK-Antwort eintrifft, untersucht der SIP-Proxy die SDP-Informationen und liest die IP-Adressen und Portnummern für jede Mediensitzung. Das SIP-ALG auf dem Gerät führt NAT für die Adressen und Portnummern durch, öffnet Pinholes für ausgehenden Datenverkehr und aktualisiert die Zeitüberschreitung für Gates in eingehender Richtung.
Wenn das ACK für die 200 OK eintrifft, passiert es auch das SIP ALG. Wenn die Nachricht SDP-Informationen enthält, stellt das SIP-ALG sicher, dass die IP-Adressen und Portnummern im Vergleich zum vorherigen INVITE nicht geändert werden – wenn dies der Fall ist, löscht das ALG alte Pinholes und erstellt neue Pinholes, um Medien passieren zu lassen. Das ALG überwacht auch die SIP-Felder "Via", "Contact" und "Record-Route" und öffnet neue Lochblenden, wenn festgestellt wird, dass sich diese Felder geändert haben.
Weitergeleitete Anrufe
Von einem weitergeleiteten Anruf spricht man beispielsweise, wenn Benutzer A außerhalb des Netzwerks Benutzer B innerhalb des Netzwerks anruft und Benutzer B den Anruf an Benutzer C außerhalb des Netzwerks weiterleitet. Das SIP ALG verarbeitet das INVITE von Benutzer A wie einen normalen eingehenden Anruf. Wenn das ALG jedoch den weitergeleiteten Anruf von B nach C außerhalb des Netzwerks untersucht und feststellt, dass B und C über die gleiche Schnittstelle erreicht werden, öffnet es keine Lochblenden in der Firewall, da die Medien direkt zwischen Benutzer A und Benutzer C fließen.
Anrufbeendigung
Die BYE-Nachricht beendet einen Anruf. Wenn das Gerät eine BYE-Nachricht empfängt, werden die Headerfelder wie bei jeder anderen Nachricht übersetzt. Da eine BYE-Nachricht jedoch vom Empfänger mit einem 200 OK quittiert werden muss, verzögert das ALG den Anrufabriss um fünf Sekunden, um Zeit für die Übertragung des 200 OK zu haben.
Rufen Sie Re-INVITE Nachrichten an
Erneute INVITE-Nachrichten fügen einem Anruf neue Mediensitzungen hinzu und entfernen vorhandene Mediensitzungen. Wenn einem Anruf neue Mediensitzungen hinzugefügt werden, werden neue Blendenöffnungen in der Firewall geöffnet und neue Adressbindungen erstellt. Der Prozess ist identisch mit dem ursprünglichen Anrufaufbau. Wenn eine oder mehrere Mediensitzungen aus einem Anruf entfernt werden, werden Lochblenden geschlossen und Bindungen freigegeben, genau wie bei einer BYE-Nachricht.
Sitzungs-Timer anrufen
Die SIP-ALG verwendet den Wert Session-Expires, um eine Zeitüberschreitung für eine Sitzung zu beenden, wenn keine Re-INVITE- oder UPDATE-Nachricht empfangen wird. Das ALG ruft den Session-Expires-Wert, falls vorhanden, aus der 200 OK-Antwort auf INVITE ab und verwendet diesen Wert für die Signalisierung des Timeouts. Wenn die ALG vor Ablauf der Sitzung eine weitere INVITE-Anweisung empfängt, werden alle Timeout-Werte auf diese neue INVITE-Anweisung oder auf Standardwerte zurückgesetzt, und der Vorgang wird wiederholt.
Als Vorsichtsmaßnahme verwendet das SIP-ALG harte Timeout-Werte, um die maximale Zeitspanne festzulegen, die ein Anruf bestehen kann. Dadurch wird sichergestellt, dass das Gerät geschützt ist, falls eines der folgenden Ereignisse eintritt:
Endsysteme stürzen während eines Anrufs ab und es wird keine BYE-Nachricht empfangen.
Böswillige Benutzer senden niemals ein BYE bei dem Versuch, ein SIP-ALG anzugreifen.
Schlechte Implementierungen des SIP-Proxys können Record-Route nicht verarbeiten und senden nie eine BYE-Nachricht.
Netzwerkfehler verhindern, dass eine BYE-Nachricht empfangen wird.
Anrufabbruch
Jede Partei kann einen Anruf abbrechen, indem eine CANCEL-Nachricht gesendet wird. Beim Empfang einer CANCEL-Meldung schließt das SIP-ALG die Blenden durch die Firewall (sofern geöffnet) und gibt Adressbindungen frei. Vor der Freigabe der Ressourcen verzögert das ALG das Auslaufen des Steuerkanals um ca. fünf Sekunden, um Zeit für die letzten 200 OK zu haben. Der Anruf wird beendet, wenn das Zeitlimit von fünf Sekunden abgelaufen ist, unabhängig davon, ob eine 487- oder Nicht-200-Antwort eintrifft.
Gabelung
Forking ermöglicht es einem SIP-Proxy, eine einzelne INVITE-Nachricht gleichzeitig an mehrere Ziele zu senden. Wenn die mehrfachen 200 OK-Antwortnachrichten für den einzelnen Anruf eintreffen, analysiert das SIP-ALG die Anrufinformationen, aktualisiert die Anrufinformationen jedoch mit den ersten 200 empfangenen OK-Nachrichten.
SIP-Nachrichten
Das SIP-Nachrichtenformat besteht aus einem SIP-Header-Abschnitt und dem SIP-Text. In Anforderungsnachrichten ist die erste Zeile des Headerabschnitts die Anforderungszeile, die den Methodentyp, den Anforderungs-URI und die Protokollversion enthält. In Antwortnachrichten ist die erste Zeile die Statuszeile, die einen Statuscode enthält. SIP-Header enthalten IP-Adressen und Portnummern, die für die Signalisierung verwendet werden. Der SIP-Text, der durch eine Leerzeile vom Header-Abschnitt getrennt ist, ist für die Sitzungsbeschreibung reserviert, die optional sind. Junos OS unterstützt derzeit nur SDP. Der SIP-Text enthält IP-Adressen und Portnummern, die für den Transport der Medien verwendet werden.
SIP-Header
In der folgenden SIP-Anforderungsbeispielnachricht ersetzt NAT die IP-Adressen in den Headerfeldern, um sie vor dem externen Netzwerk auszublenden.
INVITE bob@10.150.20.5
SIP/2.0 Via: SIP/2.0/UDP10.150.20.3
:5434 From: alice@10.150.20.3
To: bob@10.150.20.5
Call-ID: a12abcde@10.150.20.3
Contact: alice@10.150.20.3
:5434 Route: <sip:netscreen@10.150.20.3
:5060> Record-Route: <sip:netscreen@10.150.20.3
:5060>
Wie die IP-Adressenübersetzung durchgeführt wird, hängt vom Typ und der Richtung der Nachricht ab. Eine Nachricht kann eine der folgenden sein:
Eingehende Anfrage
Ausgehende Antwort
Ausgehende Anfrage
Eingehende Antwort
Tabelle 5 zeigt, wie NAT in jedem dieser Fälle durchgeführt wird. Beachten Sie, dass die ALG für einige der Header-Felder mehr als nur bestimmt, ob die Nachrichten von innerhalb oder außerhalb des Netzwerks stammen. Außerdem muss ermittelt werden, welcher Client den Anruf initiiert hat und ob es sich bei der Nachricht um eine Anforderung oder Antwort handelt.
Eingehende Anfrage (von öffentlich nach privat) |
An: |
Ersetzen der Domäne durch die lokale Adresse |
Von: |
Nichts |
|
Anruf-ID: |
Nichts |
|
Via: |
Nichts |
|
Anforderungs-URI: |
Ersetzen Sie die ALG-Adresse durch eine lokale Adresse |
|
Kontakt: |
Nichts |
|
Record-Route: |
Nichts |
|
Route: |
Nichts |
|
Ausgehende Antwort (von privat zu öffentlich) |
An: |
Ersetzen Sie die ALG-Adresse durch eine lokale Adresse |
Von: |
Nichts |
|
Anruf-ID: |
Nichts |
|
Via: |
Nichts |
|
Anforderungs-URI: |
N/A |
|
Kontakt: |
Lokale Adresse durch ALG-Adresse ersetzen |
|
Record-Route: |
Lokale Adresse durch ALG-Adresse ersetzen |
|
Route: |
Nichts |
|
Ausgehende Anforderung (von privat zu öffentlich) |
An: |
Nichts |
Von: |
Lokale Adresse durch ALG-Adresse ersetzen |
|
Anruf-ID: |
Nichts |
|
Via: |
Lokale Adresse durch ALG-Adresse ersetzen |
|
Anforderungs-URI: |
Nichts |
|
Kontakt: |
Lokale Adresse durch ALG-Adresse ersetzen |
|
Record-Route: |
Lokale Adresse durch ALG-Adresse ersetzen |
|
Route: |
Ersetzen Sie die ALG-Adresse durch eine lokale Adresse |
|
Ausgehende Antwort (von öffentlich nach privat) |
An: |
Nichts |
Von: |
Ersetzen Sie die ALG-Adresse durch eine lokale Adresse |
|
Anruf-ID: |
Nichts |
|
Via: |
Ersetzen Sie die ALG-Adresse durch eine lokale Adresse |
|
Anforderungs-URI: |
N/A |
|
Kontakt: |
Nichts |
|
Record-Route: |
Ersetzen Sie die ALG-Adresse durch eine lokale Adresse |
|
Route: |
Ersetzen Sie die ALG-Adresse durch eine lokale Adresse |
SIP-Körper
Die SDP-Informationen im SIP-Text enthalten IP-Adressen, die das ALG zum Erstellen von Kanälen für den Mediendatenstrom verwendet. Bei der Übersetzung des SDP-Abschnitts werden auch Ressourcen, d. h. Portnummern, zum Senden und Empfangen der Medien zugewiesen.
Der folgende Auszug aus einem SDP-Beispielabschnitt zeigt die Felder, die für die Ressourcenzuordnung übersetzt werden.
o=user 2344234 55234434 IN IP410.150.20.3
c=IN IP410.150.20.3
m=audio43249
RTP/AVP 0
SIP-Nachrichten können mehr als einen Medienstrom enthalten. Das Konzept ähnelt dem Anfügen mehrerer Dateien an eine E-Mail-Nachricht. Eine INVITE-Nachricht, die von einem SIP-Client an einen SIP-Server gesendet wird, kann z. B. die folgenden Felder enthalten:
c=IN IP410.123.33.4
m=audio33445
RTP/AVP 0 c=IN IP410.123.33.4
m=audio33447
RTP/AVP 0 c=IN IP410.123.33.4
m=audio33449
RTP/AVP 0
Junos OS unterstützt bis zu 6 SDP-Kanäle, die für jede Richtung ausgehandelt werden, also insgesamt 12 Kanäle pro Anruf.
Einschränkungen von Junos OS SIP ALG
Für die Konfiguration des SIP-ALG gelten die folgenden Einschränkungen:
Es werden nur die in RFC 3261 beschriebenen Methoden unterstützt.
Es wird nur die SIP-Version 2 unterstützt.
TCP wird nicht als Transportmechanismus für die Signalisierung von Nachrichten für MS-MPCs unterstützt, wird jedoch für Dienste der nächsten Generation unterstützt.
Konfigurieren Sie das SIP-ALG nicht, wenn Sie STUN verwenden. Wenn Clients STUN/TURN verwenden, um die Firewall- oder NAT-Geräte zwischen dem Anrufer und dem Responder oder Proxy zu erkennen, versucht der Client, das Verhalten des NAT-Geräts bestmöglich zu erraten und entsprechend zu handeln, um den Anruf zu tätigen.
Verwenden Sie auf MS-MPCs nicht die Option für den endpunktunabhängigen Zuordnungs-NAT-Pool in Verbindung mit dem SIP-ALG. Fehler sind die Folge. Dies gilt nicht für Dienste der nächsten Generation.
IPv6-Signalisierungsdaten werden für MS-MPCs nicht unterstützt, wohl aber für Services der nächsten Generation.
Authentifizierung wird nicht unterstützt.
Verschlüsselte Nachrichten werden nicht unterstützt.
Die SIP-Fragmentierung wird für MS-MPCs nicht unterstützt, wohl aber für Services der nächsten Generation.
Die maximale UDP-Paketgröße, die eine SIP-Nachricht enthält, wird mit 9 KB angenommen. SIP-Nachrichten, die größer als dieser Wert sind, werden nicht unterstützt.
Es wird angenommen, dass die maximale Anzahl von Medienkanälen in einer SIP-Nachricht sechs beträgt.
Vollqualifizierte Domänennamen (FQDNs) werden in kritischen Feldern nicht unterstützt.
QoS wird nicht unterstützt. SIP unterstützt DSCP-Umschreibungen.
Hochverfügbarkeit wird nicht unterstützt, mit Ausnahme von Warm-Standby.
Die Timeout-Einstellung "nie" wird für SIP oder NAT nicht unterstützt.
Multicast (Forking-Proxy) wird nicht unterstützt.
Konfigurieren eines SNMP-Befehls für den Paketabgleich
Sie können eine SNMP-Befehlseinstellung für den Paketabgleich angeben. Um SNMP zu konfigurieren, fügen Sie die snmp-command
Anweisung auf der [edit applications application application-name]
Hierarchieebene ein:
[edit applications application application-name] snmp-command value;
Die unterstützten Werte sind get
, get-next
, set
und trap
. Sie können nur einen Wert für den Abgleich konfigurieren. Die application-protocol
Anweisung auf der [edit applications application application-name]
Hierarchieebene muss den Wert snmp
haben. Weitere Informationen zum Angeben des Anwendungsprotokolls finden Sie unter Konfigurieren eines Anwendungsprotokolls.
Konfigurieren einer RPC-Programmnummer
Sie können eine RPC-Programmnummer für den Paketabgleich angeben. Um eine RPC-Programmnummer zu konfigurieren, fügen Sie die rpc-program-number
Anweisung auf der [edit applications application application-name]
Hierarchieebene ein:
[edit applications application application-name] rpc-program-number number;
Der für DCE oder RPC verwendete Wertebereich liegt zwischen 100.000 und 400.000. Die application-protocol
Anweisung auf der [edit applications application application-name]
Hierarchieebene muss den Wert rpc
haben. Weitere Informationen zum Angeben des Anwendungsprotokolls finden Sie unter Konfigurieren eines Anwendungsprotokolls.
Konfigurieren des TTL-Schwellenwerts
Sie können einen Schwellenwert für die Gültigkeitsdauer (TTL) für die Trace-Route angeben, der den akzeptablen Grad der Netzwerkdurchdringung für das Trace-Routing steuert. Um einen TTL-Wert zu konfigurieren, schließen Sie die ttl-threshold
Anweisung auf der [edit applications application application-name]
Hierarchieebene ein:
[edit applications application application-name] ttl-threshold value;
Die application-protocol
Anweisung auf der [edit applications application application-name]
Hierarchieebene muss den Wert traceroute
haben. Weitere Informationen zum Angeben des Anwendungsprotokolls finden Sie unter Konfigurieren eines Anwendungsprotokolls.
Konfigurieren eines Universal Unique Identifier
Sie können eine UUID (Universal Unique Identifier) für DCE-RPC-Objekte angeben. Um einen UUID-Wert zu konfigurieren, fügen Sie die uuid
Anweisung auf der [edit applications application application-name]
Hierarchieebene ein:
[edit applications application application-name] uuid hex-value;
Der uuid
Wert wird in hexadezimaler Schreibweise angegeben. Die application-protocol
Anweisung auf der [edit applications application application-name
Hierarchieebene muss den Wert dce-rpc
haben. Weitere Informationen zum Angeben des Anwendungsprotokolls finden Sie unter Konfigurieren eines Anwendungsprotokolls. Weitere Hinweise zu UUID-Nummern finden Sie unter http://www.opengroup.org/onlinepubs/9629399/apdxa.htm
.
Siehe auch
Konfigurieren von Anwendungssätzen
Sie können die Anwendungen, die Sie definiert haben, in einem benannten Objekt gruppieren, indem Sie die application-set
Anweisung auf der [edit applications]
Hierarchieebene mit einer application
Anweisung für jede Anwendung einschließen:
[edit applications] application-set application-set-name { application application; }
Ein Beispiel für einen typischen Anwendungssatz finden Sie unter Beispiele: Konfigurieren von Anwendungsprotokollen.
Beispiele: Konfigurieren von Anwendungsprotokollen
Das folgende Beispiel zeigt eine Anwendungsprotokolldefinition, die eine spezielle FTP-Anwendung beschreibt, die auf Port 78 ausgeführt wird:
[edit applications] application my-ftp-app { application-protocol ftp; protocol tcp; destination-port 78; timeout 100; # inactivity timeout for FTP service }
Das folgende Beispiel zeigt ein spezielles ICMP-Protokoll (application-protocol icmp
) vom Typ 8 (ICMP-Echo):
[edit applications] application icmp-app { application-protocol icmp; protocol icmp; icmp-type icmp-echo; }
Das folgende Beispiel zeigt ein mögliches Anwendungsset:
[edit applications] application-set basic { http; ftp; telnet; nfs; icmp; }
Die Software enthält einen vordefinierten Satz bekannter Anwendungsprotokolle. Die Gruppe umfasst Anwendungen, für die die TCP- und UDP-Zielports bereits von zustandslosen Firewall-Filtern erkannt werden.
Überprüfen der Ausgabe von ALG-Sitzungen
Dieser Abschnitt enthält Beispiele für erfolgreiche Ausgaben von ALG-Sitzungen und Informationen zur Konfiguration des Systemprotokolls. Sie können die Ergebnisse Ihrer Sitzungen vergleichen, um zu überprüfen, ob die Konfigurationen korrekt funktionieren.
FTP-Beispiel
In diesem Beispiel wird die Ausgabe während einer aktiven FTP-Sitzung analysiert. Es besteht aus vier verschiedenen Strömen; Zwei davon sind Ablaufsteuerungen und zwei Datenströme. Das Beispiel besteht aus den folgenden Teilen:
Beispielausgabe
MS-MPC-Karte
Für MS-MPCs finden Sie im Folgenden eine vollständige Beispielausgabe des show services stateful-firewall conversations application-protocol ftp
Betriebsmodusbefehls:
user@host>show services stateful-firewall conversations application-protocol ftp Interface: ms-1/3/0, Service set: CLBJI1-AAF001 Conversation: ALG protocol: ftp Number of initiators: 2, Number of responders: 2 Flow State Dir Frm count TCP 1.1.79.2:14083 -> 2.2.2.2:21 Watch I 13 NAT source 1.1.79.2:14083 -> 194.250.1.237:50118 TCP 1.1.79.2:14104 -> 2.2.2.2:20 Forward I 3 NAT source 1.1.79.2:14104 -> 194.250.1.237:50119 TCP 2.2.2.2:21 -> 194.250.1.237:50118 Watch O 12 NAT dest 194.250.1.237:50118 -> 1.1.79.2:14083 TCP 2.2.2.2:20 -> 194.250.1.237:50119 Forward O 5 NAT dest 194.250.1.237:50119 -> 1.1.79.2:14104
Für jeden Datenfluss werden in der ersten Zeile Datenstrominformationen angezeigt, einschließlich Protokoll (TCP), Quelladresse, Quellport, Zieladresse, Zielport, Datenstromstatus, Richtung und Frame-Anzahl.
Der Status eines Flows kann ,
Watch
Forward
oderDrop
sein:Ein
Watch
Datenflussstatus gibt an, dass die Ablaufsteuerung von der ALG auf Informationen in der Nutzlast überwacht wird. Die NAT-Verarbeitung wird für den Header und die Nutzlast nach Bedarf durchgeführt.Ein
Forward
Datenstrom leitet die Pakete weiter, ohne die Nutzlast zu überwachen. NAT wird bei Bedarf für den Header ausgeführt.Ein
Drop
Datenstrom verwirft jedes Paket, das mit dem Tupel 5 übereinstimmt.
Die Frame-Anzahl (
Frm count
) zeigt die Anzahl der Pakete an, die in diesem Datenstrom verarbeitet wurden.
In der zweiten Zeile werden die NAT-Informationen angezeigt.
source
gibt die Quellen-NAT an.dest
gibt die Ziel-NAT an.Die erste Adresse und der erste Port in der NAT-Leitung sind die ursprüngliche Adresse und der Port, die für diesen Datenstrom übersetzt werden.
Die zweite Adresse und der zweite Port in der NAT-Leitung sind die übersetzte Adresse und der Port für diesen Datenstrom.
MX-SPC3-Karte
Auf der MX-SPC3-Serviceskarte finden Sie im Folgenden eine vollständige Beispielausgabe des show services sessions application-protocol ftp
Betriebsmodusbefehls:
user@host>show services sessions application-protocol ftp Session ID: 536870917, Service-set: ss1, Policy name: p1/131085, Timeout: 1, Valid Logical system: root-logical-system Resource information : FTP ALG, 1, 1 In: 12.10.10.10/35281 --> 22.20.20.3/8204;tcp, Conn Tag: 0x0, If: vms-2/0/0.100, Pkts: 6, Bytes: 320, Out: 22.20.20.3/8204 --> 60.1.1.2/48747;tcp, Conn Tag: 0x0, If: vms-2/0/0.200, Pkts: 9, Bytes: 8239, Session ID: 536870919, Service-set: ss1, Policy name: p1/131085, Timeout: 29, Valid Logical system: root-logical-system Resource information : FTP ALG, 1, 0 In: 12.10.10.10/44194 --> 22.20.20.3/21;tcp, Conn Tag: 0x0, If: vms-2/0/0.100, Pkts: 13, Bytes: 585, Out: 22.20.20.3/21 --> 60.1.1.2/48660;tcp, Conn Tag: 0x0, If: vms-2/0/0.200, Pkts: 11, Bytes: 650, Total sessions: 2
Für jede Sitzung:
In der ersten Zeile werden Datenstrominformationen angezeigt, einschließlich Sitzungs-ID, Dienstsatzname, Richtlinienname, Sitzungszeitüberschreitung, logischer Systemname und Status.
Die zweite Zeile gibt an,
Resource information
dass die Sitzung von ALG erstellt wird, einschließlich des ALG-Namens (FTP ALG) und der ASL-Gruppen-ID, die 1 ist, und der ASL-Ressourcen-ID, die 0 für die Steuersitzung und 1 für die Datensitzung ist.Die dritte Zeile
In
ist der Vorwärtsfluss und die vierte ZeileOut
ist der umgekehrte Datenfluss, einschließlich der Quelladresse, des Quellports, der Zieladresse, des Zielports, des Protokolls (TCP), des Sitzungs-Conn-Tag, des eingehendenIn
und ausgehendenOut
Datenverkehrs, der Anzahl der empfangenen Frames und der Bytes. NAT wird bei Bedarf für den Header ausgeführt.
FTP-Systemprotokollmeldungen
Systemprotokollmeldungen werden während einer FTP-Sitzung generiert. Weitere Informationen zu Systemprotokollen finden Sie unter Systemprotokollmeldungen.
MS-MPC-Karte
Die folgenden Systemprotokollmeldungen werden während der Erstellung der FTP-Ablaufsteuerung generiert:
Regel akzeptieren Systemprotokoll:
Oct 27 11:42:54 (FPC Slot 1, PIC Slot 1) {ss_ftp}[FWNAT]: ASP_SFW_RULE_ACCEPT: proto 6 (TCP) application: ftp, fe-3/3/3.0:1.1.1.2:4450 -> 2.2.2.2:21, Match SFW accept rule-set:, rule: ftp, term: 1
Systemprotokoll zum Akzeptieren des Datenflusses erstellen:
Oct 27 11:42:54 (FPC Slot 1, PIC Slot 1) {ss_ftp}[FWNAT]: ASP_SFW_CREATE_ACCEPT_FLOW: proto 6 (TCP) application: ftp, fe-3/3/3.0:1.1.1.2:4450 -> 2.2.2.2:21, creating forward or watch flow
Systemprotokoll für die Datenstromerstellung:
Oct 27 11:43:30 (FPC Slot 1, PIC Slot 1) {ss_ftp}[FWNAT]: ASP_SFW_FTP_ACTIVE_ACCEPT: proto 6 (TCP) application: ftp, so-2/1/2.0:2.2.2.2:20 -> 1.1.1.2:50726, Creating FTP active mode forward flow
MX-SPC3-Kartenkarte
Die folgenden Systemprotokollmeldungen werden während der Erstellung der FTP-Ablaufsteuerung generiert:
Systemprotokoll für die Erstellung von FTP-Kontrollsitzungen:
Mar 23 23:58:54 esst480r RT_FLOW: RT_FLOW_SESSION_CREATE_USF: Tag svc-set-name ss1: session created 20.1.1.2/52877->30.1.1.2/21 0x0 junos-ftp 20.1.1.2/52877->30.1.1.2/21 0x0 N/A N/A N/A N/A 6 p1 ss1-ZoneIn ss1-ZoneOut 818413576 N/A(N/A) ge-1/0/2.0 UNKNOWN UNKNOWN UNKNOWN N/A N/A -1 N/A Mar 23 23:59:00 esst480r junos-alg: RT_ALG_FTP_ACTIVE_ACCEPT: application:ftp data, vms-3/0/0.0 30.1.1.2:20 -> 20.1.1.2:33947 (TCP)
Systemprotokoll für die Erstellung von FTP-Datensitzungen:
Mar 23 23:59:00 esst480r RT_FLOW: RT_FLOW_SESSION_CREATE_USF: Tag svc-set-name ss1: session created 30.1.1.2/20->20.1.1.2/33947 0x0 junos-ftp-data 30.1.1.2/20->20.1.1.2/33947 0x0 N/A N/A N/A N/A 6 p1 ss1-ZoneOut ss1-ZoneIn 818413577 N/A(N/A) ge-1/1/6.0 FTP-DATA UNKNOWN UNKNOWN Infrastructure File-Servers 2 N/A
Systemprotokoll für die Zerstörung der FTP-Datensitzung:
Mar 23 23:59:02 esst480r RT_FLOW: RT_FLOW_SESSION_CLOSE_USF: Tag svc-set-name ss1: session closed TCP FIN: 30.1.1.2/20->20.1.1.2/33947 0x0 junos-ftp-data 30.1.1.2/20->20.1.1.2/33947 0x0 N/A N/A N/A N/A 6 p1 ss1-ZoneOut ss1-ZoneIn 818413577 2954(4423509) 281(14620) 2 FTP-DATA UNKNOWN N/A(N/A) ge-1/1/6.0 No Infrastructure File-Servers 2 N/A
Systemprotokoll für die Zerstörung der FTP-Kontrollsitzung:
Mar 23 23:59:39 esst480r RT_FLOW: RT_FLOW_SESSION_CLOSE_USF: Tag svc-set-name ss1: session closed Closed by junos-tcp-clt-emul: 20.1.1.2/52877->30.1.1.2/21 0x0 junos-ftp 20.1.1.2/52877->30.1.1.2/21 0x0 N/A N/A N/A N/A 6 p1 ss1-ZoneIn ss1-ZoneOut 818413576 23(1082) 18(1176) 45 UNKNOWN UNKNOWN N/A(N/A) ge-1/0/2.0 No N/A N/A -1 N/A
Analyse
Abläufe
MS-MPC-Karte
Die Abläufe werden eingerichtet, nachdem der Drei-Wege-Handshake abgeschlossen ist.
Ablaufsteuerung vom FTP-Client zum FTP-Server. Der TCP-Zielport ist 21.
TCP 1.1.79.2:14083 -> 2.2.2.2:21 Watch I 13 NAT source 1.1.79.2:14083 -> 194.250.1.237:50118
Ablaufsteuerung vom FTP-Server zum FTP-Client. Der TCP-Quellport ist 21.
TCP 2.2.2.2:21 -> 194.250.1.237:50118 Watch O 12 NAT dest 194.250.1.237:50118 -> 1.1.79.2:14083
MX-SPC3-Karte
Die Abläufe werden eingerichtet, nachdem der Drei-Wege-Handshake abgeschlossen ist.
Steuerungssitzung vom FTP-Client zum FTP-Server, TCP-Zielport ist 21.
Session ID: 536870919, Service-set: ss1, Policy name: p1/131085, Timeout: 29, Valid Logical system: root-logical-system Resource information : FTP ALG, 1, 0 In: 12.10.10.10/44194 --> 22.20.20.3/21;tcp, Conn Tag: 0x0, If: vms-2/0/0.100, Pkts: 13, Bytes: 585, Out: 22.20.20.3/21 --> 60.1.1.2/48660;tcp, Conn Tag: 0x0, If: vms-2/0/0.200, Pkts: 11, Bytes: 650,
Datensitzung vom FTP-Client zum FTP-Server, es ist für den passiven FTP-Modus.
Session ID: 536870917, Service-set: ss1, Policy name: p1/131085, Timeout: 1, Valid Logical system: root-logical-system Resource information : FTP ALG, 1, 1 In: 12.10.10.10/35281 --> 22.20.20.3/8204;tcp, Conn Tag: 0x0, If: vms-2/0/0.100, Pkts: 6, Bytes: 320, Out: 22.20.20.3/8204 --> 60.1.1.2/48747;tcp, Conn Tag: 0x0, If: vms-2/0/0.200, Pkts: 9, Bytes: 8239,
Datensitzung vom FTP-Server zum FTP-Client, es ist für den aktiven FTP-Modus:
Session ID: 549978117, Service-set: ss1, Policy name: p1/131085, Timeout: 1, Valid Logical system: root-logical-system Resource information : FTP ALG, 1, 1 In: 22.20.20.3/20 --> 60.1.1.3/6049;tcp, Conn Tag: 0x0, If: vms-2/0/0.200, Pkts: 10, Bytes: 8291, Out: 12.10.10.10/33203 --> 22.20.20.3/20;tcp, Conn Tag: 0x0, If: vms-2/0/0.100, Pkts: 5, Bytes: 268,
Datenflüsse
Ein Datenport von 20 wird für die Datenübertragung während des FTP-Steuerprotokolls ausgehandelt. Bei diesen beiden Flüssen handelt es sich um Datenflüsse zwischen dem FTP-Client und dem FTP-Server:
TCP 1.1.79.2:14104 -> 2.2.2.2:20 Forward I 3 NAT source 1.1.79.2:14104 -> 194.250.1.237:50119 TCP 2.2.2.2:20 -> 194.250.1.237:50119 Forward O 5 NAT dest 194.250.1.237:50119 -> 1.1.79.2:14104
Fragen zur Fehlerbehebung
Woher weiß ich, ob das FTP ALG aktiv ist?
Das ALG-Protokollfeld in der Konversation sollte angezeigt werden
ftp
.Es sollte eine gültige Frameanzahl (
Frm count
) in den Ablaufsteuerungen vorhanden sein.Eine gültige Frame-Anzahl in den Datenflüssen zeigt an, dass eine Datenübertragung stattgefunden hat.
Was muss ich überprüfen, wenn die FTP-Verbindung hergestellt ist, aber keine Datenübertragung stattfindet?
Höchstwahrscheinlich ist die Steuerverbindung aktiv, aber die Datenverbindung ist ausgefallen.
Überprüfen Sie die Konversationsausgabe, um festzustellen, ob sowohl das Steuerelement als auch der Datenfluss vorhanden sind.
Wie interpretiere ich die einzelnen Flows? Was bedeuten die einzelnen Datenströme?
Initiator-Flow für FTP-Kontrollfluss: Datenfluss mit Zielport 21
FTP-Kontrollfluss-Responder-Flow: Datenfluss mit Quellport ; 21
FTP-Datenfluss-Initiator-Flow: Datenfluss mit Zielport 20
FTP-Datenfluss-Responder-Flow: Datenfluss mit Quellport 20
RTSP ALG-Beispiel
Im Folgenden finden Sie ein Beispiel für eine RTSP-Unterhaltung. Die Anwendung verwendet das RTSP-Protokoll für die Steuerungsverbindung. Sobald die Verbindung hergestellt ist, werden die Medien über das UDP-Protokoll (RTP) gesendet.
Dieses Beispiel besteht aus Folgendem:
- Beispielausgabe für MS-MPCs
- Beispielausgabe für die MX-SPC3 Servicekarte
- Analyse
- Fragen zur Fehlerbehebung
Beispielausgabe für MS-MPCs
Hier ist die Ausgabe des Betriebsmodusbefehls show services stateful-firewall conversations
:
user@host# show services stateful-firewall conversations Interface: ms-3/2/0, Service set: svc_set Conversation: ALG protocol: rtsp Number of initiators: 5, Number of responders: 5 Flow State Dir Frm count TCP 1.1.1.3:58795 -> 2.2.2.2:554 Watch I 7 UDP 1.1.1.3:1028 -> 2.2.2.2:1028 Forward I 0 UDP 1.1.1.3:1029 -> 2.2.2.2:1029 Forward I 0 UDP 1.1.1.3:1030 -> 2.2.2.2:1030 Forward I 0 UDP 1.1.1.3:1031 -> 2.2.2.2:1031 Forward I 0 TCP 2.2.2.2:554 -> 1.1.1.3:58795 Watch O 5 UDP 2.2.2.2:1028 -> 1.1.1.3:1028 Forward O 6 UDP 2.2.2.2:1029 -> 1.1.1.3:1029 Forward O 0 UDP 2.2.2.2:1030 -> 1.1.1.3:1030 Forward O 3 UDP 2.2.2.2:1031 -> 1.1.1.3:1031 Forward O 0
Beispielausgabe für die MX-SPC3 Servicekarte
Hier ist die Ausgabe des Betriebsmodusbefehls show services sessions application-protocol rtsp
:
user@host# run show services sessions application-protocol rtsp Session ID: 1073741828, Service-set: sset1, Policy name: p1/131081, Timeout: 116, Valid Logical system: root-logical-system Resource information : RTSP ALG, 1, 0 In: 31.0.0.2/33575 --> 41.0.0.2/554;tcp, Conn Tag: 0x0, If: vms-4/0/0.1, Pkts: 8, Bytes: 948, Out: 41.0.0.2/554 --> 131.10.0.1/7777;tcp, Conn Tag: 0x0, If: vms-4/0/0.2, Pkts: 6, Bytes: 1117, Session ID: 1073741829, Service-set: sset1, Policy name: p1/131081, Timeout: 120, Valid Logical system: root-logical-system Resource information : RTSP ALG, 1, 1 In: 41.0.0.2/35004 --> 131.10.0.1/7780;udp, Conn Tag: 0x0, If: vms-4/0/0.2, Pkts: 220, Bytes: 79200, Out: 31.0.0.2/30004 --> 41.0.0.2/35004;udp, Conn Tag: 0x0, If: vms-4/0/0.1, Pkts: 0, Bytes: 0, Session ID: 1073741830, Service-set: sset1, Policy name: p1/131081, Timeout: 120, Valid Logical system: root-logical-system Resource information : RTSP ALG, 1, 4 In: 41.0.0.2/35006 --> 131.10.0.1/7781;udp, Conn Tag: 0x0, If: vms-4/0/0.2, Pkts: 220, Bytes: 174240, Out: 31.0.0.2/30006 --> 41.0.0.2/35006;udp, Conn Tag: 0x0, If: vms-4/0/0.1, Pkts: 0, Bytes: 0, Total sessions: 3
Analyse
Eine RTSP-Konversation sollte aus TCP-Datenströmen bestehen, die der RTSP-Steuerungsverbindung entsprechen. Es sollte zwei Datenströme geben, einen in jede Richtung, vom Client zum Server und vom Server zum Client:
TCP 1.1.1.3:58795 -> 2.2.2.2:554 Watch I 7 TCP 2.2.2.2:554 -> 1.1.1.3:58795 Watch O 5
Die RTSP-Steuerverbindung für den Initiator-Flow wird vom Zielport 554 gesendet.
Die RTSP-Steuerverbindung für den Responder-Datenfluss wird vom Quellport 554 gesendet.
Die UDP-Flows entsprechen RTP-Medien, die über die RTSP-Verbindung gesendet werden.
Fragen zur Fehlerbehebung
Medien funktionieren nicht, wenn das RTSP ALG konfiguriert ist. Was soll ich tun?
Überprüfen Sie RTSP-Konversationen, um festzustellen, ob sowohl TCP- als auch UDP-Datenströme vorhanden sind.
Das ALG-Protokoll sollte als
rtsp
angezeigt werden.
Anmerkung:Der Status des Datenstroms wird als
Watch
angezeigt, da die ALG-Verarbeitung stattfindet und der Client im Wesentlichen die für die Anwendung entsprechende Nutzlast "beobachtet" oder verarbeitet. Bei FTP- und RTSP-ALG-Flows sind die Steuerverbindungen immerWatch
Flows.Wie überprüfe ich auf ALG-Fehler?
Sie können nach Fehlern suchen, indem Sie den folgenden Befehl eingeben. Jedes ALG hat ein separates Feld für ALG-Paketfehler.
user@host# show services stateful-firewall statistics extensive Interface: ms-3/2/0 Service set: svc_set New flows: Accepts: 1347, Discards: 0, Rejects: 0 Existing flows: Accepts: 144187, Discards: 0, Rejects: 0 Drops: IP option: 0, TCP SYN defense: 0 NAT ports exhausted: 0 Errors: IP: 0, TCP: 276 UDP: 0, ICMP: 0 Non-IP packets: 0, ALG: 0 IP errors: IP packet length inconsistencies: 0 Minimum IP header length check failures: 0 Reassembled packet exceeds maximum IP length: 0 Illegal source address: 0 Illegal destination address: 0 TTL zero errors: 0, Illegal IP protocol number (0 or 255): 0 Land attack: 0 Non-IPv4 packets: 0, Bad checksum: 0 Illegal IP fragment length: 0 IP fragment overlap: 0 IP fragment reassembly timeout: 0 Unknown: 0 TCP errors: TCP header length inconsistencies: 0 Source or destination port number is zero: 0 Illegal sequence number and flags combinations: 0 SYN attack (multiple SYN messages seen for the same flow): 276 First packet not a SYN message: 0 TCP port scan (TCP handshake, RST seen from server for SYN): 0 Bad SYN cookie response: 0 UDP errors: IP data length less than minimum UDP header length (8 bytes): 0 Source or destination port number is zero: 0 UDP port scan (ICMP error seen for UDP flow): 0 ICMP errors: IP data length less than minimum ICMP header length (8 bytes): 0 ICMP error length inconsistencies: 0 Duplicate ping sequence number: 0 Mismatched ping sequence number: 0 ALG errors: BOOTP: 0, DCE-RPC: 0, DCE-RPC portmap: 0 DNS: 0, Exec: 0, FTP: 0 ICMP: 0 Login: 0, NetBIOS: 0, NetShow: 0 RPC: 0, RPC portmap: 0 RTSP: 0, Shell: 0 SNMP: 0, SQLNet: 0, TFTP: 0 Traceroute: 0
Systemprotokoll-Meldungen
Das Aktivieren der Systemprotokollgenerierung und das Überprüfen des Systemprotokolls sind ebenfalls hilfreich für die ALG-Flussanalyse. Dieser Abschnitt enthält Folgendes:
Konfiguration des Systemprotokolls
Sie können die Aktivierung von Systemprotokollmeldungen auf verschiedenen Ebenen in der Junos OS CLI konfigurieren. Wie in den folgenden Beispielkonfigurationen gezeigt, hängt die Wahl der Ebene davon ab, wie spezifisch die Ereignisprotokollierung sein soll und welche Optionen Sie einschließen möchten. Einzelheiten zu den Konfigurationsoptionen finden Sie in der Junos OS Administration Library für Routing-Geräte (Systemebene) bzw. in der Junos OS Services Interfaces Library für Routing-Geräte (alle anderen Ebenen).
Auf globaler Top-Ebene:
user@host# show system syslog file messages { any any; }
Auf Serviceset-Ebene:
user@host# show services service-set svc_set syslog { host local { services any; } } stateful-firewall-rules allow_rtsp; interface-service { service-interface ms-3/2/0; }
Auf der Ebene der Serviceregel:
user@host# show services stateful-firewall rule allow_rtsp match-direction input-output; term 0 { from { applications junos-rtsp; } then { accept; syslog; } }
Ausgabe des Systemprotokolls
Systemprotokollmeldungen werden während der Flow-Erstellung generiert, wie in den folgenden Beispielen gezeigt:
Die folgende Systemprotokollmeldung gibt an, dass der ASP einer Akzeptanzregel entsprach:
Oct 25 16:11:37 (FPC Slot 3, PIC Slot 2) {svc_set}[FWNAT]: ASP_SFW_RULE_ACCEPT: proto 6 (TCP) application: rtsp, ge-2/0/1.0:1.1.1.2:35595 -> 2.2.2.2:554, Match SFW accept rule-set: , rule: allow_rtsp, term: 0
Eine vollständige Liste der Systemprotokollmeldungen finden Sie im Systemprotokoll-Explorer.