miércoles, 3 de junio de 2015

NAT (Network Address Translation)

 ¿Qué es NAt?
Traducción de Direcciones de Red, Cuando se inició internet, esta no fue diseñada para ser un red tan extensa como lo es hoy en día, por eso, en esa entonces solo se reservaron 32 bits para direcciones, que es el equivalente a 4,29,467.296 de direcciones IP únicas, pero esta cantidad es insuficiente. Por lo tanto se diseñó NAT, que es un “economizador de direcciones Ip”, es decir que todos los equipos que se encuentren dentro de un segmento de red, se conectan a internet mediante una única dirección IP.




-          Funcionalidades de NAT:

o   S – NAT (Source NAT):
Desde el interno hacia el exterior.
o   D – NAT (Destination NAT)
Desde el exterior hacia el interior. Ejemplo, un servicio Web.




-          Tipos de Nat:
§  NAT estático
Consiste básicamente en un tipo de NAT en el cuál se mapea una dirección IP privada con una dirección IP pública de forma estática. De esta manera, cada equipo en la red privada debe tener su correspondiente IP pública asignada para poder acceder a Internet. La principal desventaja de este esquema es que por cada equipo que se desee tenga acceso a Internet se debe contratar una IP pública. Además, es posible que haya direcciones IP públicas sin usar (porque los equipos que las tienen asignadas están apagados, por ejemplo), mientras que hay equipos que no puedan tener acceso a Internet (porque no tienen ninguna IP pública mapeada). Para configurar este tipo de NAT en Cisco nos valemos de los siguientes comandos, donde se ve que el equipo con IP 192.168.1.6 conectado por medio de la interfaz fastEthernet 0/0 será nateado con la IP pública 200.41.58.112 por medio de la interfaz de salida serial 0/0.
Router(config)# ip nat inside source static 192.168.1.6 200.41.58.112
Router(config)# interface fastEthernet 0/0
Router(config-if)# ip nat inside
Router(config)# interface serial 0/0
Router(config-if)# ip nat outside




§  NAT dinámico

Este tipo de NAT pretende mejorar varios aspectos del NAT estático dado que utiliza un pool de IPs públicas para un pool de IPs privadas que serán mapeadas de forma dinámica y a demanda. La ventaja de este esquema es que si se tienen por ejemplo 5 IPs públicas y 10 máquinas en la red privada, las primeras 5 máquinas en conectarse tendrán acceso a Internet. Si suponemos que no más de 5 máquinas estarán encendidas de forma simultánea nos garantiza que todas las máquinas de nuestra red privada tendrán salida a Internet eventualmente. Para configurar este tipo de NAT definimos el pool de IPs públicas disponibles y el rango de direcciones privadas que deseamos que sean nateadas.

En el siguiente ejemplo se cuenta con las direcciones IPs públicas desde la 163.10.90.2 a la 163.10.90.6 y la subred privada 192.168.1.0/24.

Router(config)# ip nat pool name DIR_NAT_GLOB 163.10.90.2 163.10.90.6 netmask 255.255.255.240
Router(config)# access-list 10 permit 192.168.1.0 0.0.0.255
Router(config)# ip nat inside source list 10 pool DIR_NAT_GLOB
Router(config)# interface fastEthernet 0/0
Router(config-if)# ip nat inside
Router(config)# interface serial 0/0
Router(config-if)# ip nat outside





§  NAT con sobrecarga

El caso de NAT con sobrecarga o PAT (Port Address Translation) es el más común de todos y el más usado en los hogares. Consiste en utilizar una única dirección IP pública para mapear múltiples direcciones IPs privadas. Las ventajas que brinda tienen dos enfoques: por un lado, el cliente necesita contratar una sola dirección IP pública para que las máquinas de su red tengan acceso a Internet, lo que supone un importante ahorro económico; por otro lado se ahorra un número importante de IPs públicas, lo que demora el agotamiento de las mismas.
La pregunta casi obvia es cómo puede ser que con una única dirección IP pública se mapeen múltiples IPs privadas. Bien, como su nombre lo indica, PAT hace uso de múltiples puertos para manejar las conexiones de cada host interno. Veamos esto con el siguiente ejemplo:

La PCA quiere acceder a www.netstorming.com.ar. El socket está formado por:
·         IP origen: PCA.
·         Puerto origen: X.
·         IP destino: www.netstorming.com.ar.
·         Puerto destino: 80.
Al llegar el requierimiento anterior al router que hace PAT, el mismo modifica dicha información por la siguiente:
·         IP origen: router.
·         Puerto origen: Y.
·         IP destino: www.netstorming.com.ar.
·         Puerto destino: 80.
Además, el router arma una tabla que le permite saber a qué máquina de la red interna debe dirigir la respuesta. De esta manera, cuando recibe un segmente desde el puerto 80 de www.netstorming.com.ar dirigido al puerto Y del router, este sabe que debe redirigir dicha información al puerto X de la PCA.
La forma de configurar NAT con sobrecarga es la siguiente.
Router(config)# access-list 10 permit ip 192.168.1.0 0.0.0.255
Router(config)# ip nat inside source list 10 interface serial 0/0 overload
Router(config)# interface fastEthernet 0/0
Router(config-if)# ip nat inside
Router(config)# interface serial 0/0
Router(config-if)# ip nat outsid









