ALG-Anwendungen
Konfigurieren von Anwendungseigenschaften
Um Anwendungseigenschaften zu konfigurieren, schließen Sie die application Anweisung auf Hierarchieebene [edit applications] 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 Anwendungssätze konfigurieren.
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 des Inaktivitäts-Timeouts
- Konfigurieren einer IKE ALG-Anwendung
- Konfiguration von SIP
- Konfigurieren eines SNMP-Befehls für den Paketabgleich
- Konfigurieren einer RPC-Programmnummer
- Konfigurieren des TTL-Schwellenwerts
- Konfigurieren eines universellen eindeutigen Identifikators
Konfigurieren eines Anwendungsprotokolls
Mit dieser application-protocol Anweisung können Sie angeben, welche der unterstützten Anwendungsprotokolle (ALGs) konfiguriert und in einen Anwendungssatz für die Serviceverarbeitung aufgenommen werden sollen. Um Anwendungsprotokolle zu konfigurieren, fügen Sie die application-protocol Anweisung auf Hierarchieebene [edit applications application application-name] ein:
[edit applications application application-name] application-protocol protocol-name;
Tabelle 1 zeigt die Liste der unterstützten Protokolle. Weitere Informationen zu bestimmten Protokollen finden Sie unter ALG-Beschreibungen.
Name des Protokolls |
CLI Wert |
Kommentare |
|---|---|---|
Bootstrap-Protokoll (BOOTP) |
|
Unterstützt BOOTP und DHCP (Dynamic Host Configuration Protocol). |
Distributed Computing Environment (DCE) Remote Procedure Call (RPC) |
|
Erfordert, dass die |
DCE RPC-Portzuordnung |
|
Erfordert, dass die |
Domain Name System (DNS) |
|
Erfordert, dass die |
Führungskraft |
|
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 (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 |
Zuordnung von RPC-Ports |
|
Erfordert, dass die |
Muschel |
|
Erfordert, dass die |
Protokoll für Sitzungsbeginn |
|
– |
SNMP |
|
Erfordert, dass die |
SQLNet |
|
Erfordert, dass die |
Vortragsprogramm |
|
|
Route verfolgen |
|
Erfordert, dass die |
Triviales FTP (TFTP) |
|
Erfordert, dass die |
WinFrame |
|
– |
Sie können Gateways auf Anwendungsebene (ALGs) für ICMP konfigurieren und Routen unter Stateful-Firewall-, NAT- oder CoS-Regeln verfolgen, wenn zweimal NAT im selben Servicesatz konfiguriert ist. Diese ALGs können nicht auf Datenflüsse 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 TCP- oder UDP-Header an, aber nicht die Nutzlast.
Weitere Informationen zur Konfiguration von zweimal NAT finden Sie unter Übersicht über die Netzwerkadressierung von Junos Address Aware.
Konfigurieren des Netzwerkprotokolls
Mit dieser protocol Anweisung können Sie angeben, welches der unterstützten Netzwerkprotokolle in einer Anwendungsdefinition übereinstimmen soll. Um Netzwerkprotokolle zu konfigurieren, fügen Sie die protocol Anweisung auf Hierarchieebene [edit applications application application-name] ein:
[edit applications application application-name] protocol type;
Sie geben den Protokolltyp als numerischen Wert an. Für die gebräuchlicheren Protokolle werden Textnamen auch in der Befehlszeilenschnittstelle (CLI) unterstützt. Tabelle 2 zeigt eine Liste der unterstützten Protokolle.
Netzwerkprotokoll-Typ |
CLI Wert |
Kommentare |
|---|---|---|
IP-Sicherheit (IPsec) Authentifizierungs-Header (AH) |
|
– |
Externes Gateway Protocol (EGP) |
|
– |
IPsec Encapsulating Sicherheit 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 |
UDP |
|
Erfordert einen |
Eine vollständige Liste der möglichen numerischen Werte finden Sie unter RFC 1700, Assigned Numbers (for the Internet Protocol Suite).
IP-Version 6 (IPv6) wird als Netzwerkprotokoll in Anwendungsdefinitionen nicht unterstützt.
Standardmäßig kann sich die Funktion "Zweimal 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 für doppelte NAT-Konfigurationen in die Anwendungsanweisung einschließen. Weitere Informationen zur Konfiguration von zweimal NAT finden Sie unter Übersicht über die Netzwerkadressierung von Junos Address Aware.
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 und-Anweisungen icmp-type auf Hierarchieebene [edit applications application application-name] ein:
[edit applications application application-name] icmp-code value; icmp-type value;
Sie können nur einen ICMP-Code und einen Typwert angeben. Die application-protocol Anweisung muss den Wert icmp. Tabelle 3 zeigt die Liste der unterstützten ICMP-Werte.
CLI-Anweisung |
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 aufgeführt). 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 Werts können Sie eines der folgenden Textsynonyme angeben (die Feldwerte werden ebenfalls aufgeführt): |
Wenn Sie eine Schnittstelle mit einem Eingabe-Firewall-Filter konfigurieren, der eine Ablehnungsaktion enthält, und mit einem Service-Set, das 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, können die Stateful-Firewall-Regeln das Paket verwerfen, weil es nicht in Eingaberichtung angezeigt 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 und-Anweisungen source-port auf Hierarchieebene [edit applications application application-name] 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 für den Port verwendet wird. Informationen zu Einschränkungen finden Sie in Tabelle 1.
Sie können entweder einen numerischen Wert oder eines der in Tabelle 4 aufgeführten Textsynonyme angeben.
Name des Ports |
Entsprechende Portnummer |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Weitere Informationen zu Übereinstimmungskriterien finden Sie im Benutzerhandbuch zu Routing-Richtlinien, Firewall-Filtern und Traffic Policers.
Konfigurieren des Inaktivitäts-Timeouts
Sie können eine Zeitüberschreitung für die Inaktivität der Anwendung festlegen. 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, schließen Sie die inactivity-timeout Anweisung auf Hierarchieebene [edit applications application application-name] 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 Serviceschnittstellen.
Konfigurieren einer IKE ALG-Anwendung
Vor Junos OS Version 17.4R1 wird Network Address Translation-Traversal (NAT-T) für die Junos VPN Site Secure Suite von IPsec-Funktionen auf den MX-Serie-Routern nicht unterstützt. Das IKE ALG ermöglicht die Weitergabe von IKEv1- und IPsec-Paketen über NAPT-44- und NAT64-Filter zwischen IPsec-Peers, die nicht NAT-T-kompatibel sind. Diese ALG unterstützt nur den ESP-Tunnel-Modus. Sie können die vordefinierte IKE ALG-Anwendung junos-ikeverwenden, die über vordefinierte Werte für den Zielport (500), das Inaktivitäts-Timeout (30 Sekunden), das Gate-Timeout (120 Sekunden) und das Leerlauf-Timeout der ESP-Sitzung (800 Sekunden) verfügt. Wenn Sie die IKE-ALG mit Werten verwenden möchten, die sich von der vordefinierten junos-ike Anwendung unterscheiden, 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 die 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 IPsec-Client und -Server eingerichtet hat und bevor der ESP-Datenverkehr in beide Richtungen gestartet wird. Wenn der ESP-Datenverkehr nicht vor diesem Zeitüberschreitungswert 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 das Leerlauftimeout der ESP-Sitzung (IPsec-Datenverkehr) in Sekunden an. Wenn in dieser Zeit kein IPsec-Datenverkehr an die ESP-Sitzung übergeben wird, wird die Sitzung gelöscht. Der Standardwert ist 800 Sekunden.
[edit applications application junos-ike] user@host# set child-inactivity-timeout seconds
Konfiguration von SIP
Das Session Initiation Protocol (SIP) ist ein allgemeines 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 gemäß dem in RFC 3261, SIP: Session Initiation Protocol beschriebenen Standard bereit. SIP-Datenströme unter Junos OS sind wie in RFC 3665, Session Initiation Protocol (SIP) Basic Call Flow Examples beschrieben.
Bevor Sie das Junos OS SIP ALG implementieren, sollten Sie mit bestimmten Einschränkungen vertraut sein, die unter Einschränkungen von Junos OS SIP ALG erläutert werden
Die Verwendung von NAT in Verbindung mit dem SIP ALG führt zu Änderungen in SIP-Header-Feldern aufgrund der Adressübersetzung. Eine Erläuterung dieser Übersetzungen finden Sie unter SIP ALG Interaction with Network Address Translation.
Um SIP auf Adaptive-Services-Schnittstellen zu implementieren, konfigurieren Sie die application-protocol Anweisung auf Hierarchieebene [edit applications application application-name] mit dem Wert sip. Weitere Informationen 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 einstellen, 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-registerAnweisung 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 aufrufen.Um die SIP-Registrierung zu konfigurieren, fügen Sie die
learn-sip-registerAnweisung auf Hierarchieebene[edit applications application application-name]ein:[edit applications application application-name] learn-sip-register;
Hinweis:Diese
learn-sip-registerAussage 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-registerBefehl ausgeben. Weitere Informationen finden Sie in der Junos OS System Basics and Services Command Reference. Dershow services stateful-firewall sip-registerBefehl 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 gehalten werden. Wenn ein Anruf gehalten wird, gibt es keine Aktivität, und es kann zu einer Zeitüberschreitung der Flows nach Ablauf des konfigurierten
inactivity-timeoutZeitraums kommen, was zu einem Bruch des Anrufstatus führt. Um dies zu vermeiden, wird der Flow-Timer beim Halten eines Anrufs auf densip-call-hold-timeoutZyklus zurückgesetzt, um den Anrufstatus und die Flows länger als deninactivity-timeoutZeitraum beizubehalten.Hinweis:Diese
sip-call-hold-timeoutAussage gilt nicht für die Next Gen Services MX-SPC3.Um einen Timeoutzeitraum zu konfigurieren, schließen Sie die
sip-call-hold-timeoutAnweisung auf Hierarchieebene[edit applications application application-name]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 Network Address Translation (NAT)-Protokoll ermöglicht es mehreren Hosts in einem privaten Subnetz, eine einzige öffentliche IP-Adresse für den Zugriff auf das Internet gemeinsam zu nutzen. Für ausgehenden 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 IP-Adressen sowohl in den SIP-Headern als auch im SIP-Text 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-Body enthält die Session Description Protocol (SDP)-Informationen, 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 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 Nachrichtenkopf in einer Aufruftabelle, die es verwendet, um nachfolgende Nachrichten an das richtige Endgerät weiterzuleiten. Wenn eine neue Nachricht eingeht, z. B. eine Bestätigung oder 200 OK, vergleicht die ALG die Felder "Von:", "Bis:" und "Anruf-ID:" mit der Aufruftabelle, um den Aufrufkontext der Nachricht zu identifizieren. Wenn eine neue INVITE-Nachricht eingeht, die mit dem vorhandenen Aufruf übereinstimmt, verarbeitet der ALG sie als REINVITE.
Wenn eine Nachricht mit SDP-Informationen eintrifft, weist der ALG Ports zu und erstellt eine NAT-Zuordnung zwischen ihnen und den Ports im SDP. Da der SDP sequenzielle Ports für die RTP- (Real-Time Transport Protocol) und RTCP-Kanäle (Real-Time Control Protocol) benötigt, stellt der ALG aufeinanderfolgende gerade und ungerade Ports bereit. Wenn kein Portpaar 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. SIP-Header-Felder Via, Contact, Route und Record-Route sind, falls vorhanden, ebenfalls an die IP-Adresse der Firewall gebunden. Die ALG speichert diese Zuordnungen für die Verwendung bei erneuten Übertragungen und für SIP-Antwortnachrichten.
Das SIP-ALG öffnet dann Löcher in der Firewall, um Medien durch das Gerät auf den dynamisch zugewiesenen Ports zu lassen, die auf der Grundlage von Informationen im SDP und den Header-Feldern "Via", "Contact" und "Record-Route" ausgehandelt werden. Die Pinholes ermöglichen es auch eingehenden Paketen, die Contact-, Via- und Record-Route-IP-Adressen und -Ports zu erreichen. Bei der Verarbeitung des zurückgegebenen Datenverkehrs fügt der 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 von der ALG dynamisch 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.
Die ALG prüft die SIP-Anforderungsnachricht (zunächst eine EINLADUNG) und öffnet auf der Grundlage der Informationen im SDP Tore für ausgehende Medien. Wenn eine 200 OK-Antwortnachricht eintrifft, führt das SIP-ALG eine NAT für die IP-Adressen und Ports durch und öffnet Löcher in ausgehender Richtung. (Die geöffneten Gates haben eine kurze Gültigkeitsdauer und es kommt zu einer Zeitüberschreitung, wenn die Antwortmeldung 200 OK nicht schnell empfangen wird.)
Wenn die Antwort 200 OK 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 Löcher für ausgehenden Datenverkehr und aktualisiert das Timeout für Gates in eingehender Richtung.
Wenn das ACK für das 200 OK ankommt, durchläuft es auch das SIP ALG. Wenn die Nachricht SDP-Informationen enthält, stellt das SIP-ALG sicher, dass die IP-Adressen und Portnummern gegenüber dem vorherigen INVITE nicht geändert werden – wenn dies der Fall ist, löscht das ALG alte Lochblenden und erstellt neue Lochblenden, damit Medien durchgelassen werden können. Das ALG überwacht auch die SIP-Felder "Via", "Contact" und "Record-Route" und öffnet neue Pinholes, wenn es feststellt, dass sich diese Felder geändert haben.
Weitergeleitete Anrufe
Ein weitergeleiteter Anruf liegt beispielsweise vor, 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 die INVITE von Benutzer A wie einen normalen eingehenden Anruf. Wenn das ALG jedoch den weitergeleiteten Anruf von B an C außerhalb des Netzes untersucht und feststellt, dass B und C über dieselbe Schnittstelle erreicht werden, öffnet es keine Löcher in der Firewall, da 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, übersetzt es die Headerfelder wie bei jeder anderen Nachricht. Da eine BYE-Nachricht jedoch vom Empfänger mit einem OK von 200 bestätigt werden muss, verzögert das ALG den Teardown des Anrufs um fünf Sekunden, um Zeit für die Übertragung des OK von 200 zu haben.
Nachrichten zum erneuten Einladen von Anrufen
Re-INVITE-Nachrichten fügen einem Anruf neue Mediensitzungen hinzu und entfernen vorhandene Mediensitzungen. Wenn einem Anruf neue Mediensitzungen hinzugefügt werden, werden neue Lochblenden in der Firewall geöffnet und neue Adressbindungen erstellt. Der Vorgang ist identisch mit dem ursprünglichen Anrufaufbau. Wenn eine oder mehrere Mediensitzungen aus einem Anruf entfernt werden, werden Lochblenden geschlossen und Bindungen gelöst, genau wie bei einer BYE-Nachricht.
Sitzungs-Timer aufrufen
Die SIP-ALG verwendet den Session-Expires-Wert, um eine Sitzung abzubrechen, wenn keine Re-INVITE- oder UPDATE-Nachricht empfangen wird. Die ALG ruft den Session-Expires-Wert, falls vorhanden, aus der 200 OK-Antwort auf die INVITE ab und verwendet diesen Wert für die Signalisierungszeitüberschreitung. Wenn das ALG vor dem Timeout der Sitzung ein weiteres INVITE empfängt, setzt es alle Timeoutwerte auf dieses neue INVITE oder auf Standardwerte zurück, und der Vorgang wird wiederholt.
Als Vorsichtsmaßnahme verwendet der SIP-ALG harte Timeout-Werte, um die maximale Zeitdauer 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, um ein SIP ALG anzugreifen.
Schlechte Implementierungen des SIP-Proxys können Record-Route nicht verarbeiten und senden nie eine BYE-Nachricht.
Netzwerkausfälle verhindern, dass eine BYE-Nachricht empfangen wird.
Abbruch von Anrufen
Beide Parteien können einen Anruf abbrechen, indem sie eine CANCEL-Nachricht senden. Beim Empfang einer CANCEL-Nachricht schließt das SIP-ALG Löcher durch die Firewall – falls welche geöffnet wurden – und gibt Adressbindungen frei. Vor der Freigabe der Ressourcen verzögert das ALG die Alterung des Steuerkanals um etwa fünf Sekunden, damit die letzten 200 OK passieren können. Der Anruf wird beendet, wenn das fünfsekündige Timeout abläuft, unabhängig davon, ob eine 487- oder Nicht-200-Antwort eintrifft.
Fälschung
Forking ermöglicht es einem SIP-Proxy, eine einzelne INVITE-Nachricht an mehrere Ziele gleichzeitig zu senden. Wenn die mehreren 200 OK-Antwortnachrichten für den einzelnen Anruf eintreffen, analysiert das SIP-ALG die Anrufinformationen mit den ersten 200 OK-Nachrichten, die es erhält, aktualisiert es jedoch.
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 Kopfbereich getrennt ist, ist für Sitzungsbeschreibungsinformationen reserviert, die optional sind. Junos OS unterstützt derzeit nur das SDP. Der SIP-Body enthält IP-Adressen und Portnummern, die für den Transport der Medien verwendet werden.
SIP-Header
In der folgenden Beispiel-SIP-Anforderungsnachricht ersetzt NAT die IP-Adressen in den Headerfeldern, um sie vor dem externen Netzwerk zu verbergen.
INVITE bob@10.150.20.5SIP/2.0 Via: SIP/2.0/UDP10.150.20.3:5434 From: alice@10.150.20.3To: bob@10.150.20.5Call-ID: a12abcde@10.150.20.3Contact: 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-Adressübersetzung durchgeführt wird, hängt von der Art und 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 Headerfelder mehr als nur bestimmt, ob die Nachrichten von innerhalb oder außerhalb des Netzwerks kommen. Es muss auch bestimmen, welcher Client den Anruf initiiert hat und ob es sich bei der Nachricht um eine Anforderung oder Antwort handelt.
Eingehende Anfrage (vom öffentlichen zum privaten) |
An: |
Domain durch lokale Adresse ersetzen |
Von: |
Nichts |
|
Ruf-ID: |
Nichts |
|
Via: |
Nichts |
|
Anforderungs-URI: |
ALG-Adresse durch lokale Adresse ersetzen |
|
Kontakt: |
Nichts |
|
Datensatz-Route: |
Nichts |
|
Strecke: |
Nichts |
|
Ausgehende Antwort (vom privaten zum öffentlichen) |
An: |
ALG-Adresse durch lokale Adresse ersetzen |
Von: |
Nichts |
|
Ruf-ID: |
Nichts |
|
Via: |
Nichts |
|
Anforderungs-URI: |
N/A |
|
Kontakt: |
Lokale Adresse durch ALG-Adresse ersetzen |
|
Datensatz-Route: |
Lokale Adresse durch ALG-Adresse ersetzen |
|
Strecke: |
Nichts |
|
Ausgehende Anfrage (vom privaten zum öffentlichen) |
An: |
Nichts |
Von: |
Lokale Adresse durch ALG-Adresse ersetzen |
|
Ruf-ID: |
Nichts |
|
Via: |
Lokale Adresse durch ALG-Adresse ersetzen |
|
Anforderungs-URI: |
Nichts |
|
Kontakt: |
Lokale Adresse durch ALG-Adresse ersetzen |
|
Datensatz-Route: |
Lokale Adresse durch ALG-Adresse ersetzen |
|
Strecke: |
ALG-Adresse durch lokale Adresse ersetzen |
|
Ausgehende Antwort (vom öffentlichen zum privaten) |
An: |
Nichts |
Von: |
ALG-Adresse durch lokale Adresse ersetzen |
|
Ruf-ID: |
Nichts |
|
Via: |
ALG-Adresse durch lokale Adresse ersetzen |
|
Anforderungs-URI: |
N/A |
|
Kontakt: |
Nichts |
|
Datensatz-Route: |
ALG-Adresse durch lokale Adresse ersetzen |
|
Strecke: |
ALG-Adresse durch lokale Adresse ersetzen |
SIP-Körper
Die SDP-Informationen im SIP-Body enthalten IP-Adressen, die die ALG zum Erstellen von Kanälen für den Medienstream verwendet. Die Übersetzung des SDP-Abschnitts weist auch Ressourcen zu, dh Portnummern zum Senden und Empfangen der Medien.
Der folgende Auszug aus einem Beispiel-SDP-Abschnitt zeigt die Felder, die für die Ressourcenzuordnung übersetzt werden.
o=user 2344234 55234434 IN IP410.150.20.3c=IN IP410.150.20.3m=audio43249RTP/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.4m=audio33445RTP/AVP 0 c=IN IP410.123.33.4m=audio33447RTP/AVP 0 c=IN IP410.123.33.4m=audio33449RTP/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 folgende Einschränkungen:
Es werden nur die in RFC 3261 beschriebenen Methoden unterstützt.
Es wird nur SIP Version 2 unterstützt.
TCP wird nicht als Transportmechanismus für die Signalisierung von Nachrichten für MS-MPCs unterstützt, wohl aber für Services der nächsten Generation.
Konfigurieren Sie das SIP ALG nicht, wenn Sie STUN verwenden. Wenn Clients STUN/TURN verwenden, um die Firewall oder die NAT-Geräte zwischen dem Anrufer und dem Responder oder Proxy zu erkennen, versucht der Client, das Verhalten des NAT-Geräts am besten zu erraten und entsprechend zu handeln, um den Anruf zu tätigen.
Verwenden Sie auf MS-MPCs nicht die Endgerät-unabhängige Zuordnung der NAT-Pool-Option in Verbindung mit dem SIP-ALG. Es treten Fehler auf. Dies gilt nicht für Services der nächsten Generation.
IPv6-Signaldaten 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.
SIP-Fragmentierung wird für MS-MPCs nicht unterstützt, wohl aber für Services der nächsten Generation.
Es wird angenommen, dass die maximale UDP-Paketgröße, die eine SIP-Nachricht enthält, 9 KB beträgt. SIP-Nachrichten, die größer 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-Rewrites.
Hochverfügbarkeit wird nicht unterstützt, mit Ausnahme von warmem Standby.
Die Zeitüberschreitungseinstellung "Nie" wird auf 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 Hierarchieebene [edit applications application application-name] ein:
[edit applications application application-name] snmp-command value;
Die unterstützten Werte sind get, get-next, setund 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 snmphaben. Informationen zum Angeben des Anwendungsprotokolls finden Sie unter Anwendungsprotokoll konfigurieren.
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 Hierarchieebene [edit applications application application-name] ein:
[edit applications application application-name] rpc-program-number number;
Der Wertebereich für DCE oder RPC liegt zwischen 100.000 und 400.000. Die application-protocol Anweisung auf der [edit applications application application-name] Hierarchieebene muss den Wert rpchaben. Informationen zum Angeben des Anwendungsprotokolls finden Sie unter Anwendungsprotokoll konfigurieren.
Konfigurieren des TTL-Schwellenwerts
Sie können einen TTL-Schwellenwert (Time-to-Live) 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 Hierarchieebene [edit applications application application-name] ein:
[edit applications application application-name] ttl-threshold value;
Die application-protocol Anweisung auf der [edit applications application application-name] Hierarchieebene muss den Wert traceroutehaben. Informationen zum Angeben des Anwendungsprotokolls finden Sie unter Anwendungsprotokoll konfigurieren.
Konfigurieren eines universellen eindeutigen Identifikators
Sie können eine UUID (Universal Unique Identifier) für DCE-RPC-Objekte angeben. Um einen UUID-Wert zu konfigurieren, schließen Sie die uuid Anweisung auf Hierarchieebene [edit applications application application-name] ein:
[edit applications application application-name] uuid hex-value;
Der uuid Wert ist hexadezimal. Die application-protocol Anweisung auf der [edit applications application application-name Hierarchieebene muss den Wert dce-rpchaben. Informationen zum Angeben des Anwendungsprotokolls finden Sie unter Anwendungsprotokoll konfigurieren. Weitere Hinweise zu UUID-Nummern finden Sie unter http://www.opengroup.org/onlinepubs/9629399/apdxa.htm.
Siehe auch
Anwendungssets konfigurieren
Sie können die von Ihnen definierten Anwendungen zu einem benannten Objekt gruppieren, indem Sie die application-set Anweisung auf der [edit applications] Hierarchieebene mit einer application Anweisung für jede Anwendung aufnehmen:
[edit applications]
application-set application-set-name {
application application;
}
Ein Beispiel für einen typischen Anwendungssatz finden Sie unter Beispiele: Konfigurieren von Anwendungsprotokollen.
Beispiele: Anwendungsprotokolle konfigurieren
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 einen möglichen Anwendungssatz:
[edit applications]
application-set basic {
http;
ftp;
telnet;
nfs;
icmp;
}
Die Software enthält einen vordefinierten Satz bekannter Anwendungsprotokolle. Das Set enthält Anwendungen, bei denen 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 Systemprotokollkonfiguration. Sie können die Ergebnisse Ihrer Sitzungen vergleichen, um zu überprüfen, ob die Konfigurationen ordnungsgemäß funktionieren.
FTP-Beispiel
In diesem Beispiel wird die Ausgabe während einer aktiven FTP-Sitzung analysiert. Es besteht aus vier verschiedenen Strömen; zwei sind Kontrollflüsse und zwei sind Datenströme. Das Beispiel besteht aus den folgenden Teilen:
Beispielausgabe
MS-MPC-Karte
Für MS-MPCs finden Sie im Folgenden ein vollständiges Beispiel für die Ausgabe des Befehls " show services stateful-firewall conversations application-protocol ftp Betriebsmodus":
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 Flow werden in der ersten Zeile Flow-Informationen angezeigt, einschließlich Protokoll (TCP), Quelladresse, Quellport, Zieladresse, Zielport, Flow-Status, Richtung und Frame-Anzahl.
Der Zustand eines Flusses kann
Watch,ForwardoderDrop:Ein
WatchDatenstromzustand gibt an, dass der Ablaufsteuerungsfluss von der ALG auf Informationen in der Nutzlast überwacht wird. Die NAT-Verarbeitung wird bei Bedarf für den Header und die Nutzlast durchgeführt.Ein
ForwardDatenstrom leitet die Pakete weiter, ohne die Nutzlast zu überwachen. NAT wird bei Bedarf für den Header ausgeführt.Ein
DropDatenstrom verwirft jedes Paket, das dem Tupel 5 entspricht.
Die Frame-Anzahl (
Frm count) zeigt die Anzahl der Pakete an, die in diesem Flow verarbeitet wurden.
Die zweite Zeile zeigt die NAT-Informationen.
sourcegibt Quell-NAT an.destzeigt Ziel-NAT an.Die erste Adresse und der erste Port in der NAT-Zeile sind die ursprüngliche Adresse und der Port, die für diesen Flow übersetzt werden.
Die zweite Adresse und der zweite Port in der NAT-Zeile sind die übersetzte Adresse und der Port für diesen Flow.
MX-SPC3-Karte
Auf der MX-SPC3-Servicekarte finden Sie im Folgenden ein vollständiges Beispiel für die Ausgabe des Befehls " show services sessions application-protocol ftp Betriebsmodus":
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:
Die erste Zeile zeigt Flussinformationen an, einschließlich Sitzungs-ID, Service-Set-Name, Richtlinienname, Sitzungs-Timeout, logischer Systemname und Status.
Die zweite Zeile,
Resource information, gibt an, dass die Sitzung von ALG erstellt wurde, 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 Steuerungssitzung und 1 für die Datensitzung ist.Die dritte Zeile
Inist der Vorwärtsfluss und die vierte ZeileOutist der Rückfluss, einschließlich Quelladresse, Quellport, Zieladresse, Zielport, Protokoll (TCP), Session-Conn-Tag, eingehend fürInund ausgehend fürOutSchnittstelle, Anzahl der empfangenen Frames und 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 Systemprotokoll akzeptieren:
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: 1Systemprotokoll "Accept Flow" 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 flowSystemprotokoll für die Datenflusserstellung:
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 CardCard
Die folgenden Systemprotokollmeldungen werden während der Erstellung der FTP-Ablaufsteuerung generiert:
Systemprotokoll für die Erstellung einer FTP-Steuerungssitzung:
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 von FTP-Datensitzungen:
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-Steuerungssitzung:
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
Kontrollflüsse
MS-MPC-Karte
Die Kontrollflüsse werden nach Abschluss des Drei-Wege-Handshakes eingerichtet.
Kontrollfluss 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:50118Ablaufsteuerung 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 Kontrollflüsse werden nach Abschluss des Drei-Wege-Handshakes eingerichtet.
Kontrollsitzung 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 FTP-aktiven 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,
Datenströme
Ein Datenport von 20 wird für die Datenübertragung im Verlauf des FTP-Steuerungsprotokolls ausgehandelt. Diese beiden Flüsse sind 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 Feld ALG-Protokoll in der Konversation sollte angezeigt
ftpwerden.In den Ablaufsteuerungen sollte eine gültige Frameanzahl (
Frm count) vorhanden sein.Eine gültige Frame-Anzahl in den Datenflüssen zeigt an, dass eine Datenübertragung stattgefunden hat.
Was benötige ich, um zu überprüfen, ob die FTP-Verbindung hergestellt ist, aber keine Datenübertragung stattfindet?
Höchstwahrscheinlich ist die Steuerverbindung aktiviert, aber die Datenverbindung ist unterbrochen.
Überprüfen Sie die Konversationsausgabe, um festzustellen, ob sowohl der Kontroll- als auch der Datenfluss vorhanden sind.
Wie interpretiere ich die einzelnen Flows? Was bedeuten die einzelnen Flows?
FTP-Kontroll-Flow-Initiator-Flow – Flow mit Zielport 21
FTP control flow responder flow – Flow mit Quellport ; 21
FTP-Datenfluss-Initiator-Flow – Flow mit Zielport 20
FTP-Datenfluss-Responder-Flow – Flow mit Quellport 20
Beispiel für RTSP ALG
Im Folgenden finden Sie ein Beispiel für eine RTSP-Konversation. 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 dem folgenden:
- Beispielausgabe für MS-MPCs
- Beispielausgabe für MX-SPC3 Services Card
- Analyse
- Fragen zur Fehlerbehebung
Beispielausgabe für MS-MPCs
Hier ist die Ausgabe des Befehls für den show services stateful-firewall conversations Betriebsmodus:
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 MX-SPC3 Services Card
Hier ist die Ausgabe des Befehls für den show services sessions application-protocol rtsp Betriebsmodus:
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-Flows bestehen, die der RTSP-Steuerverbindung entsprechen. Es sollte zwei Flüsse 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-Flow wird vom Quellport 554 gesendet.
Die UDP-Datenströme 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-Flows vorhanden sind.
Das ALG-Protokoll sollte als
rtspangezeigt werden.
Hinweis:Der Status des Flusses wird als
Watchangezeigt, da die ALG-Verarbeitung stattfindet und der Client im Wesentlichen die der Anwendung entsprechende Nutzlast "überwacht" oder verarbeitet. Bei FTP- und RTSP-ALG-Flows sind die Steuerverbindungen immerWatchFlows.Wie überprüfe ich auf ALG-Fehler?
Sie können nach Fehlern suchen, indem Sie den folgenden Befehl eingeben. Jede 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
Systemprotokollmeldungen
Das Aktivieren der Systemprotokollgenerierung und das Überprüfen des Systemprotokolls sind auch für die ALG-Flussanalyse hilfreich. 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. Weitere Informationen zu den Konfigurationsoptionen finden Sie in der Junos OS Administration Library for Routing Devices (Systemebene) oder in der Junos OS Services Interfaces Library for Routing Devices (alle anderen Ebenen).
Auf höchster globaler 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 Dienstregelebene:
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 mit einer Akzeptanzregel übereinstimmte:
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.