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.
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.
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.
Cisco vous recommande de prendre connaissance des rubriques suivantes :
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).
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.
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.)
L'image suivante fournit un exemple de diagramme de réseau, qui est utilisé comme référence dans ce document :
À 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.
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
Il existe deux solutions possibles à cette situation.
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.
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).