jueves, 16 de abril de 2015

ROOT SERVER (Servidores Raíz)


Los Root Servers (Servidores Raíz), son los servidores DNS principales de todo el mundo, estos se encargan de resolver las peticiones DNS para los dominios de más alto nivel. Existen 13 Root Server distribuidos en varios puntos del planeta, principalmente en Estados Unidos. Estos servidores están bajo el dominio: root-servers.org.
Los 13 servidores raíz son los encargados de traducir los nombres de dominio (como www.google.com) a direcciones IP (173.194.115.179), y luego a la inversa. Es decir cada vez que un internauta introduce una dirección de una página web en el navegador o envía un mensaje de correo, está empleando un servidor DNS para traducir las direcciones web a las direcciones IP correspondientes. Todos los servidores DNS de la red dependen de los servidores raíz y el resto del sistema para realizar su trabajo.




Todos los Root Servers usan BIND (Berkeley Internet Name Domain) como servidor DNS, excepto los servidores H, L y K que utilizan NSD (Name Server Daemon). Los Servidores Raíz Distribuidos utilizan anycast para mejorar y equilibrar la carga, dando un servicio descentralizado.

Distribución geográfica de los 13 Servidores
10 en Estados Unidos, 1 en Estocolmo (Suecia), 1 en Londres (Reino Unido) y otro en Japón.
La distribución geográfica de estos 13 servidores de datos pone de manifiesto el origen estadounidense de la Red: 10 de ellos se encuentran en Estados Unidos. Sólo tres se encuentran fuera de sus fronteras: uno en Estocolmo, otro en Londres, y otro en Japón. Dentro de Estados Unidos, la distribución es un tanto peculiar: 6 servidores se encuentran concentrados en un punto muy próximo a Washington y en la costa oeste, más concretamente en el estado de California, son 4 los servidores.
Los trece servidores se denominan por las primeras trece letras del alfabeto, y están en manos de 9 organismos y corporaciones diferentes e independientes, principalmente universidades, empresas privadas y organismos relacionados con el ejército de EEUU. Aproximadamente la mitad depende de organizaciones públicas estadounidenses.




Root Servers

A – VeriSign: Está ubicado en Dulles (Virginia, EEUU). Se encuentra preparado ya para conexiones con IPv6: 2001:503:BA3E::2:30 y actualmente usa IPv4: 198.41.0.4.
B – Instituto para la formación científica: Situado en Marina del Rey (California). También está preparado para conexiones IPv6: 2001:478:65::53. Y también acepta conexiones IPv4: 192.228.79.201.
C – Cogent Communications: Es una multinacional fundada en 1999 situada en Washington. Usa IPv4: 192.33.4.12
D – Universidad de Maryland: Situado en la ciudad College Park. Acepta conexiones IPv4: 128.8.10.90.
E – Centro de investigación Ames de la NASA: El centro de investigación está situado en Silicon Valley (California). Usa conexiones IPv4: 192.203.230.10.
F – Consorcio de Sistemas de Internet (ISC): No es un sólo servidor físico, sino un sistema distribuido de varios servidores DNS a lo largo de diferentes lugares como Ottawa, New York, Madrid, Roma, Paris, Barcelona, Buenos Aires, hasta 43 ciudades. Fue el primero de los 7 servidores DNS distribuidos existentes. También está preparado para conexiones IPv6: 2001:500:2f::f. IPv4: 192.5.5.241
G – Departamento de Defensa de EE.UU.: Se encuentra ubicado en la capital de Ohio. Usa conexiones IPv4: 192.112.36.4.
H – Laboratorio de investigación de la Armada de EE.UU: También está preparado para conexión vía IPv6: 2001:500:1::803f:235 y actualmente soporta IPv4: 128.63.2.53.
I – Autonomica/NORDUnet: Es otro de los servidores distribuidos que abarca hasta 31 ciudades diferentes (Helsinki, Milán, Londrés, Chicago, Bruselas…). Soporta conexiones IPv4: 192.36.148.17.
J – VeriSign: Su segundo servidor, a diferencia del primero, es un servidor distribuido a lo largo de 37 ciudades (Vienna, Miami, Atlanta, Seattle, Tokyo, Seúl, Praga, Madrid…). También esta preparado para conexiones IPv6: 2001:503:C27::2:30 e IPv4: 192.58.128.30.
K – Centro de coordinación de redes IP europeas: Como los anteriores servidores, dispone de una red de distribución (Londres, Amsterdam, Frankfurt, Budapest, Delhi, …). Está preparado para conexiones IPv6: 2001:7fd::1. e IPv4: 193.0.14.129.
L – Corporación de Internet para la Asignación de Nombres y Números: Se basa en un servidor distribuido entre Los Angeles y Miami (Estados Unidos). Soporta conexiones IPv4: 199.7.83.42.
M – WIDE Project: Sistema distribuido entre 6 lugares entre los que se encuentran varias ciudades de Tokyo, Seúl, Paris y San Francisco. Está también preparado para IPv6: 2001:dc3::35 y actualmente soporta IPv4: 202.12.27.33.n




