Échec des services téléphoniques MRA en raison de la traduction IP source sur réflexion NAT (configuration d'une carte réseau unique avec NAT statique activée)

Options de téléchargement

  • PDF     (428.4 KB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
  • ePub     (411.0 KB)
    Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
  • Mobi (Kindle)     (220.3 KB)
    Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils
Mis à jour:20 octobre 2017
ID du document:212347

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

    Introduction


    Ce document décrit comment dépanner les pannes de services téléphoniques sur MRA causées par la traduction IP source sur réflexion NAT, avec Expressway-E single-NIC avec configuration NAT statique.

    Conditions préalables

    Cisco vous recommande de prendre connaissance des rubriques suivantes :

    • NAT (Network Address Translation)
    • SIP (Session Initiation Protocol)
    • Configuration de base de Cisco Video Communication Server (VCS) ou Expressway
    • Accès mobile et distant (MRA) sur Expressway ou VCS

    Components Used

    Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

    The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

    Remarque : Dans l’ensemble du document, les périphériques Expressway sont appelés Expressway-E et Expressway-C. Cependant, la même configuration s’applique aux périphériques Expressway et VCS Control de Video Communication Server (VCS). 

    Informations générales

    Ce document couvre un scénario dans lequel l’accès mobile et distant a été déployé sur Expressway avec Expressway-E à l’aide d’une seule carte réseau et d’une adresse NAT statique (décrite comme DMZ de pare-feu à 3 ports utilisant une interface LAN Expressway-E unique, comme décrit dans le Guide de configuration de base d’Expressway). Les utilisateurs MRA peuvent se connecter correctement, mais n'ont pas accès aux services téléphoniques.


    Le message SIP REGISTER du client externe est reçu par Expressway-E sur le port 5061.
    Expressway-E crée ensuite un message SIP SERVICE vers Expressway-C. Cette requête entraîne un délai d’attente de la requête 408.

    Problème


    Les services téléphoniques échouent car le message SIP REGISTER ne passe pas par Cisco Unified Communications Manager (CUCM ou Call Manager). Expressway-E et Expressway-C ne peuvent pas échanger leurs certificats correctement à l’aide de l’échange de messages SIP SERVICE. Les messages SIP SERVICE obtiennent uniquement un délai d’attente de requête 408 en réponse de l’Expressway-C. Comme le message SIP SERVICE échoue, l’Expressway-E ne transmet pas le message SIP REGISTER à l’Expressway-C.
    Ceci est dû au fait que le pare-feu entre Expressway-C et Expressway-E effectue la traduction IP (et port) source des messages de l’Expressway-C vers l’Expressway-E. Cela entraîne le routage incorrect de ces messages SIP SERVICE vers cette adresse traduite, au lieu de sa propre adresse locale. Dans un scénario réussi, l’Expressway-C traite le message SIP SERVICE lui-même. (Le message SIP SERVICE entre Expressway-E et Expressway-C est utilisé pour vérifier les certificats et n’est donc visible qu’au début de la configuration d’une zone de traversée, ou lors de la première inscription sur MRA.)

    Diagramme du réseau

    L'image suivante fournit un exemple de diagramme de réseau, qui est utilisé comme référence dans ce document :

    Détails


    À partir des captures de paquets Expressway-C, vous pouvez voir que l’Expressway-C (10.0.30.2) se connecte correctement à l’adresse IP publique NAT statique Expressway-E (64.100.0.10) sur le port 7003. (Notez que le port source est 27901 sur l’Expressway-C) : 

    Dans les captures de paquets de l’Expressway-E, vous pouvez voir que la connexion provient de 64.100.0.10 sur le port 4401 (qui est sa propre adresse IP publique NAT statique) avec la destination 10.0.10.2 et le port 7003 :

    Voici les perspectives de la connexion entre Expressway-C et E :

     Expressway-C: 10.0.30.2:27901 <-> 64.100.0.10:7003
     Expressway-E: 64.100.0.10:4401 <-> 10.0.10.2:7003


    Cela indique que le pare-feu entre Expressway-C et Expressway-E effectue la traduction IP et de port source sur ces messages.
    Si vous regardez le flux de communication SIP sur Expressway-E, vous pouvez voir qu’il obtient le SIP REGISTER du périphérique client MRA, alors Expressway-E génère un message SIP SERVICE pour échanger ses certificats avec Expressway-C, mais cela donne un délai d’attente de requête 408.


    Preuves dans les journaux de diagnostic

    Notez que l’en-tête de route de ce message SIP SERVICE (envoyé d’Expressway-E à Expressway-C) contient l’adresse IP et le port de l’adresse NAT (64.100.0.10:4401).
    Lorsque ce message arrive à l’Expressway-C, Expressway-C tente de router le message en fonction de cet en-tête de route, vers 64.100.0.10:4401. Cette opération échoue car elle ne peut pas établir de connexion à cette adresse, car cette adresse se trouve du côté du serveur Expressway-E. Même si Expressway-C peut se connecter à cette adresse, elle n’est pas correcte car le message SIP SERVICE est destiné à la réception et au traitement d’Expressway-C. 

    Le message SIP SERVICE arrive à Expressway-C :

    2016-04-19T17:09:13+10:00 expc tvcs: UTCTime="2016-04-19 07:09:13,973" Module="network.sip" Level="DEBUG":  Action="Received"  Local-ip="10.0.30.2"  Local-port="27901"  Src-ip="64.100.0.10"  Src-port="7003"  Msg-Hash="123456789123456789"
 SIPMSG:
 |SERVICE sip:serviceserver@cucm02.example.local SIP/2.0
 Via: SIP/2.0/TLS 64.100.0.10:7003;egress-zone=UCTraversal;branch=[branchID];proxy-call-id=[callid];rport
 Via: SIP/2.0/TCP 127.0.0.1:5060;branch=[branchID];received=127.0.0.1;rport=25063;ingress-zone=DefaultZone
 Call-ID: abcd12345678@127.0.0.1
 CSeq: 4616 SERVICE
 Contact: <sip:serviceproxy@cucm02.example.local>
 From: <sip:serviceproxy@cucm02.example.local>;tag=0987654321aaaa
 To: <sip:serviceserver@cucm02.example.local>
 Max-Forwards: 15
 Route: <sip:64.100.0.10:4401;transport=tls;apparent;ds;lr>
 Route: <sip:127.0.0.1:22210;transport=tcp;vcs-cate;lr>
 User-Agent: TANDBERG/4132 (X8.7.2)
 Date: Tue, 19 Apr 2016 07:09:13 GMT
 Event: service
 P-Asserted-Identity: <sip:serviceproxy@cucm02.example.local>
 X-TAATag: e90b4983919b1f7a46d38f835
 Identity: "7ioJ9gpsS5ob2TUAttNxBGYRWDbnRuf5skrkxP+B14ngRvjkIWIu7BQP5W7vW1BTVyVaGuubV5u7rPDc5anDx9u46i/8TkxxYuxkr83DEh/cYPWlwO7JvTP5nub6/EtEt6RXvwizY6Gm/MXV4eMqQJ06kA86EFxP1SsRxop0YjUs61B10JnBrtQjOicskoAuMGzNjiBKvcCAbrASGtWP015vRp9khcs3e8vmkpZH5Qtef6+gNaRWPES3MS=="
 Content-Type: multipart/mixed;boundary=boundary-6j7zrmj35ifsu3efg5ga603hnz1nbf
 Content-Length: 2555
 
 --boundary-6j7zrmj35ifsu3efg5ga603hnz1nbf
 Content-Type: application/text
 
 <?xml version="1.0" encoding="utf-8"?> <methodCall><params><username>john.smith</username><realm>expe.example.com</realm><nonce>2i78worv9unccs6vbclfi4xai78worv9unccs6vbclfi4xa4i15j</nonce><qop>auth</qop><cnonce>54f80570</cnonce><nc>00000001</nc><response>2i78worv9unccs6vbclfi4xa4i15j</response><uri>sip:cucm02.example.local</uri><method>REGISTER</method><id>12345678</id><caching-enabled>true</caching-enabled><reqtype>collab-edge</reqtype></params><methodName>DigestAuth</methodName><version>1.0</version><msgid>12345678979</msgid><sipdomain>cucm02.example.local</sipdomain></methodCall>
 
 --boundary-6j7zrmj35ifsu3efg5ga603hnz1nbf
 Content-Type: application/x-x509-ca-cert
-----BEGIN CERTIFICATE-----
hknS5nQ8NJEspxLPY0N4BvA8iL7ZasOqnqgHRlj95N8bn
OfigoKhe90kV6Y7PRbRpwFv6jGiFR8hyepr3t2BPec0aZ
ZAK3ZC92RQbDjCxy2U99L8WLlTpJQwIuTjLHicbiNCNZu
Be9xEMgewwGFVfSzW08DzlecJNXpsKqQ0ivbpLbwreXJG
SCbcse3O67yvghMDsotcK4gur11FZWOZJFa3EMlgoT3Mj
ApGvMfL9caTjY1EaLWDl5rWGGe8FpRLCizrz0wwUGg7Px
Moy6kAujtolwN9BUI0sgJ98MnBuuREJZNW7g7nJL5zywT
FXhMgy9PBUMuwjgu5KruY4caWDYtNu1kZzCtnm044lOk7
xhIOoOWWj9sNFnDQGDrgBIFBjggEihSbZr6h4Pq2ZMZ4r
i5yGpz0j7a6lg2NOKm6FXpfqVlB7zvyQsM6x0XJEImpjV
al0nHYkTLkBEmK5jVosgyOrSWpZPimc364sRxRW4ABZZX
M6XstZNGhvQNDVk1JlfCN5yRtEgEkkizeWOHJcts922wL
2rVTfUfWGXMkca8YHKj2ixkthNnHVbLG0YoUNOUDHq1xu
49F7Kcw7neuQQZ4MmEif59lnyhY7qEIQVEpGn0jgqZAX8
omNVxTewa9nTXvjxo5xvTLghYfESCqniBbtWwMhhRuR7N
eh09OvFWsuUyHJmDBYpoNZWTXEB4Fw5XwfjzZAoHzOFV6
xcE4LGYrpI4EbaZ58r8uVrfXkrNrgepFw2zMgamhwf9n5
AzEU2gh9vTUNZEAn8De5XQKAipeehO8Dpef2JTBLV5avf
nh7rfxh8BZY4xteSRox8iBnT4Na6qsDMb2gvp6gTYFFJH
RGMHIe5siI1HhARqDjen4EwrKfMOYNJWTqmx4mjDrqyme
 -----END CERTIFICATE-----
 
 
  |

2016-04-19T17:09:13+10:00 expc tvcs: UTCTime="2016-04-19 07:09:13,977" Module="developer.sip.leg" Level="INFO" CodeLocation="ppcmains/sip/sipproxy/SipProxyLeg.cpp(10047)" Method="SipProxyLeg::routeViaNettleIfNeeded" Thread="0x3150905deea6":  this="0xc76759f343ca" Type="Outbound"  routingViaNettle="false"  twoInARow="false" oneIsATraversalServerZone="false" isCall="false" isRefer="false" fromClusterPeer="false" fromNettle="false" toNettle="false" inboundZone=UC_Traversal (encryption-mode=on ice-mode=off) outboundZone=DefaultZone (encryption-mode=auto ice-mode=off) encryptionSettingsRequireNettle="true" iceSettingsRequireNettle="false" needlesslyNettling="false" routeViaNettle="false"


    Expressway-C tente d’envoyer ce message SIP SERVICE sur ce qu’il indique dans l’en-tête de route, mais la connexion échoue : 

    2016-04-19T17:09:13+10:00 expc tvcs: UTCTime="2016-04-19 07:09:13,979" Module="network.tcp" Level="DEBUG":  Src-ip="10.0.30.2" Src-port="27921" Dst-ip="64.100.0.10" Dst-port="4401" Detail="TCP Connecting"
2016-04-19T17:09:13+10:00 expc tvcs: UTCTime="2016-04-19 07:09:13,980" Module="network.tcp" Level="ERROR":  Src-ip="10.0.30.2" Src-port="27921" Dst-ip="64.100.0.10" Dst-port="4401" Detail="TCP Connection Failed"

    Dans la capture de paquets d’Expressway-C, la tentative SYN TCP obtient une réponse RST : 

     En conséquence, Expressway-C envoie un délai de requête 408 vers l’Expressway-E : 

    2016-04-19T17:09:13+10:00 expc tvcs: UTCTime="2016-04-19 07:09:13,982" Module="network.sip" Level="INFO":  Action="Sent"  Local-ip="10.0.30.2"  Local-port="27901"  Dst-ip="64.100.0.10"  Dst-port="7003"   Detail="Sending Response Code=408, Method=SERVICE, CSeq=4616, To=sip:serviceserver@cucm02.example.local, Call-ID=abcd12345678@127.0.0.1, From-Tag=0987654321aaaa, To-Tag=0987654321bbbb, Msg-Hash=123456789123456789"
2016-04-19T17:09:13+10:00 expc tvcs: UTCTime="2016-04-19 07:09:13,982" Module="network.sip" Level="DEBUG":  Action="Sent"  Local-ip="10.0.30.2"  Local-port="27901"  Dst-ip="64.100.0.10"  Dst-port="7003"  Msg-Hash="123456789123456789"
 SIPMSG:
 |SIP/2.0 408 Request Timeout
 Via: SIP/2.0/TLS 64.100.0.10:7003;egress-zone=UCTraversal;branch=[branchID];proxy-call-id=[callid];received=64.100.0.10;rport=7003;ingress-zone=UCTraversal;ingress-zone-id=4
 Via: SIP/2.0/TCP 127.0.0.1:5060;branch=[branchID];received=127.0.0.1;rport=25063;ingress-zone=DefaultZone
 Call-ID: abcd12345678@127.0.0.1
 CSeq: 4616 SERVICE
 From: <sip:serviceproxy@cucm02.example.local>;tag=0987654321aaaa
 To: <sip:serviceserver@cucm02.example.local>;tag=0987654321bbbb
 Server: TANDBERG/4132 (X8.7.2)
 Warning: 399 10.0.30.2:5061 "Request Timeout"
 Content-Length: 0

    Solution

    Il existe deux solutions possibles à cette situation.

    Désactiver la traduction de port IP source sur le pare-feu

    Si vous désactivez la traduction IP/port source sur le pare-feu, le serveur Expressway-E voit le trafic Expressway-C comme provenant de 10.0.30.2:27901 (IP et port réels sur l’Expressway-C) au lieu de 64.100.0.10:4401 (adresse NAT). De cette manière, l’en-tête de route du message SIP SERVICE contient la valeur 10.0.30.2:27901 et à réception de ce message, l’Expressway-C le routera vers lui-même et effectuera un certain traitement sur celui-ci, ce qui donne 200 OK à renvoyer à l’Expressway-E (si tout va bien) qui passera ensuite par proxy via le message SIP REGISTER pour poursuivre le processus d'inscription.

    Passer à une configuration de carte réseau double

    Avec une configuration de carte réseau double sur Expressway-E, il n’est pas nécessaire d’effectuer une réflexion NAT et le problème est évité. Cependant, assurez-vous que le pare-feu interne entre Expressway-E et Expressway-C (s’il est présent) n’effectue pas de traduction IP/port source du trafic entre Expressway-C et Expressway-E (ce qui entraînerait des problèmes similaires).

    Informations connexes

    TAC Authored

    Contribution d’experts de Cisco

    • Steven Janssens
      Cisco TAC Engineer
    • Lisette Baer
      Cisco TAC Engineer
    • Edited by Lidiya Bogdanova
      Cisco TAC Engineer

    Ce document vous est-il utile?

    FeedbackCommentaires

    Contacter Cisco