{"id":7612,"date":"2016-08-29T09:52:50","date_gmt":"2016-08-29T14:52:50","guid":{"rendered":"http:\/\/www.servervoip.com\/blog\/?p=7612"},"modified":"2019-06-10T11:11:25","modified_gmt":"2019-06-10T16:11:25","slug":"traduccion-de-direccion-de-red","status":"publish","type":"post","link":"http:\/\/www.servervoip.com\/blog\/traduccion-de-direccion-de-red\/","title":{"rendered":"Traducci\u00f3n de direccion de red"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n <\/div>\n
\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n <\/div>\n<\/div>\n
\n <\/span>\n <\/div>\n<\/div>\n

TRADUCCI\u00d3N DE DIRECCION DE RED:<\/strong> NAT consiste en traducir las direcciones IP (generalmente de privadas a p\u00fablicas) y a veces debe modificar adem\u00e1s las direcciones del Protocolo de Control de Transmisi\u00f3n (TCP) o UDP (puertos) cuando la conexi\u00f3n atraviesa un encaminador o un firewall [72, 73], por lo que algunos autores se refieren a esta t\u00e9cnica como Traducci\u00f3n de Direcci\u00f3n de Red y Puerto (NAPT).<\/p>\n

En la figura se muestra el funcionamiento de NAT. Las direcciones IP pertenecientes a una Red privada se traducen en una \u00fanica direcci\u00f3n de salida a trav\u00e9s del dispositivo NAT. En este caso esa direcci\u00f3n corresponde a la Red 206.245.160.0; sin embargo, esta Red puede abarcar un sin n\u00famero de dispositivos, por lo cual es necesario especificar los puertos de origen y destino para conocer con exactitud el destino de un paquete transmitido. Para establecer un camino desde el cliente con direcci\u00f3n IP de origen 192.168.0.2 al servidor Web, se necesita conocer los puertos para encaminar los mensajes enviados.<\/p>\n

\"Esquema

Esquema de Funcionamiento de NAT<\/p><\/div>\n

Es claro que la cantidad de direcciones de Red que ofrece IPv4 son insuficientes para asignar una direcci\u00f3n a cada nodo que se conecta a Internet. NAT ha sido propuesto como una soluci\u00f3n a corto plazo mientras se desarrolla e implementa IPv6 como una soluci\u00f3n formal a este problema; pero la transici\u00f3n completa a IPv6 no se ha completado.<\/p>\n

NAT adem\u00e1s cumplen la funci\u00f3n de ocultaci\u00f3n, ya que no es posible establecer una conexi\u00f3n desde Internet a una m\u00e1quina de la Red privada, por el simple hecho de que no existir\u00edan caminos en Internet para llegar a \u00e9l.<\/p>\n

Se plantea un problema para el tr\u00e1fico de VoIP cuando atraviesa un dispositivo que emplee NAT. La mayor\u00eda de los protocolos de se\u00f1alizaci\u00f3n de VoIP convencionales s\u00f3lo tratan con la se\u00f1alizaci\u00f3n de una conexi\u00f3n telef\u00f3nica, mientras que el tr\u00e1fico de audio es manejado por otro protocolo y el puerto en el que se env\u00eda este tr\u00e1fico es aleatorio [76]. El encaminador NAT puede ser capaz de manejar el tr\u00e1fico de se\u00f1alizaci\u00f3n, pero no tiene manera de saber que el tr\u00e1fico de audio est\u00e1 relacionado con esta se\u00f1alizaci\u00f3n; como consecuencia, el tr\u00e1fico de audio no se traduce entre los espacios de direcciones y no se env\u00eda correctamente al destinatario.<\/p>\n

A continuaci\u00f3n analizamos las soluciones aportadas por los distintos protocolos de se\u00f1alizaci\u00f3n estudiados para soportar NAT:<\/p>\n

– H.323. El est\u00e1ndar H.323 usa RTP para transportar medios de comunicaci\u00f3n entre los EPs. Por lo tanto, el m\u00e9todo m\u00e1s sencillo para sobrellevar el inconveniente que causa NAT es simplemente reenviar los puertos apropiados a trav\u00e9s de su dispositivo NAT para el cliente interno. Y para recibir llamadas siempre se tendr\u00eda que reenviar el puerto TCP 1720 al cliente. Adem\u00e1s, se tendr\u00eda que reenviar los puertos UDP para el flujo multimedia RTP y los puertos RTCP para el control de flujo.<\/p>\n

Si se tiene un n\u00famero de clientes detr\u00e1s de un dispositivo NAT, otra manera de evitar problemas es utilizar un GK ejecut\u00e1ndose en modo proxy, el cual requiere de un interfaz conectado a la Subred privada y a Internet. El cliente H.323 en la Subred privada as\u00ed como los clientes externos que deseen llamar, deben registrarse en el GK.<\/p>\n

Finalmente, H.323 introdujo en sus \u00faltimas versiones una serie de extensiones para el est\u00e1ndar de videoconferencia, en las que incluyen protocolos de la familia de H.460.x, los cuales se ocupan del firewall y NAT.<\/p>\n

– SIP. Tiene los mismos problemas que padece H.323. Probablemente el mayor obst\u00e1culo t\u00e9cnico de SIP es hacer transacciones a trav\u00e9s de NAT.
\nDebido a que SIP encapsula informaci\u00f3n de direccionamiento en sus<\/p>\n

tramas (frames) de datos a nivel de aplicaci\u00f3n y NAT trabaja a nivel de Red, la informaci\u00f3n de direccionamiento no se modifica autom\u00e1ticamente, y por lo tanto, los flujos de datos no tienen la informaci\u00f3n correcta de direccionamiento para completar la conexi\u00f3n. Adem\u00e1s de esto, los firewalls normalmente integrados con NAT no consideran el flujo multimedia entrante a ser parte de la transacci\u00f3n SIP, lo que podr\u00eda bloquear la conexi\u00f3n.<\/p>\n

Se han planteado soluciones que incluyen emplear: infraestructura ASP para el correcto funcionamiento del sistema de Red sin que el usuario tenga que modificar la configuraci\u00f3n de traducci\u00f3n de direcciones de su encaminador [78], firewalls recientes y Controladores de Frontera de Sesion (SBC), que son dispositivos que solucionan la incompatibilidad de SIP con NAT [79]; pero esto todav\u00eda se considera un defecto en este protocolo, pues causa un sinf\u00edn de problemas para los profesionales de Redes que necesitan conectar los puntos terminales SIP utilizando la infraestructura de Red que actualmente poseen.<\/p>\n

– IAX. Fue dise\u00f1ado deliberadamente para trabajar en dispositivos que utilizan NAT. El uso de un \u00fanico puerto UDP tanto para la se\u00f1alizaci\u00f3n y la transmisi\u00f3n de medios de comunicaci\u00f3n, provoca que este protocolo no presente problemas en topolog\u00edas NAT. Estas consideraciones han ayudado a convertirse a IAX en uno de los protocolos m\u00e1s f\u00e1ciles para la implementaci\u00f3n de Redes.<\/p>\n

– MGCP y MEGACO. El hecho de que RTP utilice un rango de puerto din\u00e1mico hace que sea dif\u00edcil para atravesar firewalls y NAT, ya que NAT cambia la direcci\u00f3n IP de origen y n\u00famero de puerto RTP que ha sido negociado durante el SDP. Con el fin de superar este inconveniente se puede utilizar un servidor de Sesi\u00f3n Transversal de Utilidades para NAT (STUN) con el objetivo de poder descubrir el puerto real.<\/p>\n

[rev_slider captions]
\n[rev_slider ServerVoip]
\n <\/p>\n

\n

Otros m\u00e9todos utilizados en VoIP para trabajar en Redes que utilizan NAT y firewalls son:<\/p>\n

– Que los dispositivos VoIP conozcan la direcci\u00f3n IP p\u00fablica (o nombre DNS) de la NAT.
\n– Que la NAT deba ser configurada para no utilizar direccionamiento din\u00e1mico.
\n– Que la NAT deba ser configurada est\u00e1ticamente para traducir las direcciones privadas a las direcciones p\u00fablicas.<\/p>\n

La desventaja de estos m\u00e9todos es que requieren un administrador del sistema para configurar y administrar los dispositivos VoIP y realizar cambios a las direcciones p\u00fablicas, lo que implica un gasto exagerado en recursos.<\/p>\n

Tomado de:
\nGuti\u00e9rrez, R. (2014). Estudio detallado de los protocolos SIP, H.323 y otros, para la se\u00f1alizaci\u00f3n en VoIP: Estado actual y futuro (tesis de grado). Escuela Superior Polit\u00e9cnica del Litoral, Guayaquil, Ecuador.<\/p>\n

Fuente:
\nhttp:\/\/www.cib.espol.edu.ec\/Digipath\/D_Tesis_PDF\/D-84316.pdf<\/p>\n

DataCenter VoIP<\/h2>\n

Los edificios que alojan a los servidores en Europa y Estados Unidos son los centros de datos m\u00e1s ecol\u00f3gicos y fueron construidos como idea de almac\u00e9n de datos. La ubicaci\u00f3n estrat\u00e9gica en Europa central y en Estados Unidos son las ventajas principales.<\/p>\n

Los Data Centers est\u00e1n perfectamente situados para garantizar conexiones r\u00e1pidas a todos los territorios de Europa y Am\u00e9rica para que todos los clientes se beneficien de la mejor calidad en el servicio brindado. Por otra parte, el edificio que est\u00e1 situado en Europa se encuentra en una de las zonas m\u00e1s ricas de agua subterr\u00e1nea, lo que abre la posibilidad a ServerVoIP de realizar un innovador, ecol\u00f3gico y \u00fanico sistema de refrigeraci\u00f3n de forma natural.<\/p>\n

\"datacenter<\/a>
\n