¿Por qué mantener copias de los servidores raíz?
Si se produjera un ataque ordenado a los 13 servidores raíz, nos quedaríamos sin la copia de los servidores autorizados para resolver los dominios de primer nivel (TLD), es decir, los .es, .fr, .it, .edu, .net, .org
¿Dónde están ubicadas el resto de copias de los servidores raíz?
En la siguiente dirección podremos ver la ubicación mundial de todos los servidores raíz:

El mapa lo podemos ampliar y como se puede comprobar hay una leyenda en cada letra, donde podemos comprobar los siguientes campos:
Operador: que compañía, empresa, organización administra el servidor.
IPv4: IP en versión 4.
IPv6: IP en versión 6.
ASN: identificador del Sistema Autónomo.
¿En Perú y/o México existe algún servidor raíz?
No, solo en Perú y México hay una copia de los Root Servers

-       En Perú, exactamente en el Callao, se encuentra una copia del servidor L.




-       En México existen tres copias de diferentes servidores. El primero se encuentra en la Ciudad de México, es copia del root server D. Y los otros dos se encuentra en Monterrey, uno es copia del servidor raíz F y el otro es copia del servidor raíz L.



Referencias Bibliográficas:
--http://www.securitynull.net/rootserver-los-13-servidores-raiz-del-mundo/ 
--http://www.root-servers.org/


viernes, 13 de marzo de 2015

Spanning Tree Protocol & Broadcast Storm Control

Spanning Tree Protocol (STP)

El Protocolo de Árbol de Extensión (STP), es un protocolo de capa dos del modelo OSI (Capa de Enlace de Datos), basado en un algoritmo diseñado por la programadora Radia Periman, mientras trabajada para DEH. Existen dos versiones, la original DEC STP y la estandariza por el IEEE (IEEE 802.1D), las cuales no son compatibles entre sí. Actualmente es recomendable utilizar la versión estandarizada por la IEEE (Instituto de Ingeniería Eléctrica y Electrónica).

Este protocolo STP, nace bajo la necesidad de poder controlar los bucles entre switches (sea en una maquina o en segmento de red), los cuales se producen al disponer de más una ruta alternativa, es decir que tienen más de un camino para comunicarse entre ellos, por lo que de esta manera los switches reenvían paquetes de broadcast y multicast (difusión y multidifusión de transmisión de datos) en todos los puertos y estos paquetes se mantienen indefinidamente saturando el ancho de banda de todos los enlaces, usando todos los recursos de los dispositivos, hasta hacer que la red colapse por completo.


Todo este problema hoy en día se puede evitar, gracias al estándar del protocolo STP, el cual ayuda a evitar este tipo de situaciones, este protocolo calcula los enlaces redundantes entre equipos y según el costo de la ruta de los enlaces redundantes puede inteligentemente bloquear un puerto del switch. En otras palabras. La función del STP, es mantener la red libre bucles, cortar los bucles de enlaces redundantes creados en redes en los que se involucran switch y otros dispositivos de la capa de enlace de datos.






Broadcast Storm Control (BSC)

Control de Tormenta de Difusión,
Una tormenta de broadcast significa que la red esta siento saturada por la emisión constante de paquetes o el tráfico de multidifusión, trasmitir tormentas puede conducir, con el tiempo, a una perdida completa de la conectividad de la red, así como también a la perdida de paquetes que se van a enviar.
La tormenta de paquetes se da  cuando en un puerto se recibe un gran número de paquetes broadcast, unicast o multicast. Al reenviar dichos paquetes puede causar una reducción del rendimiento de la red e incluso puede llegar a interrumpir el servicio.
Cuando se llega a enviar mensajes de Broadcast, esto puede se problemático para la red, pero los switches tienen una característica,  "Broadcast Storm Control" que puede mitigar el problema.
El Broadcast Storm Control puede deshabilitarse en caso de que los usuarios no manden mensajes a Broadcast, para que los mensajes de difusión que ellos manden (que no sea Broadcast) no se vean afectados por el Broadcast Storm Control, ya que no es común que los usuarios manden mensajes de Broadcast.
La desactivación del Broadcast Storm Control se aplica a todos los puertos del switch.

