ADC
Danke für das Feedback

Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)

Application Layer Gateway für SIP-Protokoll

Die Verwendung von Large Scale NAT (LSN) mit Session Initiation Protocol (SIP) ist kompliziert, da SIP-Nachrichten IP-Adressen sowohl in den SIP-Headern als auch im SIP-Body enthalten. Wenn LSN mit SIP verwendet wird, 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), zu denen IP-Adressen und Portnummern für die Übertragung der Medien gehören.

SIP ALG hält sich an die folgenden RFCs:

  • RFC 3261
  • RFC 3581
  • RFC 456
  • RFC 475

Hinweis

SIP ALG wird in einer eigenständigen NetScaler-Appliance, in einem NetScaler-Hochverfügbarkeits-Setup sowie in einem NetScaler-Cluster-Setup unterstützt.

So funktioniert SIP ALG

Wie die IP-Adressü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

Bei einer ausgehenden Nachricht werden die private IP-Adresse und die Portnummer des SIP-Clients durch die NetScaler-eigene öffentliche IP-Adresse und Portnummer ersetzt, die als LSN-Pool-IP-Adresse und Portnummer bezeichnet werden undwährend der LSN-Konfiguration angegeben wurden. Bei einer eingehenden Nachricht werden die LSN-Pool-IP-Adresse und die Portnummer durch die private Adresse des Clients ersetzt. Wenn die Nachricht öffentliche IP-Adressen enthält, behält das NetScaler SIP ALG diese. Außerdem entsteht eine Lochblende auf der:

  • LSN pool-IP-Adresse und Port im Namen des privaten Clients, sodass die Nachrichten, die aus dem öffentlichen Netzwerk an dieser IP-Adresse und diesem Port ankommen, als SIP-Nachrichten behandelt werden.
  • Öffentliche IP-Adresse und Port im Namen der öffentlichen Clients, sodass die Nachrichten, die vom privaten Netzwerk an dieser IP-Adresse und diesem Port ankommen, als SIP-Nachrichten behandelt werden.

Wenn eine SIP-Nachricht über das Netzwerk gesendet wird, sammelt das SIP Application Layer Gateway (ALG) Informationen aus der Nachricht und übersetzt die IP-Adressen in den folgenden Headern in LSN-Pool-IP-Adressen:

  • Über
  • Kontakt
  • Route
  • Route aufzeichnen

In der folgenden Beispiel-SIP-Anforderungsnachricht ersetzt LSN die IP-Adressen in den Header-Feldern, um sie vor dem externen Netzwerk zu verbergen.

INVITE adam@10.102.185.156 SIP/2.0 Via: SIP/2.0/UDP 192.170.1.161:62914 From: eve@10.120.210.3 To: adam@10.102.185.156 Call-ID: a12abcde@10.120.210.3 Contact: adam@10.102.185.156 Route: <sip:netscreen@10.150.20.3:5060> Record-Route: <sip:netscreen@10.150.20.3:5060>

Wenn eine Nachricht mit SDP-Informationen eingeht, sammelt das SIP-ALG Informationen aus der Nachricht und übersetzt die IP-Adressen in den folgenden Feldern in LSN-Pool-IP-Adressen und Portnummern:

  • c= (Verbindungsinformationen)

    Dieses Feld kann auf Sitzungs- oder Medienebene angezeigt werden. Es wird im folgenden Format angezeigt:

    c=<network-type><address-type><connection-address>

    Wenn die Ziel-IP-Adresse eine Unicast-IP-Adresse ist, erstellt das SIP-ALG Pinholes, indem es die im Feld m= angegebene IP-Adresse und Portnummern verwendet.

  • m= (Medienmitteilung)

    Dieses Feld wird auf Medienebene angezeigt und enthält die Beschreibung des Mediums. Es wird im folgenden Format angezeigt:

    m=<media><port><transport><fmt list>

  • a= (information about the media field)

    Dieses Feld kann auf Sitzungs- oder Medienebene im folgenden Format angezeigt werden:

    a=<attribute>

    a=<attribute>:<value>

Der folgende Auszug aus einem SDP-Beispielabschnitt zeigt die Felder, die für die Ressourcenzuweisung übersetzt wurden.

o=Benutzer 2344234 55234434 DIN IP4 10.150.20.3

C=in IP4 10.150.20.3

