NAT en VoIP
Contenido
Introducción
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).
Prerequisites
Requirements
Cisco recomienda que tenga conocimiento sobre estos temas:
- SIP (protocolo de inicio de sesión)
- Voz sobre IP (protocolo de Internet)
- Protocolos de ruteo
Componentes Utilizados
La información de este documento se basa en
- Cualquier versión de IOS 12.4T y posterior.
- Cualquier versión de CME
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.
Antecedentes
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.
- NAT básicamente reemplaza la dirección IP dentro de los paquetes con una dirección IP diferente
- Permite que varios hosts de una subred privada compartan (es decir, parecen) una única dirección IP pública para acceder a Internet.
- Por lo general, las configuraciones NAT cambian sólo la dirección IP de los hosts internos
- NAT es bidireccional- Si A se traduce a B en la interfaz interna, B que llega a la interfaz externa se traducirá a A!
- RFC1631
Figure 1
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
- Dirección local interna: la dirección IP asignada a un host en la red interna. Normalmente, la dirección proviene de un espacio de dirección privada.
- Dirección global interna: dirección IP enrutable asignada por la NIC o el proveedor de servicios que representa una o más direcciones IP locales internas al mundo exterior.
- Dirección local externa: la dirección IP de un host externo tal como aparece en la red interna. No necesariamente una dirección legítima, está asignada desde un espacio de dirección enrutable en el interior.
- Dirección global externa: la dirección IP asignada a un host en la red externa por el propietario del host. La dirección se asigna desde una dirección enrutable globalmente o desde un espacio de red.
NAT estática
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
NAT dinámica
En NAT dinámica, cada host interno se mapea a una dirección de un conjunto de direcciones.
- Asigna una dirección IP de un conjunto de direcciones globales internas.
- Si un nuevo paquete llega de otro host interno y necesita una entrada NAT, pero todas las direcciones IP agrupadas están en uso, el router simplemente descarta el paquete.
- Básicamente, el conjunto de direcciones globales internas debe ser tan grande como el número máximo de hosts simultáneos que necesitan utilizar Internet al mismo tiempo
La siguiente CLI ilustra la configuración de NAT dinámica
Sobrecarga NAT (PAT)
Cuando el conjunto (de direcciones IP) es más pequeño que el conjunto de direcciones que deben traducirse, esta función resulta útil.
- Varias direcciones internas NATed a sólo una o pocas direcciones externas
- PAT (Traducción de dirección de puerto) utiliza números de puerto de origen únicos en la dirección IP global interna para distinguir entre traducciones. Debido a que el número de puerto está codificado en 16 bits, el número total podría ser teóricamente de hasta 65.536 por dirección IP. PAT intentará conservar el puerto de origen original, si este puerto de origen ya está asignado, PAT intentará encontrar el primer número de puerto disponible
- La sobrecarga de NAT puede utilizar más de 65 000 puertos, lo que le permite ampliarse bien sin necesidad de muchas direcciones IP registradas, en muchos casos, con la necesidad de una sola dirección IP global externa.
La figura 4 ilustra PAT.
Figure 4
Opciones del comando NAT
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.
- Traducciones estáticas con puertos: paquetes entrantes dirigidos a un puerto específico (p. ej. puerto 25, para el servidor SMTP) enviado a un servidor específico.
- Compatibilidad con mapas de ruta: flexibilidad en la configuración de filtros/ACL
- Configuraciones de conjunto más flexibles: para permitir rangos discontinuos de direcciones.
- Conservación del número de host: Traduzca la parte "red" y conserve la parte "host".
margen NAT
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.
NAT en VoIP
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).
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.
Gateways
Puesto que las gateways, por definición, no son dispositivos ip-to-ip, NAT no es aplicable.
CME
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
Local
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’
Por lo tanto, NAT no es aplicable o no se requiere en este caso.
Local a remoto
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
teletrabajador remoto
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.
Teléfonos remotos con uso público (lea: ruteable) direcciones IP
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
Teléfonos remotos con dirección IP privada
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
- MTP no es suave en el uso de la CPU
- Por lo general, el MOH de multidifusión no puede reenviarse a través de una WAN- La función MOH de multidifusión verifica si el MTP está habilitado para un teléfono y si lo está, no envía MOH a ese teléfonoL.
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.
Teléfonos SIP remotos
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.
CUBE
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.
NAT transversal alojado
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:
- NAT traversal remoto: la capacidad de ofrecer servicios de clase 5 a los terminales mediante NAT (que solo puede hacer NAT capa 3!) y dispositivos de firewall (realizando "ALG" de forma remota).
- Compatibilidad con medios compartidos: la capacidad de enviar medios entre dispositivos ubicados de forma conjunta donde no tiene sentido rutear los medios de vuelta a la red IP
- No se ha agregado ningún equipo, lo que elimina la necesidad de agregar ningún CPE.
Teniendo en cuenta lo anterior, ¿qué opciones existen para implementar tal servicio?
- Reemplace el HGW por un costoso ALG,
- Utilice un controlador de borde de sesión (SBC) para modificar los encabezados SIP incrustados para los paquetes. Esto implica que un producto alojado en red de clase operador admita SIP en una configuración muy segura y tolerante a fallos. Esta solución se denomina NAT SBC.
La opción NAT SBC satisface los requisitos del proveedor enumerados anteriormente.
NAT SBC
El NAT SBC funciona de la siguiente manera (figura 11)
- El router de acceso traduce solamente la dirección IP L3/L4
- Dirección IP en el mensaje SIP no traducido
- La NAT SBC intercepta y traduce la dirección IP integrada. En el momento en que el SBC ve los paquetes SIP destinados a 200.200.200.10, inicia el código nat-sbc.
- Los medios no se traducen y van directamente entre los teléfonos [5]
Figura 11
Notas de diseño
- La dirección IP 200.200.200.10 (Figura 12) no se asigna a ninguna interfaz en el NAT SBC. Se configura como la dirección del "proxy" al que el teléfono SIP A y el teléfono SIP B envían mensajes de señalización.
- Los dispositivos domésticos no traducen determinados campos SIP/SDP solo de direcciones (por ejemplo, ID de llamada: ,O= , Advertencia: header & Branch= parámetro. maddr= y received= los parámetros se manejaron solamente en algunos escenarios.) Estos campos son manejados por el NAT SBC, excepto por la autorización de proxy y la traducción de autorización, porque esto interrumpirá la autenticación.
- Si los dispositivos domésticos se configuran para hacer PAT, los agentes de usuario (teléfonos y proxy) deben admitir señalización simétrica [6] y medios simétricos y tempranos. Debe configurar el puerto de reemplazo en el router NAT SBC.
- En ausencia de soporte para señalización simétrica y medios simétricos y tempranos, los routers intermedios deben configurarse sin PAT y la dirección de reemplazo debe configurarse en el NAT SBC.
Configuración
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
Flujo de llamadas con NAT SBC
Las figuras 13 y 14 ilustran el flujo de llamadas en términos de las traducciones. Cabe señalar los siguientes aspectos:
- Tras el registro, el switch de software indica que los dos teléfonos están desactivados como
— Teléfono SIP A - 15.3.33.62 2001
— Teléfono SIP B - 15.3.33.62 2002
- En este flujo de llamada, la NAT SBC deja la dirección IP de medios sin traducir.
Figura 13
Figura 14
Registro SIP
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.
CUSP
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.
Resolución de problemas
Síntomas
Un síntoma obvio podría ser que una llamada falla en una o ambas direcciones. Los síntomas menos obvios podrían incluir:
- Audio unidireccional
- Audio unidireccional al transferir
- Audio sin sentido
- Pérdida del registro SIP
Comandos show y debug
- deb ip nat [sip | skinny]
- show ip nat statistics
- show ip nat translations
Cosas que comprobar
- Asegúrese de que la configuración incluya el comando ip nat inside o el subcomando ip nat outside interface. Estos comandos habilitan NAT en las interfaces, y la designación interna/externa es importante.
- Para NAT estática, asegúrese de que el comando ip nat source static enumere primero la dirección local interna y después la dirección IP global interna.
- Para NAT dinámica, asegúrese de que la ACL configurada para que coincida con los paquetes enviados por el host interno coincida con los paquetes del host, antes de que se haya producido ninguna traducción NAT. Por ejemplo, si una dirección local interna de 10.1.1.1 se debe traducir a 200.1.1.1, asegúrese de que la ACL coincida con la dirección de origen 10.1.1.1, no 200.1.1.1.
- Para NAT dinámica sin PAT, asegúrese de que el conjunto tenga suficientes direcciones IP. Los síntomas de no tener suficientes direcciones incluyen un valor creciente en el segundo contador de pérdidas en el resultado del comando show ip nat statistics , así como ver todas las direcciones en el rango definido en el conjunto NAT en la lista de traducciones dinámicas.
- Para PAT, es fácil olvidar agregar la opción overload en el comando ip nat inside source list. Sin ella, NAT funciona, pero PAT no, lo que a menudo da como resultado que los paquetes de los usuarios no se traduzcan y que los hosts no puedan llegar a Internet.
- Quizás NAT se ha configurado correctamente, pero existe una ACL en una de las interfaces, descartando los paquetes. Observe que IOS procesa las ACL antes de NAT para los paquetes que ingresan a una interfaz y después de traducir las direcciones para los paquetes que salen de una interfaz.
- No olvide configurar "ip nat outside" en la interfaz que se encuentra frente a la WAN (aunque no se traduzca dirección externa).
- Tan pronto como se configura NAT, show ip nat translations no muestra nada. Haga ping una vez y vuelva a comprobarlo.
- Agarre seguimientos de Wireshark en interfaces internas y externas de NAT-SBC
Escenarios
A continuación se muestra la salida de depuración para un par de escenarios. ¡Se explican por sí solas!
NAT básica
A continuación se muestran las líneas de configuración y depuración para NAT básica.
SIP ALG
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.
Referencias
Información general:
- http://www.cisco.com/en/US/partner/Technologies/tk648/tk361/tk438/Technologies_white_paper09186a0080091cb9.html
- Anatomía: http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-3/anatomy.html
- http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094831.shtml
VoiP y NAT
- https://supportforums.cisco.com/docs/DOC-5406
- http://www.juniper.net/techpubs/software/junos-security/junos-security95/junos-security-swconfig-security/id-60290.html
Matriz de características de NAT
- http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080b17919.shtml
- http://www.cisco.com/en/US/Technologies/tk648/tk361/tk438/Technologies_white_paper09186a00801af2b9.html
- http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080b17919.shtml
NAT transversal alojado:
NAT SBC
- EDCS-611622
- EDCS-526070
ALG:
- http://www.cisco.com/en/US/docs/ios-xml/ios/ipaddr_nat/configuration/15-0s/iadnat-applvlgw.html
- http://www.voip-info.org/wiki/view/Routers+SIP+ALG
- http://www.commpartners.us/knowledge/attachments/voip-nat.pdf
- http://www.cisco.com/en/US/partner/docs/ios-xml/ios/ipaddr_nat/configuration/15-mt/nat-tcp-sip-alg.html
CME
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
1.0 |
23-May-2017 |
Versión inicial |
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)