CONCLUSIONES


El protocolo STP es muy útil para evitar colisiones y que un paquete ande circulando por toda la red, también permite identificar y bloquear los puertos que sean redundantes.

El Broadcast Storm Control es una herramienta muy útil cuando se quiere controlar con los mensajes de difusión en la red y evitar colisiones, perdidas de mensajes o que se queden circulando en la red.



REFERENCIAS:

--> http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/5234-5.html 
--> http://portalcomputacionere.blogspot.mx/2012/08/spanning-tree-protocol-broadcast-storm.html




viernes, 27 de febrero de 2015

COMUNICACIONES UNIFICADAS.

La innovación de las Comunicaciones Empresariales.


Comunicaciones unificadas, quizá para los que están alejados del mundo tecnológico, es un término desconocido, pero actualmente es muy usado por pequeñas, medianas y grandes empresas, incluso se podría decir, que también lo usamos las personas que no estamos involucradas en ningún tipo de negocio, pero este tema va enfocado a las empresas.

En años anteriores, se hablaba mucho sobre este tema, se decía que sería todo un boom, y hoy en día es toda una realidad.













Las comunicaciones unificadas, no son otra cosa que la integración de todos los medios de comunicación en un solo dispositivo e interfaz, lo cual facilita la experiencia al usuario, permite que experimenten una mayor productividad con la convergencia de los canales de comunicaciones y los procesos del negocio usando una combinación de tecnologías, los dispositivos y los servicios incluyendo presencia, status, movilidad, comunicación de colaboración, conferencias de voz y video, y mensajería instantánea.

Conozcamos un poco más sobre este tema. Por el año 2005, los trabajadores andaban con más de 2 o 3 dispositivo para poder tener una buena comunicación con su empresa, lo que realmente resultaba tedioso. Por lo que se decía que para el año 2010, la mayoría de trabajadores adquirirían un teléfono inteligente.

Alejandro Bourg, Director de la Alianza Microsoft-Nortel Enterprise CALA, indica que, en las grandes organizaciones existía una enorme necesidad de eliminar ambientes completamente distintos y disociados. Decía, "Como usuario final quiero hacer telefonía por lP,  tengo  mi  cliente  y programa que corre a través de mi PC;  por otro lado, tengo e-mails y una herramienta de mensajería instantánea para chat en distintos ambientes, lo cual buscamos integrar", expresó.

Para resolverlo, dijo que la mejor fórmula serían los sistemas basados en tecnología lP, los cuales desplazarían a los sistemas analógicos. "Fue una gran oportunidad para los que en aquella entonces ofrecían un servicio que ha permitido al usuario navegar la Web, usar audio, y acceder a videoconferencias a través de una interfaz integrada que permita extender la capacidad de organizar reuniones en vivo desde múltiples locaciones, como bares o aeropuerto. Por lo que podemos decir que, las comunicaciones unificadas surgieron a partir de una gran necesidad, la cual fue tratar de innovar las comunicaciones, para que las empresas puedan producir aún más.



Si una empresa, hoy en día, no cuenta son este sistema de Comunicaciones Unificadas, se podría decir que está por debajo de una que si lo implementa. Ya que estas comunicaciones Unificadas tienen grandes ventajas, en primer lugar esta, los bajos costos de implementación, y la rápida recuperación de la inversión, por otra lado tenemos que, un trabajador no estará alejado de sus clientes o empresas por el simple hecho de no estar en su oficina, si no que se podrán contactar gracias a las CU, así también tenemos, que si la empresa requiere comunicación con otra empresa en el exterior del país, pues ya no será necesario viajar a tal ciudad, si no que por medio de las videoconferencias se mantendrá dicha comunicación, Y una ventaja muy importante, es que las Comunicaciones Unificadas permiten la toma de decisiones en tiempo real, ya que al contar con esto se puede saber mucha información relevante de la empresa, la cual sirve en momentos de toma de decisiones.

Por esta y muchas más ventajas, es que las comunicaciones unificadas se abrieron un paso importante en el mercado empresarial, pues muchas empresas, tanto de pequeñas como grandes, quieren estar siempre a la vanguardia de la tecnología para estar siempre a la altura de sus competidores más fuertes.




REFERENCIAS BIBLIOGRÁFICAS 

-       ->- RAMIREZ, José. (n.d.), Comunicaciones Unificadas. Consultado el: 22 de febrero de 2015.
Disponible en:

-           --> NEC (n.d). Comunicaciones Unificadas. Consultado el 25 de febrero de 2015.
Disponible en:
http://www.necmex.com/nec/descargas/unified-communications.pdf