m=audio 43249 RTP/AVP 0

Die folgende Tabelle zeigt, wie SIP-Payload übersetzt wird.

     
Eingehende Anfrage (von öffentlich nach privat) In Ohne
Von
Anruf-ID
Über
Anfrage-URI
Kontakt
Route aufzeichnen
Reiseroute
Ausgehende Antwort (von privat nach öffentlich) In Ohne
Von
Anruf-ID
Über
Anfrage-URI
Kontakt
Route aufzeichnen
Reiseroute
Ausgehende Anfrage (von privat nach öffentlich) In Ohne
Von
Anruf-ID
Über
Anfrage-URI
Kontakt
Route aufzeichnen
Reiseroute
Eingehende Antwort (von öffentlich nach privat) In Ohne
Von
Anruf-ID
Über
Anfrage-URI
Kontakt
Route aufzeichnen
Reiseroute

Einschränkungen von SIP ALG

Ein SIP-ALG hat die folgenden Einschränkungen:

  • Nur SDP-Payload wird unterstützt.
  • Folgende Komponenten werden nicht unterstützt:
    • Multicast-IP-Adressen
    • Verschlüsseltes SDP
    • SCHIFF BIS
    • FQDN-Übersetzung
    • SIP-Layer-Authentifizierung
    • TD/Partitionierung
    • Mehrteiliger Körper
    • SIP-Nachrichten über IPv6-Netzwerk
    • Faltung der Leitung

Getestete SIP-Clients und Proxyserver

Die folgenden SIP-Clients und Proxyserver wurden mit SIP ALG getestet:

  • SIP-Kunden: X-Lite, Zoiper, Ekiga. Avaya
  • Proxyserver: OpenSIPS

LSN SIP-Szenario: SIP-Proxy außerhalb des privaten Netzwerks (öffentliches Netzwerk)

SIP-Client-Registrierung

Für einen typischen SIP-Anruf muss sich der SIP-Client beim SIP-Registrar registrieren, indem er eine REGISTER-Anfrage verfasst und an den SIP-Registrar sendet. Das SIP-ALG der NetScaler-Appliance fängt die Anfrage ab, ersetzt die IP-Adresse und Portnummer in der Anfrage durch die LSN-Pool-IP-Adresse und Portnummer, die in der LSN-Konfiguration angegeben sind, und leitet die Anfrage an den SIP-Registrar weiter. Das SIP-ALG öffnet dann ein Loch in der NetScaler-Konfiguration, um die weitere SIP-Kommunikation zwischen dem SIP-Client und dem SIP-Registrar zu ermöglichen. Der SIP-Registrar sendet über die IP-Adresse und Portnummer des LSN-Pools eine 200-OK-Antwort an den SIP-Client. Die NetScaler-Appliance erfasst diese Antwort im Pinhole, und das SIP-ALG ersetzt den SIP-Header und fügt die ursprünglichen SIP-Felder Contact, Via, Route und Record-Route wieder in die Nachricht ein. Das SIP-ALG leitet die Nachricht dann an den SIP-Client weiter. Die folgende Abbildung zeigt, wie SIP ALG LSN in einem Ablauf zur SIP-Anrufregistrierung verwendet.localized image

Ausgehende Anrufe

Ein SIP-Anruf wird mit einer SIP INVITE-Nachricht initiiert, die vom internen an das externe Netzwerk gesendet wird. Das SIP-ALG führt NAT für die IP-Adressen und Portnummern in den SIP-Headerfeldern Via, Contact, Route und Record-Route durch und ersetzt sie durch die IP-Adresse und Portnummer des LSN-Pools. LSN speichert diese Zuordnungen für nachfolgende SIP-Nachrichten im SIP-Anruf. Das SIP-ALG öffnet dann separate Pinholes in der NetScaler-Konfiguration, sodass SIP und Medien über die NetScaler-Appliance an den dynamisch zugewiesenen Ports, die in den SDP- und SIP-Headern angegeben sind, übertragen werden können. Wenn eine 200 OK-Meldung beim NetScaler eingeht, wird sie von einer der erstellten Pinholes erfasst. Das SIP-ALG ersetzt den SIP-Header, stellt die ursprünglichen SIP-Felder Contact, Via, Route und Record-Route wieder her und leitet die Nachricht dann an den internen SIP-Client weiter.localized image

