¿Tiene una cuenta?
Para la documentación de este producto, se ha apuntado a utilizar un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad étnica, orientación sexual, nivel socio-económico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe el comportamiento de NAT (traducción de direcciones de red) en routers que funcionan como CUBE (Cisco Unified Border Element), CME o CUCME (Cisco Unified Cummunication Manager Express), Gateways y CUSP (Cisco Unified SIP Proxy).
Cisco recomienda que tenga conocimiento sobre estos temas:
La información de este documento se basa en
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. If your network is live, make sure that you understand the potential impact of any command.
La Traducción de Dirección de Red es una técnica comúnmente utilizada para traducir las direcciones IP en los paquetes que fluyen entre las redes usando diferentes espacios de dirección. El propósito de este documento no es revisar NAT. Por el contrario, este documento pretende proporcionar una revisión completa de la NAT tal como se utiliza en las redes VoIP de Cisco. Además, el alcance se limita a los componentes que componen la tecnología MS-Voice.
Figure 1
Nota: Puede ayudar a pensar en NAT como una ayuda para rutear paquetes IP dentro y fuera de las redes usando el espacio de dirección privada. En otras palabras, NAT hace que las direcciones no enrutables sean enrutables
La figura 2 muestra la topología a la que se hace referencia en las ilustraciones siguientes.
Figure 2
Este glosario es fundamental para comprender y describir la NAT
Nota: Esté cómodo con estos términos. Cualquier nota o documento en NAT seguramente se refiere a ellos
Esta es la forma más simple de NAT, donde en cada dirección interna se traduce estáticamente a una dirección externa (y viceversa).
Figure 3
La CLI a la configuración para la traducción anterior es la siguiente
interface Ethernet0/0
IP address 10.1.1.3 255.255.255.0
ip nat inside
!
Interfaz serial0/0
ip address 200.1.1.251 255.255.255.252
ip nat outside <— Requerido![2]
ip nat inside source static 10.1.1.2 200.1.1.2
ip nat inside source static 10.1.1.1 200.1.1.1
En NAT dinámica, cada host interno se mapea a una dirección de un conjunto de direcciones.
La siguiente CLI ilustra la configuración de NAT dinámica
Cuando el conjunto (de direcciones IP) es más pequeño que el conjunto de direcciones que deben traducirse, esta función resulta útil.
La figura 4 ilustra PAT.
Figure 4
La implementación de NAT de Cisco es muy versátil con una serie de opciones. A continuación se enumeran algunas de ellas, pero consulte http:// www.cisco.com /en/US/partner/technologies/tk648/tk361/tk438/technologies_white_paper09186a0080091cb9.html para obtener más información sobre la lista completa de mejoras.
Un orificio en el lenguaje NAT se refiere al mapping entre los tuplas <host IP, port> y <global address, global port>. Permite que el dispositivo NAT utilice el número de puerto de destino (que sería el puerto global) de los mensajes entrantes para mapear el destino nuevamente a la IP de host y al puerto que originó la sesión. Es importante tener en cuenta que los orificios se agotan después de un período de no uso y la dirección pública se devuelve al conjunto NAT.
Entonces, ¿cuáles son los problemas y preocupaciones con NAT en las redes VoIP? Bueno, recuerde que la NAT que hemos discutido hasta ahora (llamada vagamente como NAT básica) sólo traduce la dirección IP en el encabezado del paquete IP y vuelve a calcular la suma de comprobación, por supuesto, pero la señalización VoIP lleva direcciones incrustadas en el cuerpo de los mensajes de señalización. En otras palabras, en la Capa 5
La figura 5 ilustra el efecto de dejar las direcciones IP incrustadas sin traducir. La señalización de llamada se completa correctamente, pero el proxy SIP del proveedor de servicios no puede intentar enrutar los paquetes de medios (RTP) a la dirección de medios enviada por el agente de llamadas.
Figure 5
Otro ejemplo sería el uso del Contacto por parte del terminal SIP: en SDP para comunicar la dirección en la que el terminal desea recibir mensajes de señalización para nuevas solicitudes.
Estos problemas se solucionan mediante una función llamada Application Layer Gateway (ALG).
Un ALG entiende el protocolo utilizado por las aplicaciones específicas que admite (por ejemplo, SIP) y realiza la inspección de paquetes de protocolo y la "reparación" del tráfico a través de él. Para obtener una buena descripción de cómo se han corregido los diversos campos para la señalización de llamadas SIP, refiérase a http://www.voip-info.org/wiki/view/Routers+SIP+.
En los routers Cisco, el soporte para ALG SIP está habilitado, de forma predeterminada, en el puerto TCP estándar 5060. Es posible configurar ALG para que admita puertos no estándar para señalización SIP. Consulte http://www.cisco.com/en/US/docs/ios-xml/ios/ipaddr_nat/configuration/15-mt/nat-tcp-sip-alg.html.
Precaución: ¡Cuidado! No hay ningún RFC u otro estándar que especifique qué campos incrustados deben traducirse para los diversos protocolos VoIP. Como resultado, las implementaciones varían entre los proveedores de equipos, lo que genera problemas de interoperabilidad (y casos TAC).
Puesto que las gateways, por definición, no son dispositivos ip-to-ip, NAT no es aplicable.
Esta sección del documento revisa los escenarios de llamadas con CME para comprender por qué se debe utilizar NAT.
Escenario 1. Teléfonos locales
Situación hipotética 2. Teléfonos remotos (con direcciones IP públicas)
Situación hipotética 3. teletrabajador remoto
Nota: En todos los casos, para que el audio fluya, la dirección IP de CME debe ser enrutable
En esta situación (figura 6), los dos teléfonos que participan en la llamada son teléfonos ligeros con direcciones IP privadas.
‘Figura 6’
Nota: Recuerde que el teléfono delgado que está conectado en una llamada con otro teléfono delgado en el mismo sistema CME envía sus paquetes de medios directamente al otro teléfono; Es decir, el RTP para el teléfono local al teléfono local NO fluye a través de CME.
Por lo tanto, NAT no es aplicable o no se requiere en este caso.
Nota: El CME determina si el medio (RTP) debe basarse directamente o no en si los dos teléfonos involucrados en una llamada son delgados y en el mismo segmento de red. De lo contrario, CME se inserta en la trayectoria RTP.
En este escenario (figura 7), CME se inserta en la secuencia RTP de modo que RTP de los teléfonos se termine en el CME. CME volverá a originar los flujos hacia el otro teléfono. Dado que CME se encuentra tanto en la red interna (privada) como en la red externa y envía su dirección interna al teléfono interno y a la dirección externa (pública) al teléfono externo, NAT tampoco es necesaria aquí.
Sin embargo, tenga en cuenta que los puertos UDP/TCP (señalización y RTP) deben estar abiertos entre el teléfono IP remoto y la dirección IP de origen CME. Esto significa que los firewalls u otros dispositivos de filtrado están configurados para permitir los puertos en cuestión.
Figura 7
Nota: Tenga en cuenta que la señalización [mensajes] siempre termina en CM
Esto se refiere a los teléfonos IP que se conectan a CME a través de una WAN para admitir teletrabajadores que tienen oficinas que son remotas desde el router CME. Los diseños más comunes son aquellos que involucran teléfonos con direcciones IP enrutables y teléfonos con direcciones IP privadas.
Si ambos teléfonos involucrados en la llamada se configuran con direcciones IP enrutables públicas, los medios pueden fluir entre los teléfonos directamente (Figura 8). Por lo tanto, una vez más, no se necesita NAT.
Figura 8
En este escenario, la llamada se señala entre teléfonos delgados configurados con direcciones IP privadas. Los routers de oficina doméstica (SOHO), en general, tienden a no ser "conscientes de SCCP". es decir, incapaz de traducir las direcciones IP incrustadas en los mensajes SCCP. Esto significa que, al finalizar la configuración de la llamada, los teléfonos terminan con la dirección IP privada de cada uno. Dado que ambos teléfonos son privados, CME indicará la llamada entre ellos de forma que el audio fluya directamente entre los teléfonos. Sin embargo, esto resultará en audio unidireccional o no-direccional (ya que las direcciones IP privadas, por definición, no se pueden rutear en Internet!), a menos que se implemente una de las siguientes soluciones alternativas-
· Configure las rutas estáticas en los routers SOHO
· establecer una conexión VPN IPsec a los teléfonos
Una mejor manera de resolver esto sería configurar "mtp". El comando mtp garantiza que los paquetes de medios (RTP) de los teléfonos remotos transiten por el router CME (figura 9).
Figura 9
La solución "mtp" es mejor debido a las complicaciones con la apertura de puertos de firewall. Un firewall puede obstruir los paquetes de medios que circulan por una WAN. Esto significa que debe abrir los puertos en el firewall, pero ¿cuáles? Con CME retransmitiendo el audio, los firewalls se pueden configurar fácilmente para pasar los paquetes RTP. El router CME utiliza un puerto UDP específico(2000!) para los paquetes de medios. Por lo tanto, al permitir que los paquetes lleguen y salgan del puerto 2000, TODO el tráfico RTP se puede pasar.
La figura 10 ilustra cómo configurar mtp.
ephone 1
mac 1111.2222.3333
tipo 7965
mtp
botón 1:1
Figura 10
No todo es maravilloso con mtp. Hay situaciones en las que mtp puede no ser deseable
Por lo tanto, si tiene una configuración WAN que puede reenviar paquetes multicast y puede permitir paquetes RTP a través de su firewall, puede decidir no utilizar MTP.
Tenga en cuenta que los teléfonos SIP no se mencionaron en los escenarios anteriores. Esto se debe al hecho de que si uno de los teléfonos es un teléfono SIP, CME se inserta en la trayectoria de audio. Esto se convierte en el escenario de local a remoto descrito anteriormente, donde no se requiere NAT.
El CUBE realiza funciones NAT y PAT de forma inherente a medida que termina y vuelve a originar todas las sesiones. El CUBE sustituye su propia dirección por la dirección de cualquier terminal con el que se comunica, ocultando (traduciendo) de forma efectiva la dirección de ese terminal.
Por lo tanto, no se requiere NAT con la función CUBE. Hay un escenario de servicio VoIP en el que se requiere NAT en el CUBE, como se describe en la siguiente sección.
Un breve resumen sobre el servicio de telefonía alojado ayudará a comprender los fundamentos de esta función.
El servicio de telefonía alojado es una nueva forma de servicio VoIP en el que la mayoría de los equipos residen en la ubicación del proveedor de servicios. Funcionan con las puertas de enlace domésticas (HGW), que implementan solo NAT básica (es decir, NAT en L3/L4). Por ejemplo, Verizon instala el Terminal de red óptica (ONT), que proporciona servicios WiOS en casa; la llamada de voz se señala mediante un proceso SIP integrado en ONT. La señalización SIP se realiza a través de la red IP privada de Verizon a nuevos switches de software, que proporcionan el servicio y el control necesarios para establecer comunicaciones de voz a otros clientes de voz digital de FiOS o a clientes de telefonía tradicional.
Entre los requisitos clave del proveedor para el servicio de telefonía alojado se incluyen:
Teniendo en cuenta lo anterior, ¿qué opciones existen para implementar tal servicio?
La opción NAT SBC satisface los requisitos del proveedor enumerados anteriormente.
El NAT SBC funciona de la siguiente manera (figura 11)
Figura 11
A continuación se muestra la configuración de ejemplo para un SBC NAT típico.
ip nat sip-sbc
proxy 200.200.200.10 5060 15.3.33.22 5060 protocol udp
call-id-pool call-id-pool
session-timeout 300
mode allow-flow-round
puerto de anulación
!
ip nat pool sbc1 15.3.33.61 15.3.33.69 netmask 255.255.0.0
ip nat pool sbc2 15.3.33.91 15.3.33.99 netmask 255.255.0.0
ip nat pool call-id-pool 1.1.1.1 1.1.255.254 netmask 255.255.0.0
ip nat pool outside-pool 200.200.200.100 200.200.200.200.200 netmask 255.255.255.0
ip nat inside source list 1 pool sbc1 overload
ip nat inside source list 2 pool sbc2
ip nat outside source list 3 pool outside-pool add-route
ip nat inside source list 4 pool call-id-pool
!
access-list 1 permit 10.1.1.0 0.0.0.255
access-list 1 permit 171.1.0 0.0.0.255
access-list 2 permit 20.1.1.0 0.0.0.255
access-list 2 permit 172.1.1.0 0.0.0.255
access-list 3 permit 15.4.0.0 0.0.255.255
access-list 3 permit 15.5.0.0 0.0.255.255
access-list 4 permit 10.1.0.0 0.0.255.255
access-list 4 permit 20.1.0.0 0.0.255.255
Las figuras 13 y 14 ilustran el flujo de llamadas en términos de las traducciones. Cabe señalar los siguientes aspectos:
— Teléfono SIP A - 15.3.33.62 2001
— Teléfono SIP B - 15.3.33.62 2002
Figura 13
Figura 14
En las versiones anteriores (de SBC NAT), los terminales SIP tenían que enviar paquetes keepalive para mantener abierto el orificio de entrada del registro SIP (para permitir que saliera->en el tráfico fluyera, por ejemplo, las llamadas entrantes). los paquetes keepalive pueden ser cualquier paquete SIP enviado por el terminal o el registrador (switch de software). Las versiones recientes evitan la necesidad de esto, ya que el propio NAT-SBC (a diferencia de los switches de software) obliga a los terminales a volver a registrarse con frecuencia para mantener los orificios de acceso abiertos.
Nota: Los síntomas de un orificio de registro caducado pueden ser oscuros, con fallas de señalización de llamada aleatoria.
CUSP tiene la noción de una red lógica, que se refiere a una colección de interfaces locales que se tratan de manera similar para (por ejemplo, interfaz, puerto, transporte para escucha). Al configurar una red lógica en CUSP, puede configurarla para que utilice NAT. Una vez configurado, el ALG SIP se habilita automáticamente. Esto es útil cuando ciertas redes lógicas.
Un síntoma obvio podría ser que una llamada falla en una o ambas direcciones. Los síntomas menos obvios podrían incluir:
A continuación se muestra la salida de depuración para un par de escenarios. ¡Se explican por sí solas!
A continuación se muestran las líneas de configuración y depuración para NAT básica.
Se muestran las líneas de salida de debug ip nat sip. En este caso, se traduce la dirección IP incrustada en un paquete saliente.
Información general:
VoiP y NAT
Matriz de características de NAT
NAT transversal alojado:
NAT SBC
ALG:
CME
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
23-May-2017 |
Versión inicial |