Eingehende Anrufe

Ein eingehender SIP-Anruf wird mit einer SIP INVITE-Nachricht vom externen Client an das interne Netzwerk initiiert. Der SIP-Registrar leitet die INVITE-Nachricht an den SIP-Client im internen Netzwerk weiter und verwendet dabei die Pinhole, die erstellt wurde, als sich der interne SIP-Client beim SIP-Registrar registriert hat.

Das SIP-ALG führt NAT für die LSN-IP-Adressen und Portnummern in den SIP-Headerfeldern Via, Contact, Route und Record-Route durch, übersetzt sie in die IP-Adresse und Portnummer des internen SIP-Clients und leitet die Anfrage an den SIP-Client weiter. Wenn die vom internen SIP-Client gesendete 200-OK-Antwortnachricht an der NetScaler-Appliance ankommt, führt das SIP-ALG NAT für die IP-Adressen und Portnummern in den SIP-Headerfeldern Via, Contact, Route und Record-Route durch, übersetzt sie in die IP-Adresse und Portnummer des LSN-Pools, leitet die Antwortnachricht an den SIP-Registrar weiter und öffnet dann eine Lochblende in ausgehender Richtung für die weitere SIP-Kommunikation.localized image

Beendigung des Anrufs

Die BYE-Nachricht beendet einen Anruf. Wenn das Gerät eine BYE-Nachricht empfängt, übersetzt es die Header-Felder in der Nachricht genauso wie bei jeder anderen Nachricht. Da jedoch eine BYE-Nachricht vom Empfänger mit 200 OK bestätigt werden muss, verzögert das ALG den Anruf-Teardown um 15 Sekunden, um Zeit für die Übertragung der 200 OK zu haben.

Telefonieren zwischen Clients im selben Netzwerk

Wenn sowohl Client A als auch Client B im selben Netzwerk einen Anruf initiieren, werden die SIP-Nachrichten über den SIP-Proxy im externen Netzwerk weitergeleitet. Das SIP-ALG verarbeitet die INVITE von Client A als normalen ausgehenden Anruf. Da sich Client B im selben Netzwerk befindet, sendet der SIP-Proxy das INIVITE zurück an die NetScaler-Appliance. Das SIP-ALG untersucht die INIVITE-Nachricht, stellt fest, dass sie die NAT-IP-Adresse von Client A enthält, und ersetzt diese Adresse durch die private IP-Adresse von Client A, bevor die Nachricht an Client B gesendet wird. Sobald der Anruf zwischen den Clients hergestellt ist, ist der NetScaler nicht an der Medienübertragung zwischen den Clients beteiligt.

Weitere LSN-SIP-Szenarien: SIP-Proxy im privaten Netzwerk

Wenn Sie den SIP-Proxyserver im privaten Netzwerk hosten möchten, empfiehlt Citrix, dass Sie einen der folgenden Schritte ausführen:

  • Konfigurieren Sie eine statische LSN-Zuordnung für den privaten SIP-Proxy. Weitere Informationen finden Sie unter Konfigurieren von statischen LSN-Maps. Stellen Sie sicher, dass der NAT-Port mit dem Port identisch ist, der im SIP-ALG-Profil konfiguriert ist.
  • Konfigurieren Sie den SIP-Proxyserver in einer entmilitarisierten Zone (DMZ).

Abbildung 1. SIP-Anrufregistrierung

localized image

Abbildung 2. Ablauf eingehender SIP-Anrufe

localized image

Die Abbildungen 1 und 2 zeigen die folgenden Szenarien:

  • Szenario 1: Der SIP-Client im privaten Netzwerk registriert sich beim SIP-Proxyserver im selben Netzwerk. ALG-Operationen werden nicht ausgeführt, da sich der SIP-Client und der SIP-Proxyserver im selben Netzwerk befinden.
  • Szenario 2: Der SIP-Client im öffentlichen Netzwerk registriert sich beim SIP-Proxyserver im privaten Netzwerk. Die REGISTER-Nachricht vom öffentlichen SIP-Client wird mithilfe der auf der Appliance konfigurierten statischen LSN-Zuordnung an die NetScaler-Appliance gesendet, und die Appliance erstellt eine Pinhole für weitere SIP-Operationen.
  • Szenario 3 — Ablauf eingehender SIP-Anrufe. Ein eingehender SIP-Anruf wird mit einer SIP INVITE-Nachricht vom externen zum internen Netzwerk initiiert. Die NetScaler-Appliance empfängt die INVITE-Nachricht vom SIP-Client C2, der sich im externen Netzwerk befindet, über die auf der NetScaler-Appliance konfigurierten statischen LSN-Maps.
    Die Appliance erstellt eine Pinhole und leitet die INVITE-Nachricht an den SIP-Proxy weiter. Der SIP-Proxy leitet dann die INVITE-Nachricht an den SIP-Client C1 im internen Netzwerk weiter. Der SIP-Client C1 sendet dann 180 und 200 OK-Nachrichten an den SIP-Proxy, der die Nachricht wiederum über die NetScaler-Appliance an den SIP-Client C2 weiterleitet. Wenn die vom internen SIP-Client C1 gesendete 200-OK-Antwortnachricht beim NetScaler eingeht, führt das SIP-ALG NAT für die IP-Adressen und Portnummern in den SIP-Headerfeldern Via, Contact, Route und Record-Route sowie in den SDP-Feldern durch und ersetzt sie durch die IP-Adresse und Portnummer des LSN-Pools. Das SIP-ALG leitet die Antwortnachricht dann an den SIP-Client C2 weiter und öffnet in ausgehender Richtung eine Pinhole für die weitere SIP-Kommunikation.

Unterstützung für Audit-Logs

Sie können ALG-Informationen als Teil der LSN-Protokollierung protokollieren, indem Sie ALG in der LSN-Überwachungsprotokollierungskonfiguration aktivieren. Weitere Informationen zur LSN-Protokollierung finden Sie unter LSN protokollieren und überwachen. Eine Protokollmeldung für einen ALG-Eintrag im LSN-Protokoll besteht aus folgenden Informationen:

  • Zeitstempel
  • Art der SIP-Nachricht (z. B. SIP-Anfrage)
  • Quell-IP-Adresse und Port des SIP-Clients
  • Ziel-IP-Adresse und Port des SIP-Proxys
  • NAT-IP-Adresse und Port
  • SIP-Methode
  • Sequenznummer
  • Ob der SIP-Client registriert ist oder nicht
  • Benutzername und Domain des Anrufers
  • Benutzername und Domäne des Empfängers

Beispiel für ein Audit-Protokoll:

Anfrage:

07/19/2013:09:49:19 GMT Informational 0-PPE-0 : default ALG ALG_SIP_INFO_PACKET_EVENT 169 0 : Infomsg: "SIP request" - Group: g2 - Call_ID: NTY0YjYwMTJmYjNhNDU5ZjlhMmQxOTM5ZTE3Zjc3NjM. - Transport: TCP - Source_IP: 192.169.1.165 - Source_port: 57952 - Destination_IP: 10.102.185.156 - Destination_port: 5060 - Natted_IP: 10.102.185.191 - Natted_port: 10313 - Method: REGISTER - Sequence_Number: 3060 - Register: YES - Content_Type: - Caller_user_name: 156_pvt_1 - Callee_user_name: 156_pvt_1 - Caller_domain_name: - Callee_domain_name: -

Antwort:

07/19/2013:09:49:19 GMT Informational 0-PPE-0 : default ALG ALG_SIP_INFO_PACKET_EVENT 170 0 : Infomsg: "SIP response" - Group: g2 - Call_ID: NTY0YjYwMTJmYjNhNDU5ZjlhMmQxOTM5ZTE3Zjc3NjM. - Transport: TCP - Response_code 200 - Source_IP: 10.102.185.156 - Source_port: 5060 - Destination_IP: 192.169.1.165 - Destination_port: 57952 - Natted_IP: 10.102.185.191 - Natted_port: 10313 - Sequence_Number: 3060 - Content_Type: - Caller_user_name: 156_pvt_1 - Callee_user_name: 156_pvt_1 - Caller_domain_name: - Callee_domain_name: -

Konfiguration von SIP ALG

Sie müssen die SIP ALG als Teil der LSN-Konfiguration konfigurieren. Anweisungen zum Konfigurieren von LSN finden Sie unter Konfigurationsschritte für LSN. Stellen Sie beim Konfigurieren von LSN sicher, dass Sie:

  • Stellen Sie beim Hinzufügen des LSN-Anwendungsprofils die folgenden Parameter ein:
    • IP-Pooling = GEPAART
    • Adress- und Portzuordnung = ENDPUNKTUNABHÄNGIG
    • Filterung = ENDPUNKTUNABHÄNGIG

Wichtig: Damit das SIP-ALG funktioniert, ist eine vollständige Cone NAT-Konfiguration erforderlich.

Beispiel:

add lsn appsprofile app_tcp TCP -ippooling PAIRED -mapping ENDPOINT-INDEPENDENT -filtering ENDPOINT-INDEPENDENT
  • Erstellen Sie ein SIP-ALG-Profil und stellen Sie sicher, dass Sie entweder den Quellportbereich oder den Zielportbereich definieren.

Beispiel:

add lsn sipalgprofile sipalgprofile_tcp -sipsrcportrange 1-65535 -sipdstportrange 5060 -openViaPinhole ENABLED -openRecordRoutePinhole ENABLED –sipTransportProtocol TCP
  • Stellen Sie SIP ALG = ENABLED ein, während Sie die LSN-Gruppe erstellen.

Beispiel:

add lsn group g1 -clientname c1 -sipalg ENABLED
  • Binden Sie das SIP-ALG-Profil an die LSN-Gruppe.

Beispiel für eine SIP-ALG-Konfiguration:

Die folgende Beispielkonfiguration zeigt, wie Sie eine einfache LSN-Konfiguration mit einem einzelnen Teilnehmernetzwerk, einer einzelnen LSN-NAT-IP-Adresse, einer SIP-ALG-spezifischen Einstellung erstellen und SIP-ALG konfigurieren:

add lsn pool p1 Done bind lsn pool p1 10.102.185.190 Done add lsn client c1 Done bind lsn client c1 -network 192.170.1.0 -netmask 255.255.255.0 Done add lsn appsprofile app_tcp TCP -ippooling PAIRED -mapping ENDPOINT-INDEPENDENT -filtering ENDPOINT-INDEPENDENT Done add lsn appsprofile app_udp UDP -ippooling PAIRED -mapping ENDPOINT-INDEPENDENT -filtering ENDPOINT-INDEPENDENT Done bind lsn appsprofile app_tcp 1-65535 Done bind lsn appsprofile app_udp 1-65535 Done add lsn sipalgprofile sipalgprofile_tcp -sipdstportrange 5060 -openViaPinhole ENABLED -openRecordRoutePinhole ENABLED –sipTransportProtocol TCP Done add lsn sipalgprofile sipalgprofile_udp -sipdstportrange 5060 -openViaPinhole ENABLED -openRecordRoutePinhole ENABLED -sipTransportProtocol UDP Done add lsn group g1 -clientname c1 -sipalg ENABLED Done bind lsn group g1 -poolname p1 Done bind lsn group g1 -appsprofilename app_tcp Done bind lsn group g1 -appsprofilename app_udp Done bind lsn group g1 -sipalgprofilename sipalgprofile_tcp Done bind lsn group g1 -sipalgprofilename sipalgprofile_udp Done
Die offizielle Version dieses Inhalts ist auf Englisch. Für den einfachen Einstieg wird Teil des Inhalts der Cloud Software Group Dokumentation maschinell übersetzt. Cloud Software Group hat keine Kontrolle über maschinell übersetzte Inhalte, die Fehler, Ungenauigkeiten oder eine ungeeignete Sprache enthalten können. Es wird keine Garantie, weder ausdrücklich noch stillschweigend, für die Genauigkeit, Zuverlässigkeit, Eignung oder Richtigkeit von Übersetzungen aus dem englischen Original in eine andere Sprache oder für die Konformität Ihres Cloud Software Group Produkts oder Ihres Diensts mit maschinell übersetzten Inhalten gegeben, und jegliche Garantie, die im Rahmen der anwendbaren Endbenutzer-Lizenzvereinbarung oder der Vertragsbedingungen oder einer anderen Vereinbarung mit Cloud Software Group gegeben wird, dass das Produkt oder den Dienst mit der Dokumentation übereinstimmt, gilt nicht in dem Umfang, in dem diese Dokumentation maschinell übersetzt wurde. Cloud Software Group kann nicht für Schäden oder Probleme verantwortlich gemacht werden, die durch die Verwendung maschinell übersetzter Inhalte entstehen können.