Share on Google+Share on FacebookTweet about this on Twitter

ATENCION: Los ejemplos que se van a mostrar y “tutoriales” tan solo tienen carácter educativo. En ningún aspecto comparto filosofías de invasión a la intimidad, ataques contra un sistema informático o cuestiones similares. En la medida que sea posible siempre se usarán ejemplos y formas que puedan ser usados por cualquier persona, de forma que pueda verificar los contenidos escritos. No obstante, por motivos más que obvios, materiales como contraseñas, nombres de usuarios o de hosts, serán omitidos o modificado en las capturas de pantallas realizadas (o las lineas escritas). Es decir, los ejemplos serán completamente reales, los datos mostrados a vosotros necesarios para poder pertrechar estos ejemplos no siempre lo serán (Sí lo serán los resultados). Para que esto conste de forma clara, todo material sensible modificado o falso estará resaltado en ROJO. Por motivos de seguridad, todo el material que sea expuesto aquí (exceptuando software propietario o libre, citaciones expresas o código de terceros) tanto texto, imágenes y código son propiedad del autor y está completamente prohibido su reproducción completa o parcial en otros lugares, espero que se comprenda.


Introducción a Routers, Switch, Hubs y Bridges

El último punto necesario a ver antes de poder entrar en el Sniffing, son los dispositivos de red más comunes que podemos tener a nuestro alcance. Muchos de estos han sido más o menos explicados a lo largo de toda esta la literatura, aunque ahora será necesario comprender un poquito mejor su funcionamiento. Aunque parezca lo contrario, es necesario conocer como funcionan estos para poder comprender y poder realizar si es necesario alguna técnica de Sniffing. Nosotros veremos estos dispositivos de red atendiendo a la complejidad de estos, de menor a mayor, aunque al final veremos otros dispositivos de red, para terminar con la “totalidad” de dispositivos de red que podemos encontrar.

  • Hubs
  • Bridges
  • Switches
  • Routers
  • Otros: Modems, APs, Gateways

Como veremos, algunos de ellos están prácticamente en desuso por el empleo masivo de otros (como es en el caso de los Hubs y los Bridges), pero en cambio son los mejores ejemplos para comprender tanto el Sniffing como los otros dispositivos de red.

 

 

Hubs

El nombre castellano es Concentrador, si bien es cierto que incluso en nuestro idioma incluso es más normal referirnos a ellos como Hubs. El término Hubs o concentrador en cambio es usado en otros puntos de la informática, por ejemplo los Hubs USB, esos pequeños aparatitos que proveen a nuestros equipos con más USBs. Pues bien, aquí nos referiremos a un Hub como los Hub Ethernet. Sus funciones principales siempre han sido dos: La interconexión de diferentes equipos entre sí para formar normalmente redes locales y para regenerar las señales.

Los Hubs se vieron en el capítulo anterior en su gran mayoría, o al menos en su funcionamiento básico. Básicamente es un elemento hardware con un número determinado de “puertos” en los cuales se pueden conectar diferentes equipos por medio de Ethernet o FastEthernet. Su funcionamiento es simple, simplemente redirige (o más correctamente repite) las señales que llegan a cada puerto al resto. Es decir, son meros repetidores de señales. Esto hace que nos preguntemos en que nivel del modelo OSI ó TCP/IP funcionan los Hubs, a lo que la respuesta más lógica (y cierta) es por ende el nivel físico, es decir la capa 1.

Como elemento hardware, lo único que hace es conectar las líneas de transmisión de datos de cada puerto con las líneas de recepción de todos los otros. Los Hub por tanto no realizan ninguna modificación de los datos, ni a nivel lógico (IP, datos…) ni a nivel de enlace de datos (MAC, control de errores…). Los Hub simplemente repiten lo que reciben en un puerto a TODOS los otros puertos. Algunos, quizás aun recuerden la necesidad en aquellos tiempos de usar o cables Ethernet directos (pin a pin) o cables Ethernet cruzados (Los pins de transmisión a los de recepción y viceversa). Por aquel entonces, los cables que se conectaban a los hub debían de ser cables directos, pero los cables necesarios para conectar directamente dos PCs o un hub a otro hub, o el router al hub, debían de ser cruzados. ¿Por qué? Por lo que estamos diciendo precisamente. A día de hoy esto no es necesario, primero porque los hub han desaparecido prácticamente y segundo porque los dispositivos modernos detectan que tipo de cable se está usando, y si es necesario cruza las líneas.

Los equipos conectados a un Hub simplemente pueden conocer si un frame es o no para ellos por la dirección MAC a la que están siendo enviados, pero es muy importante anotar que cualquier adaptador ethernet conectado a dicho hub recibirá siempre la totalidad de los frame que son enviados a través del hub. Que el adaptador ethernet procese o no dichos frames es secundario, la cuestión es que dichos frames son colocados a la entrada del adaptador, lo cual será de suma importancia a la hora de la seguridad y del Sniffing.

Otro inconveniente de los Hubs, es que al estar conectados todos los equipos de este modo, se produce un número muy elevado de colisiones. Es decir, es muy común que dos o más equipos estén transmitiendo datos simultáneamente. Dado que un hub lo que realiza es repetir la transmisión al resto de los puertos, se da que el mismo medio se está usando de forma simultanea, lo que origina colisiones de datos, lo que origina en un decremento importante de rendimiento, lo que hace además necesario un mecanismo de control de colisiones por parte del hub, para poder enviar a los adaptadores ethernet conectados a él una señal de colisión de datos.

El diseño propio de un Hub produce que la velocidad máxima de dicho hub quede definida por el adaptador ethernet más lento. Es decir, si tenemos una red compuesta tanto por adaptadores Ethernet (10Mb/s) como adaptadores FastEthernet (100Ms/s), el hub funcionará tan solo a una velocidad de 10Mb/s. La explicación es obvia, al actuar como mero repetidor y tener conectadas de forma interna las líneas de transmisión con las de recepción entre los propios puertos, si un equipo intentase enviar datos a 100Mb/s estos no podrían jamás ser recibidos por los adaptadores Ethernet, con lo que los adaptadores FastEthernet en una red mixta Ethernet/FastEthernet, funcionarían tan solo en modo Ethernet 10Mb/s.

En cambio, pese a todas las deficiencias hay que recordar y tener en cuenta que son un dispositivo tremendamente sencillo en comparación con los Switches, y hay que tener en cuenta también que no es lo mismo hablar de la tecnología de hace 20 años con la de hoy en día. Incluso los propios hubs FastEthernet cuando aparecieron eran treméndamente costosos!! Poco a poco, estos comenzaron a ver como se iba reduciendo su precio y comenzaban a aparecer los primeros Switches. Por aquel entonces los Switches estaban limitados tan solo a entornos que se necesitase una alta seguridad y gran rendimiento, dejando los Hubs como dispositivos de red con un precio bastante asequible y ya presentes en prácticamente la totalidad de las redes, e incluso su incorporación en routers. El tiempo de nuevo y gracias a las tecnologías de integración de hoy en día, los nuevos materiales y otros han hecho posible que los Hubs sean poco más o menos un recuerdo, un hermano pequeño de los actuales Switches que tan solo es posible encontrarlos en redes antiguas. Hoy por hoy, incluso los routers más económicos del mercado incorporan Switches en lugar de hubs.Eso sí, una vez más hacer hincapié en que un hub de a lo mejor 40 puertos podía tener un precio casi inexistente en comparación de un Switch de 8 de puertos.

Otra función que tenían los Hubs eran la de regeneración de las señales. Las redes Ethernet (Estandar, Fast, Giga…) tienen una limitación aproximada de 100 metros de cableado punto a punto para garantizar la estabilidad de las señales. Es decir, cada 100 metros de cableado se debería de regenerar la señal. Dado que los Hubs son meros repetidores, una forma sencilla sin tener que recurrir a dispositivos regeneradores sería aprovechar los mismos Hubs de la red. No obstante, la necesidad de detección de colisiones entre los diferentes hosts hace que tan solo sea posible la interconexión de un máximo de 4 hubs entre sí. Es decir, un hub con 20 puertos y la entrada de uplink conectado a un segundo hub, conectado a un tercero conectado a un cuarto.

No obstante, de cara al Sniffing, el uso de Hubs es una gran ventaja. Los hub reenvían todos los datos que son recibidos al resto de dispositivos, es decir, no debería de ser por tanto complicado configurar un adaptador de red para que en vez de descartar todas las tramas que no coincidan con su dirección MAC, recogerlas TODAS (aunque no se interprete ni se use dicha información), independientemente de quien iba a ser el receptor de dicha información (Router, otro host, una impresora de red…). A este modo de operación se le conoce como “modo promiscuo”. En las redes WIFI ocurre algo similar y lo denominamos “modo monitor”, ya que al igual que un hub envía los datos a todos los demás dispositivos conectados, los datos en una red inalámbrica se transmiten al aire, y es posible configurar los adaptadores WIFI para poder monitorizar todo el ambiente en busca de señales WIFI, con independencia de si iban o no dirigidos a ellos. Esto es lo que hace que tanto hubs como los AP (puntos de acceso) sean inseguros de base, dado que la información que circula por ellos está realmente a disposición de cualquiera que sepa poner la oreja en el lugar adecuado.

 

 

Bridges

Bridge o puente, y es otro elemento de red que a día de hoy ha desaparecido como elemento propio. No obstante los propios Switchs están basados en los bridges, y tampoco es raro ver por ejemplo puentes WIFI. ¿Pero que es un bridge? Básicamente es un elemento de red que une segmentos de red diferentes. Por ejemplo, si tenemos 2 hubs de 4 puertos cada uno, si interconectamos los hub tendríamos una LAN (una red local) de 8 posible equipos, los 8 pertenecientes todos al mismo segmento de red y todo tratados de igual modo. En cambio, podemos tener esos dos hub conectados por medio de un bridge. En este caso, tendríamos dos segmentos de red de 4 equipos cada uno,  y aun así los 4 equipos de un lado podrían comunicarse perfectamente con los otros 4 equipos. La diferencia es que a la vez que el bridge hace de unión entre ellos, también filtra los frames que no pertenecen a dicho segmento. Es decir, podemos decir que en realidad los bridges son una forma eficaz de dividir/segmentar una red a nivel casi de hardware (nivel 2 del modelo OSI), sin ser necesario una división a nivel de red, como haría por ejemplo un router.

Los bridges no son meros repetidores como es el caso de los Hubs. Estos, trabajan en el nivel 2 del modelo OSI, es decir, en el nivel de enlace de datos, luego podemos decir que los bridges trabajan sobre los frames enviados/recibidos. Aun así, comprender el funcionamiento de un bridge es muy fácil. Imaginar el esquema citado anteriormente, dos segmentos de red diferentes conectados por un puente, donde el puente sería un dispositivo con dos puertos de red (en los cuales se conectarían cada uno de los segmentos) y una memoria interna donde se va creando con el tiempo la tabla de direcciones del puente (MAC/Puerto). Lo interesante en el funcionamiento de los bridges es precisamente dicha tabla.

 

La tabla de un bridge se va generando de forma automática con el tiempo. Además, estos (los bridge) no requieren de ninguna configuración inicial, las propias tablas son las que configuran el dispositivo. Si pensamos en un arranque en frío, la tabla de un bridge se encontraría completamente vacía. La idea es simplemente ir examinando las direcciones origen/destino de los frames e ir almacenando en su memoria, en su tabla una asociación MAC-Puerto del Bridge. La mejor forma de ver esto es con un ejemplo. Imaginemos que disponemos de una red igual a la imagen mostrada anteriormente, dos segmentos de red conectados ambos por un puente de dos puertos, el puerto 1 y el puerto 2 (el primer segmento conectado al puerto 1 y el segundo segmento conectado al puerto 2). El primer segmento posee dos equipos y el segundo segmento posee 3 equipos. Dichos equipos podrían estar conectados entre ellos por ejemplo a través de un hub, aunque eso ahora mismo es completamente indiferente. Llamemos por tanto a los equipos del primer segmento A y B, y a los equipos del segundo segmento X, Y y Z. Imaginemos ahora que partimos de un arranque en frío del puente y que la tabla del puente está completamente vacía. Imaginemos que el equipo A quiere enviar un mensaje al equipo Y del segundo segmento. Veamos que es lo que sucedería en dicha red, omitiendo por simplificar direcciones IP o protocolos ARP:

  1. El host A envía un frame al host Y. ¿Como lo hace? crea un frame Ethernet con la dirección MAC Origen (que será la dirección MAC de A) y con la dirección MAC destino (que será la dirección MAC de Y).
  2. Dado que tanto el primer segmento como el segundo tienen sus equipos conectados gracias a un hub, el frame sale de A hacia el hub del primer segmento. Una vez el frame llega al hub del primer segmento, este repite el frame a todos los demás puertos, en este caso al host B y al puente, ambos dispositivos conectados al hub.
  3. El host B recibe un frame gracias al hub (los hub son completamente transparentes para los host, para ellos es como si no existiese un elemento de red en medio) cuyo origen es la MAC de A y destino es la MAC de Y. Dado que no es un frame destinado a él, el host B descarta el frame de A (a menos que el adaptador de red de B estuviese configurado en modo promiscuo).
  4. El puente recibe en el puerto 1 exactamente el mismo frame que ha recibido B, pero el puente no es u mero repetidor. Lo primero que realizará el Puente será inspeccionar la dirección Origen de dicho frame y la buscará en la tabla. Si en su tabla posee dicha entrada no la añadirá, si no la posee la añadirá. Dado que hemos partido de un arranque en frío, tenemos la certeza de que el puente no encontrará la entrada en la tabla, así que añadirá en la tabla lo expuesto a continuación:

    Host A -> Puerto 1

  5. Una vez que se ha inspeccionado la MAC de origen y realizado o no la inclusión de la tabla, se inspeccionará la MAC destino y se buscará si existe alguna correspondencia en la tabla. En este punto la tabla tan solo posee una entrada que especifica el puerto al que está conectado el Host A, pero nada sobre el puerto Y. Dado que no conoce el puerto al que está conectado el host Y, el puente reenviará el frame a TODOS sus puertos, en este caso tna solo al puerto 2 (tan solo es un puente con dos puertos).
  6. El frame saldrá del puente por el puerto 2 y llegará al hub del segundo segmento, el cual, reenviará a todos sus puertos el mismo frame, es decir, enviará el frame tanto a X, a Y y a Z.
  7. Tanto X y como Z descartarán el frame dado que la MAC destino no es la de ellos, en cambio el host Y aceptará y recibirá el frame originario de A
  8. El host Y envía la contestación a A, para ello construye un frame con la dirección origen (la MAC de Y) y la dirección destino (la MAC de A). El frame alcanzará el hub y de aquí al puerto 2 del puente.
  9. El puente inspeccionará la dirección origen del frame, y dado que no la encuentra en la tabla la añadirá a la tabla, de este modo esta quedaría ya de este modo:

    Hot A -> Puerto 1
    Host Y -> Puerto 2

  10. El puente inspeccionaría la dirección MAC destino y la buscaría en su tabla. En este caso el puente SI encuentra en la tabla la dirección del host A, y sabe que debe de reenviar el frame por el puerto 1.
  11. El frame sale por el puerto 1, llega hasta el hub del primer segmento y de ahí al host A y al host B, rechazando el host B el frame porque no es para él.

Todo esto puede parecer un pobo absurdo, porque no parece que se haya logrado gran casa, el camino de ida del frame es exactamente el mismo camino de vuelta del segundo frame. Pero de echo no lo es. Si partimos ahora con la tabla del puente tal y como ha quedado después de la transmisión anterior, veamos que sucede cuando ahora el Host B quiere enviar un dato al Host A:

  1. El host B construye un frame con la dirección origen (la de B) y la dirección destino (la de A). El frame alcanza el hub y este repite el frame a todos sus puertos: El Host A y el puerto 1 del puente.
  2. El host A recibe el frame, y dado que su MAC coincide con la MAC destino del frame, acepta y recibe el frame.
  3. ¿Que pasa con el puente? El puente examinaría la dirección origen del frame y al no encontrarla en su tabla la añadiría, como ha hecho siempre, dejando la tabla de la siguiente forma:

    Hot A -> Puerto 1
    Host Y -> Puerto 2
    Host B -> Puerto 1

    Y después de analizar el origen del frame inspeccionaría la MAC destino. En su tabla encontraría que el host A ya está incluido y que este está conectado al puerto 1, que es por donde el frame le está llegando. ¿Que hace el puente? Simplemente descarta el frame (sería un poco absurdo reenviar de nuevo el frame por el puerto 1, dado que proviene de él)

¿Que se ha logrado hacer por tanto con el puente? Poco a poco la tabla del puente separa la red en lo que se denomina dos dominios de colisión diferentes. Sin el puente, todos los frames enviados de cualquiea de los 5 hosts alcanzarían TODOS los host. Con el puente (y la tabla del puente completa) los frames enviados por hosts dentro del mismo segmento jamás cruzarán el puente. Esto dota a estos dispositivos de red de algunas interesantes cualidades:

  1. Los puentes pueden segmentar/dividir redes sin necesidad de configurar nada, y lo hacen a nivel de enlace de datos (nivel 2). Ojo!! no separa el 100% del tráfico, como veremos más adelante.
  2. Gracias a las tablas de reenvío de estos, los frames dejarán de circular por segmentos de red en los que el host destino no pertenece, lo que se traduce en la ausencia de colisiones entre segmentos de red diferentes. Ningún host de un segmento tendrá una colisión con un host de otro segmento.
  3. Al separar los dominios de colisión, hace que el rendimiento de los diferentes segmentos de red sea mucho mayor y dota además de muchísima más seguridad a cada segmento, ya que se puede tener la certeza de que un frame de un segmento jamás circulará por el otro segmento (excepto el inicial cuando la tabla del puente no posee aun la entrada y por supuesto los frames broadcast)
  4. Son dispositivos muy simples de implementar y extremadamente baratos

Evidentemente no es oro todo lo que reluce, y posee algunas desventajas, como por ejemplo que no separa dominios de broadcast, y posíblemente y más importante aun sea que para los puentes es muy complicado la interconexión de dos segmentos que usen tecnologías diferentes.

A día de hoy, al igual que los Hub, los puentes como tales han desaparecido casi en su totalidad. No obstante, su principio de funcionamiento es el que inspira el funcionamiento básico del siguiente dispositivo de red que vamos a ver: Los Switches. ¿De cara al sniffing? Los puentes como los hub son dispositivos completamente transparentes para los equipos, no obstante los puentes no reenviarán frames de un segmento a otro, lo que producirá que un sniffer no podrá (en principi0) capturar ningún frame del otro segmento de red, aun cuando el adaptador de red del equipo esté en modo promiscuo.



Switches

La evolución de la tecnología, procesadores, microcontroladores, integración… han echo posible que los Switches estén presente casi en la totalidad de todas las redes del mundo. Al igual que los hubs o los bridges, nosotros tan solo veremos los Switches Ethernet. El nombre español es Conmutador, lo cual tiene bastante sentido ya que podríamos ver un Switch como una máquina que interconecta en el momento adecuado los dos hosts que quieren hablar entre ellos, con completo aislamiento del resto.

En realidad, el funcionamiento del Switch es simple si se ha comprendido el funcionamiento de un hub y de un bridge. El más simple de todos los Switchs podríamos verlo/simplificarlo como un bridge multipuerto. Fusionar por un lado la idea simplista de un hub con las ventajas que brindan los puentes. Un puente segmenta una red  en dominios de colisión, pero es posible aplicar el mismo concepto a cada host en particular, de forma que cada host tendría por así decirlo un dominio de colisión propio. Dicho de otro modo, cada host queda de este modo completamente aislado del resto. Imaginar un puente de 4 puertos que une 4 segmentos de red diferentes, segmentos de red que poseen tan solo un host. Recordemos que el funcionamiento de un hub era meramente el de repetir los frames en cada uno de los puertos, pero en los Switch no se realizará dicha repetición, cada frame será entregado UNICAMENTE al host concreto. ¿Como? Gracias a la tabla de reenvío, exactamente del mismo modo que el puente conoce el puerto al que pertenece cada host. Además de esta peculiaridad, en un Switch es posible trabajar en FullDuplex y simultáneamente, mientras que el host A mantienen una comunicación con el host B, el host C y el host D pueden estar teniendo otra comunicación entre ellos a la máxima velocidad. Por supuesto no podemos limitarnos a pensar que en un puerto de un Switch tan solo es posible conectar un host, es posible conectar desde otro Switch, un hub, un router…

Si la función que realiza es realmente la de un puente multipuerto sería correcto decir que los Switches también son dispositivos de red de nivel 2, que trabajan enviando el frame recibido por un puerto al puerto destino gracias a una tabla interna. Y es cierto en parte, dado que los Switchs han evolucionado mucho más allá de un mero puente multipuerto. Aun así, el Switch base (por así decirlo) es un dispositivo de red de nivel 2. Por otro lado, como hemos dichos los Switches han evolucionado más allá del nivel 2, y aquí comienza realmente la complejidad de estos, dado que las funcionalidades y niveles en los que operan un Switch pueden ser muy diferentes, dependiendo de los fabricantes o incluso del márketing. ¿No está entonces estandarizado? Bueno, dependiendo de la literatura a la que se acuda podemos leer una cosa u otra, y realmente no siempre es errónea, a veces es simplemente puntos de vistas diferentes. Por regla general no obstante se conoce como Switchs inteligentes a aquellos Switchs que operan al menos también a nivel 3 (nivel de red), aunque es más normal el uso del término “multilayer Switch”, es decir, Switch (o conmutador) multi-capa (que opera en múltiples niveles diferentes). El problema de usar el término “Layer-3 Switch” (Switch de nivel 3) o incluso “Multilayer Switch”, es que la definición puede hacer referencia directamente a un Router, dado que en sentido estricto, podemos decir que un Routers es también un Switch multi-capa.

Históricamente, los dispositivos de red de nivel 1 fueron los Hub, los dispositivos de red de nivel 2 los bridges y Switches y los Routers dispositivos de red de nivel 3 y superiores. Desde mi punto de vista por tanto, no llamaría (por confusión más que nada) a un router un “Multilayer Switch”, ya que para mi estos últimos no poseen la finalidad ni las funciones que identifican quizás más inequívocamente a un Router. Para mi, un Switch multi-capa o un Switch de nivel 3 es un Switch avanzado que posee o puede poseer algunas funciones de nivel 3 que pueden ser interesantes a la hora de desempeñar su labor principal, que no es la del rutado de datos, sino la de la interconexión de hosts de una misma red. Aunque repito una vez más que esto es simplemente una apreciación personal. Por ejemplo, CISCO (la mayor compañía del mundo dedicada a redes) tiene un interesante artículo que nos habla poco más o menos de todo esto. Para ellos un Switch de nivel 3 no es más que un router que realiza las funciones de rutado por hardware y no por software:

Artículo de CISCO sobre Switchs de nivel 2 y nivel 3

 

Una función interesante de los Switchs (no todos) es solucionar el “problema” del broadcast y poder crear diferentes redes dentro del mismo Switch. Con un router podemos crear de forma fácil subredes, pero esta cualidad puede realizarse también en nivel 2 gracias a las VLAN: Virtual Local Area Network. Consiste simplemente en poder configurar el Switch para tener diferentes “agrupaciones” de puertos. Por ejemplo, asignar el puerto 1 y el puerto 2 como una VLAN, el puerto 3 y el puerto 4 como otra VLAN y el puerto 1 y el puerto 4 como una tercera VLAN. Efectivamente, no hay que pensar en las VLAN como algo estricto. Cada una de las VLAN serán tratadas como redes independientes de las otras, con un dominio broadcast diferente para cada una de ellas. Esto es una técnica usada de forma muy habitual. Actualmente esto se logra sobre todo con el estandar 802.1Q, el marcado de frames, en el que el Switch añade a los frame ethernet un campo de marcado que especifica la VLAN a la que será enviado el frame. Imginar por ejemplo que disponemos de un Switch de 5 puertos (Puert 1, 2 3 y 4 para hosts  y el puerto 5 para la conexión al router). Podríamos por ejemplo querer que los puertos 1 y 2 formasen junto al puerto 5 una VLAN, con lo que los puertos 1 y 2 tendrían acceso a internet y podrían verse entre ellos. Pero por otro lado podríamos crear una VLAN con los puertos 3 y 4, con lo que estos dos equipos tan solo podrían verse uno al otro y sin conexión a internet.

Pero hablemos un poco más de los Switchs. Una cuestión que no contempla los Switchs es por ejemplo la gestión de los mensajes multicast, ya que estos son enviados a todos los host conectados a este, con independencia de si los hosts conectados a él pertenecen al mismo grupo multicast o no. ¿Por qué sucede esto? Bueno, porque los grupos y las direcciones de multicast se realizan a nivel de red. He aquí un ejemplo de la necesidad de los Switches de nivel 3. Una solución a este “problema” es por ejemplo una técnica conocida como IGMP snooping, en la que el Switch monitoriza también los mensajes IP multicast, almacenando en una caché/tabla del propio Switchs cuando un host se une a un grupo multicast o lo abandona. Conociendo los hosts que pertenecen a cada grupo multicast, los mensajes multicast que traspasen por tanto el Switch ya no serían enviados a todos los hosts, sino a aquellos que realmente pertenecen al grupo multicast al cual están dirigidos. Esto que parece un pequeño añadido produce que en redes que hacen un uso intenso de tráfico multicast (como por ejemplo videoconferencias o transmisiones de audio/video a grupos multicast concretos) obtengan un rendimiento muy superior, ya que los hosts que no pertenecen al grupo multicast no recibirán tráfico alguno. En una red con 4 hosts esto parece un poco absurdo, pero pensar en una red con 200 hosts conectados, y que por ejemplo tienen dos grupos multicast de 100 hosts cada uno. Con este sistema 100 hosts no tendrían tráfico alguno, sin IGMP snooping toda la red estaría recibiendo los datos. Dado que el sistema de IGMP Snooping requiere examinar las IPs, el Switch estaría trabajando por tanto en nivel 3, pero para mi, un Switch con IGMP Snooping no es un router. Aquí se ve por tanto la problemática. Todos los Routers son Layer-3 Switchs, pero no todos los Layer-3 Switchs son Routers.

Otra función que es relativamente fácil encontrar en algunos Switchs de nivel 3 son los sistemas QoS (Calidad de Servicio), para evitar la saturación de la red. Es cierto que QoS suele ser implementado a nivel de Router, pero sin mucho trabajo puede ser bastante útil que los Switchs puedan manipular los bits de la cabecera IP para QoS.

 

Para encontrar Switchs más allá del nivel 3,  deberíamos de acudir a redes más complejas o empresas que pueden beneficiarse de estos dispositivos. Por ejemplo, se pueden encontrar Switchs que proporcionan ellos mismos sistemas NAT sobre todo para balancear la carga de los servidores. Imaginar que disponemos de 4 servidores Web que tienen la información sincronizada, y un Switch que envía a los usuarios a un servidor o a otro en función de la saturación/carga de cada uno de los 4 servidores, sin necesidad de interponer un router que se encargue de dicha tarea, que evidentemente podría realizarla. Quizás, aquí comprendemos más que es lo que CISCO quiere decir cuando habla de Routers = Swichs de nivel 3 por software. A fin de cuenta un router a día de hoy suele tener todo un OS instalado en él, y es el OS que tiene instalado quien gestiona cada uno de los servicios que este posee…. es decir, un procesador que ejecuta programas. Un Switch en cambio, posiblemente el balanceo de la carga de los servidores lo haría íntegramente por hardware, una electrónica que es capaz de conocer la carga que circula por cada uno de los servidores y según esta información redirigir a un usuario a uno u a otro. Mientras que el propósito es el mismo, el medio es muy diferente.

En realidad, no hay un límite en cuanto a funcionalidades de un Switch, basta con implementarle por hardware alguna función de cualquier nivel del modelo OSI que pueda ser interesante para un escenario concreto. Si bien es cierto que los Routers suelen encargarse de la mayoría de estas cuestiones, también lo es que para tareas concretas el rendimiento y facilidad que otorgará un switch siempre será mucho mayor.

 

¿Que podemos decir de los Switches de cara al Sniffin? Lo mismo que podíamos decir sobre los bridges. En principio, un host conectado a un Swicth tan solo podría capturar tráfico de sí mismo, dado que en los Switches cada frame se envía tan solo al puerto concreto. Es decir, los Switches son infinitamente más seguros a priori que los Hub. A día de hoy los Hub han desaparecido y sustituidos casi en su totalidad por los Switches modernos, entre los cuales podemos encontrar desde dispositivos asequibles para casi cualquier persona del mundo y que no requieren ningún tipo de configuración, a dispositivos profesionales de los cuales mejor no preguntar siquiera el precio:

Para hacernos una idea solo del tamaño de dichos dispositivos, si miramos el Switch de la derecha de la imagen, cada uno del los agujeros que se pueden apreciar en la mitad superior son conexiones RJ45, es decir, un puerto Ethernet, en este caso son 10GigaEthernet. Es evidente que este tipo de Switchs es un poco el extremo más extremo que podemos encontrar, hablamos de Switchs que realizan funciones de rutado, QoS, VLAN, VPN, Firewall… Tampoco hay que dejarse engañar, ojo!! la mayoría de los Switchs y Rotuers de este tipo son modulares, es decir, se pueden añadir a lo mejor 200 puertos para Ethernet sobre fibra óptica de golpe con un módulo extra para ello.

 

 

Routers

Son el alma máter de Internet. Originalmente su función era simple: Un dispositivo capaz de poder conectar dos o más redes independientes entre ellas, de modo que se puedan intercambiar entre ellas paquetes de datos, generalmente de manera selectiva. Es decir, si tenemos la red A y la red B, un dispositivo que pueda permitir a la red A comunicarse con la red B. Esto puede parecer que es exactamente lo que hacía un Switch, pero nada más lejos. Es cierto que un Switch común puede interconectar dos redes diferentes a nivel físico, pero el papel principal de un router es completamente diferente.

Un router posee dos aspectos fundamentales de operación: El plano de control y el plano de reenvío.

Si un router puede conectar dos o más redes independientes entre ellas, lo primero que debe de conocer es, por así decirlo, el mapa de red que existe a su alrededor, e incluso que se extiende más allá de esta. ¿Y que interpretamos como mapa de red? Pues ni más ni menos que la arquitectura de esta, las interfaces de acceso de dichas redes, los protocolos que van a usarse en cada una de ellas, las direcciones de estas… En definitiva crear, modificar, adaptar, mantener… lo que se conoce como la tabla de enrutamiento. Esta función será la que realice el plano de control.

Pero aunque se dispongan de un plano de control perfecto, es necesario poder cumplir con su funcionalidad principal: Enviar los, generalmente, paquetes de una red a otra, siguiendo unas determinadas reglas o filtros. Podríamos ver que el plano de control es algo así como la oficina de correos y el plano de reenvío los carteros. Una vez más esto puede asemejarse a la función que desempeñaría un Switch, solo que este realiza dichas funciones en nivel 2 dele modelo OSI, mientras que un router realizaría esta función a nivel 3 (nivel de red), manejando IPs (generalmente).

Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.153.1 * 255.255.255.255 UH 0 0 0 ppp0
192.168.153.1 * 255.255.255.255 UH 0 0 0 ppp0
192.168.2.0 * 255.255.255.0 U 0 0 0 br0
192.168.1.0 * 255.255.255.0 U 0 0 0 vlan2
169.254.0.0 * 255.255.0.0 U 0 0 0 br0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default 192.168.153.1 0.0.0.0 UG 0 0 0 ppp0

Evidentemente esta es una tabla de rutado muy sencilla, nada comparable a lo que podría ser una tabla de rutado de un router conectado a una gran red, pero el funcionamiento y comprensión es sencillo. La tabla de rutado no se preocupa de saber el origen de nada, simplemente el destino de todo.

Ejemplo 1:

Si cualquier paquete llegase a este router, por ejemplo con intención de alcanzar la IP 192.168.2.100, el router miraría primero la tabla de rutado para saber la “ubicación” de dicha red, en este caso la red 192.168.2.0 para la máscara de subred 255.255.255.0. Según se muestra en la tabla de rutado, la interfaz asociada a dicha red sería la interfaz “br0”, es decir que dicha interfaz sería por la que saldría el paquete para poder alcanzar el host destino. Esto podría darse por ejemplo en un paquete entrante desde Internet a la red interna 192.168.2.0

Ejemplo 2:

Imaginemos que ahora es un equipo perteneciente a la red 192.168.1.0 el que desea acceder a google.es (66.249.92.104). El router no posee en este caso ninguna ruta definida para dicho host, con lo que usará la ruta por defecto (default). La ruta por defecto se hará cargo de TODOS los destinos que no hayan coincidido con alguna ruta anterior. De echo, el destino “default” en realidad es la ip destino 0.0.0.0, que como ya se dijo en su momento es lo mismo que decir “Todas las IPs”. A diferencia del resto de rutas, esta define además una puerta de enlace a la que se deben de reenviar los paquetes, que no es el propio router. Siguiendo con el ejemplo anterior, cuando el router recibiese la petición para enviar el paquete a la dirección 66.249.92.104, este reenviaría dicho paquete a la puerta de enlace 192.168.153.1, y lo haría por medio de la interfaz ppp0e.

 

Por supuesto, como veremos más adelante las funcionalidades de un router han ido incrementándose con los años de tal forma que hoy por hoy parece que aquella función principal para la que se concibieron es la más desconocida para la mayoría, mientras que aquellas funcionalidades que podríamos llamar “secundarias” son mucho más conocidas. Pero antes de verlas, es importante tener una visión de los routers mucho más amplia de aquellos routers residenciales que tenemos en nuestras casas. De echo, si fuésemos completamente estrictos hablando, es posible que el término “router” tuviésemos que eliminarlo de los “routers caseros” que posee la gran mayoría en sus hogares, y llamarse estos simplemente “Puertas de enlace”, ya que la gran mayoría de estos aunque conectan nuestra propia red a la red del ISP, no intercambian ningún tipo de información de enrutado, de ahí el nombre de “Puerta de Enlace” o “Router residencial”. Pero dejando esta matización a un lado, continuaremos llamando a nuestras puertas de enlace routers, y es por ello por lo que los veremos definidos aquí, aunque más adelante.

  • Edge/Border Routers

    Literalmente sería algo así como Routers de bordes, aunque personalmente prefiero usar el término de “Routers Exteriores”, interpretando exteriores como los routers que se encuentran en el punto más extremo  de la red del ISP al que pertenecen, las fronteras de ella. Si recordamos más o menos lo que es Internet, Internet no es más que un cúmulo enorme de dispositivos interconectados entre ellos, redes dentro de redes dentro de redes…. ¿A fin de cuenta no tenemos la mayoría de nosotros una red LAN constituida en casa? Pero del mismo modo esta red LAN doméstica se encuentra conectada a la Red o subred de nuestro ISP, y esta a su vez puede pertenecer a la red de otro ISP o directamente conectada a las demás redes. Pues bien, los Routers exteriores son los routers que conectan directamente la red del ISP (como telefónica) con otros ISP, o incluso con grandes organizaciones y/o empresas.

    La necesidad de los Routers exteriores no solo puede encontrarse en los ISP, es psoible como hemos dicho encontrarlos en empresas con unas infraestructuras de red grandes, u organizaciones de cualquier índole: Universidades, Multinacionales, Gobiernos… Y su importancia es evidente, son estos Routers los que enviarán/recibirán nuestros paquetes de datos cuando el destino se encuentre fuera de, normalmente, nuestro ISP.

    ¿Como? Bueno, la función principal de los routers ya se han tratado. Gracias a protocolos específicos para ello como BGP, estos routers intercambian entre ellos toda la información de enrutado necesaria para garantizar que todos ellos conocen perfectamente el destino de cada nueva red. Dicho de otro modo, si queremos acceder a la página de google, no nos gustaría que nuestro paquete de datos en vez de llegar en último término a las redes de google se enviasen a las redes de yahoo (por ejemplo). Si los servidores de DNS (como explicamos) eran esas bases de datos enormes que asociaban a un determinado nombre de dominio una IP (simplificando mucho), los Routers exteriores serían los encargados de asociar cada red a un destino físico determinado, en este caso sería lo que se denomina un AS (Sistema autónomo). Definir un AS puede ser un poco complicado. La definición oficial sería algo como: “Un AS es un grupo interconectado de uno o varios prefijos IP que son usados por una o más ISP, que tiene un política de enrutado simple y claramente definida”. Dicho de otro modo, un dispositivo (un router externo posiblemente) perteneciente al propio ISP de la red en la que se encuentra que posee los prefijos IP de dicha red. Cada ISP por tanto poseerá un AS principal registrado y conocido por todos, que será al que estará conectado los routers exteriores.

  • Core Routers

    Si a los Edge Routers los llamamos Routers exteriores, los Core Routers podríamos definirlos como Routers interiores. Serían básicamente el resto de los Routers. Dentro de la red de un ISP, serían la infraestructura principal sobre la que se asienta toda ella, un compendio de decenas, centenas, millares… de routers conectados entre sí, que permiten que los paquetes de datos circulen perfectamente por dicha red, desde un extremo hasta otro si hace falta, y por supuesto en caso de que sea necesario enviar los paquetes de datos a los routers exteriores si estos tienen que salir de la red propia.


Para poder realizar las tareas que se han descrito, los routers actuales son prácticamente computadores en sí mismos, normalmente con un OS propio que administra los recursos de este. Esto cada vez tiene mayor importancia, así como el hardware usado, si tenemos en cuenta que las funciones que se van implementando en los routers son cada vez mayores. Y es que a pesar de su principal finalidad, ha ido siendo cada vez más frecuente el ir añadiendo funcionalidades propias de otros dispositivos dedicados, dotando a los routers de una mayor versatilidad, a la vez que se va prescindiendo de otros equipos dedicados, lo cual suele ser costoso. Esto tiene aun más importancia cuando abandonamos las grandes empresas y nos centramos en PYMES y particulares, donde no es viable disponer de equipo específico para funciones especializadas. Vamos a ver cuales de estas funciones son las más usuales que podemos encontrar en la actualidad:

  • Servidor DHCP

    DHCP es un protocolo para la auto-configuración de dispositivos. Para que cualquier dispositivo de red IP pueda acceder a esta necesita estar configurado para ello, cuanto menos necesita tener una IP asignada y una máscara de subred, aunque lo habitual es una configuración completa: puerta de enlace, servidores dns, ip asignada y el tiempo de vida de la asignación de dicha IP. DHCP como la mayoría de protocolos que nacieron originalmente, no se basaban en la seguridad, sino en la versatilidad y facilidad de uso. Lo cierto es que es un sistema simple y eficaz para la configuración automática de dispositivos de red que no necesitan de una configuración específica, lo cual es el caso del 90% de los hosts de cualquier red.  aparte de los ajustes de configuración básicos, es corriente que tanto clientes y servidores DHCP puedan ser configurados para solicitar/asignar parámetros de configuración extra, incluyendo ajustes específicos para sistemas operativos concretos. La lista completa de los parámetros puede encontrarse en la documentación oficial: Parámetros DHCP

    El funcionamiento es simple. El dispositivo se conecta a la red, y dado que no dispone de ninguna dirección IP o parámetros de configuración, lanza un mensaje broadcast tanto a nivel de MAC como de IP, solicitando auto-configuración por medio de DHCP (presuponiendo que el cliente dispone de un cliente DHCP que permite realizar dicha tarea). Dicha solicitud puede incluir no solo el deseo simple de obtener sus parámetros básicos, sino que puede solicitar también unos ajustes concretos, como una dirección IP concreta, el nombre NetBios que tendrá, el tipo de nodo… cualquier ajuste que el sistema operativo del dispositivo (o el cliente DHCP del dispositivo) crea pertinente que necesita o que podría ser útil. Si existe un servidor DHCP en dicha red, recogerá la petición DHCP del cliente con los ajustes solicitados, y será este quien procese la información y conteste al cliente de forma específica, con los ajustes que el cliente solicitó u otros completamente diferentes, o incluso ignorando la petición de dicho cliente. Es decir, siempre será el servidor DHCP quien una vez tomada la petición de un cliente configurará (o no) al cliente como él (el servidor) desee. Vamos a ver un ejemplo de una petición DHCP (ambos usando IPv4, recordar que al igual que existe el protocolo DHCPv4, existe también el protocolo DHCPv6 para redes IPv6):

    Como se puede apreciar, además de solicitar una IP y nombre de host concretos, el host (con OS Windows 7) solicita además algunos parámetros de configuración, como por ejemplo el nombre de dominio, ajustes netbios… lo cual no quiere decir de nuevo que el servidor conteste a todo ello, el cliente tendrá que conformarse por regla general con los parámetros de configuración que le asigne el servidor DHCP, es más, el servidor DHCP puede modificar algunas funciones del propio cliente por medio de DHCP, tales como por ejemplo deshabilitar para dicho adaptador Netbios dentro de su propio OS (Windows 7 en este caso)

    Estos servidores DHCP podrían constituirse perfectamente con la mayoría de versiones servidores de los OS que conocemos a día de hoy, aunque era muy frecuente tener un equipo con Linux que se encargase de ciertas funciones similares. A día de hoy, esto es una función típica que se ha incluido en ¿todos? los routers actuales.


  • Clientes de conexión

    En realidad es complicado buscar un nombre adecuado a este tipo de funciones. La mayoría de los routers podríamos verlos como un dispositivo con al menos 2 entradas/salidas (2 puertos Ethernet por ejemplo). En cambio, estamos acostumbrados a pensar automáticamente en nuestras puertas de enlace residenciales (routers residenciales), los cuales los vemos más bien como un dispositivo con una entrada y una o más salidas (Un puerto de “entrada” para WAN y otros de “salida” para LAN, no estoy hablando de Modems). En realidad los puertos de un router son evidentemente tanto de entrada de salida, pero es algo común el verlos como puertos independientes. En este tipo de routers, el puerto WAN suele tener una función muy concreta: La conexión del router a Internet. Si la conexión se realiza por medio de un modem, sería el modem el que se encontraría conectado a dicho puerto, si fuese un modem/router ADSL lo normal es encontrar un puerto para la línea de teléfono, sin que sea visible la existencia de un puerto WAN, aunque internamente exista. Con todo esto en la cabeza… ¿a que nos referimos entonces con que un router puede funcionar como diferentes clientes de conexion?

    Imaginar por ejemplo que nuestro router residencial está conectado a un modem ADSL por el puerto WAN. DSL es una tecnología que por regla general usa ATM como transportador, y se basa en protocolos como PPPoE y PPPoA para conectarnos con nuestro ISP. Para que esto sea posible, el router o el modem tienen que actuar como clientes PPPoE/PPPoA para poder realizar dicha conexión. En modems DSL antiguos, era bastante habitual que el cliente PPPoE fuese un programa a descargar en su OS, después fue una función incorporada al router del modem/router residencial.

    Otro escenario típico es por ejemplo la necesidad de poder conectar entre sí dos o más redes a través de Internet, pudiendo de este modo que ambas redes puedan interactuar entre ellas como si de una sola red se tratase. Esto suele realizarse por protocolos de túneles o VPN, como PPTP, L2TP o IPSec, Para que este escenario sea posible, lo ideal es contar con un router que actúe de servidor del túnel y tantos otros que actúen como clientes del túnel. Pero incluso el mismo acceso a internet podría venir dado igualmente por dicho túnel.

    Son muchos los sistemas de conexión que puede conectarse un router, además de los nombrados tendríamos por supuesto el actuar como cliente DHCP, en el que el router obtendría sus parámetros de configuración por medio de otro servidor DHCP, o como cliente WIFI, cliente 3G… las posibilidades son muchas.


  • Network Address Translation (NAT)

    Esta es sin duda una de esas funcionalidades estrella para todos los routers residenciales, y en cambio me atrevería a decir que completamente inservible fuera del ámbito de los hogares y las PYMES. Uno de los principales problemas que tenemos a día de hoy es como ya dijimos el agotamiento del espacio de direcciones IPv4. La mayoría de los hogar (y evidentemente cualquier empresa, organización…) dispone de al menos más de un dispositivo que desean conectar a Internet. Al margen de que dispongamos de más líneas contratadas, IPs dinámicas o estáticas… si no existiese NAT se requeriría una IPv4 unicast (y por IPv4 unicast me refiero a una IPv4 direccionable en Internet) por cada dispositivo que deseásemos conectar a la red!! es decir, si tenemos 4 portátiles necesitaríamos 4 IPv4 unicast. Esto es impensable. Es NAT quien hace posible que todos y cada uno de los host de una LAN pueda acceder simultáneamente a Internet, compartiendo TODOS ellos la misma IPv4 unicast asignada por su ISP.

    Es de aquí de donde aparecen los términos de IP privada e IP pública. Al contrario de lo que la mayoría de las personas cree, la IP privada es la IP menos importante de cara al exterior, siendo realmente la IP pública la que obtiene todo el protagonismo. La IP privada de un host es la IP que le ha sido asignada en su LAN, con la que puede comunicarse con todos y cada uno de los dispositivos de esta. La IP pública de dicho host es la IP con la que se comunica al exterior para poder alcanzar cualquier destino de Internet. La IP privada es por tanto asignada por el mismo Host o por algún servidor DHCP de la red al que pertenece, mientras que la IP pública será asignada por el ISP, y será usada por todos los Host de la red que estén detrás de un dispositivo NAT. De este modo se comienza a ver la verdadera utilidad de NAT, mientras que todos los hosts dentro de la misma red pueden comunicarse con una IPv4 que pertenece a un rango IP para uso privado, todos usan la misma IP para Internet, siendo el ahorro de direcciones IPv4 unicast evidente.

    ¿Como es esto posible? La función de NAT es simple, NAT es ni más ni menos que un traductor (quizás sería más correcto usar conversor) de direcciones IP. Según hacia que lado se realice dicha conversión o traducción, podremos hablar de SNAT o de DNAT. Si NAT modifica una IP destino hablaríamos entonces de DNAT, si la IP modificada es la IP de origen del paquete hablaríamos de SNAT. Independientemente de esto, la idea de NAT es que cuando un host envía un paquete IP hacia Internet, su IP privada es convertida por SNAT a la IP pública de este antes de lanzar dicho paquete a Internet. El destino de dicho paquete responderá a la IP pública que envió dicho paquete, este será recogido de nuevo por el router, y por medio de DNAT convertirá la IP destino de dicho paquete (que actualmente es la IP pública de los hosts de la red) a la IP privada de quien envió dicho paquete, para acabar enviando el paquete de vuelta al host que comenzó la comunicación. Son dos las cuestión realmente interesante con NAT: Como hace el router para saber a quien enviar de nuevo el paquete destino y la necesidad/beneficio de lo que llamamos redirección de puertos (Port Forwarding). Un dispositivo NAT puro, al igual que puede realizar conversiones de direcciones IP debería de ser capaz de realizar PAT (Port Address Translation), es decir, ser capaz de modificar también los puertos TCP/UDP de origen/destino. Esto es a tener en cuenta, dado que muchos routers disponen tan solo de un soporte NAT parcial, incapaz de realizar PAT. Menos usado tal vez sean los esquemas de NAT dinámicos, en los que en vez de tener una sola IP externa (aka pública) se disponen de varias, y el dispositivo NAT puede realizar SNAT a una u otra IP.

    El cómo se realiza el proceso SNAT es simple. Dado que el router conoce tanto la IP pública como la IP privada de quien realiza el envío del paquete IP, SNAT “sólo” tiene que modificar al vuelo la IP privada por la IP pública. En realidad esto no es del todo correcto dado que al modificar la IP del paquete sería necesario modificar modificar también otros campos del paquete IP (CRC o incluso las cabeceras TCP/UDP), y esto no es algo tan simple en protocolos dependiente de IP como ICMP. Pero de un modo simplista podríamos ver que SNAT simplemente cambia una IP por otra. El problema es  DNAT. Cuando el paquete externo llega al router es porque algún servidor (por ejemplo) envió a nuestra IP pública dicho paquete. Dicho servidor no tiene siquiera que saber ningún tipo de información relativa a algún host de nuestra red, en todo caso podrá saber alguna información del único dispositivo de nuestra red expuesto a Internet, nuestro router. La pregunta del millón es por tanto ¿cómo se reenvía desde el router dicho paquete IP al interior de nuestra LAN? ¿Cómo sabe el router siquiera si dicho paquete fue o no solicitado? Bueno, todo ello depende de que tipo de NAT tenga implementando nuestro dispositivo, o el tipo de NAT que necesitemos.

    • NAT de Cono completo (Full-Cone NAT):

      Es la implementación NAT menos segura. NAT mapeará la dirección IP del host junto con su puerto (llamados internos) a una dirección y puerto diferentes (llamados externos, el puerto externo puede ser el mismo al puerto interno) . Una vez se ha realizado dicho mapeo, CUALQUIER host externo PUEDE comunicarse con el host interno enviando los paquetes a UNA dirección:puerto externo que haya sido mapeado.


    • NAT de cono restringido (Restricted Cone NAT)

      Una vez una dirección:puerto interno se ha mapeado a una dirección:puerto externo, SOLO PODRÁ comunicarse con el host interno un host externo sí el host interno en cuestión se ha conectado previamente al host que desea comunicarse con el host interno. En tal caso, dicho host externo PODRÁ comunicarse con el host interno usando CUALQUIER puerto propio, enviando los paquetes a la IP y puertos externos que han sido mapeados.


    • NAT de cono restringido de puertos (Port-Restricted Cone NAT)

      El modo de funcionamiento es exactamente igual a NAT de cono restringido, salvo que se le impone la restricción al host externo de usar el MISMO puerto propio al que previamente se conectó el host interno. En tal caso podrá usar UNA dirección:puerto externa del host interno para comunicarse con él


    • NAT Simétrico (Symmetric NAT)

      Es la implementación NAT más segura. Básicamente a Nat de cono restringido de puertos se le añade una nueva restricción, obligando que el host externo SOLO pueda comunicarse con el host interno a través del puerto externo concreto que realizó la conexión previa, además de tener que hacerlo por el puerto propio al que estaba destinada la comunicación previa.

    La mejor forma de ilustrar esto es sin duda alguno ejemplificándolo. Vamos a ver unos pequeños ejemplos de esto. Para todos ellos vamos a suponer que disponemos 1 host interno (Host A) y 2 host externos (Host Y y Z):


    Full Cone

    Host A: 192.168.0.100 : 50000 -> SNAT -> 80.25.213.2 : 51000 | El puerto Interno del host A es 50000, mapeado al puerto externo 51000.
    Host Y : 212.251.23.5 : XXXXX
    Host Z: 120.21.0.25 :  WWWWW

    Siendo XXXXX y WWWWW un puerto cualquiera, tanto el Host Y como el Host Z podran enviar en cualquier momento un paquete al puerto 50000 del Host A enviándolo a la IP pública de este 80.25.213.2 y a su puerto exterior 51000

    La principal ventaja de este sistema es que no se requiere de ninguna conexión previa por parte del Host A para que este pueda recibir una conexión entrante a dicho puerto. Esto es algo abstante habitual, por eejmplo es el comportamiento que deseamos cuando usamos programas P2P, Messenger, Juegos Online, Accesos remotos… aplicaciones que pueden recibir en cualquier momento datos de algún host al cual previamente no hemos conectado. En cierto modo, cuando en un Router hacemos uso de ese típico “abrir puerto”, realmente lo que se hace es hacer que para dicho puerto NAT se comporte como Full Cone. La desventaja de este sistema es evidente, el Host A en este caso siempre tendrá expuesto su puerto 50000 al exterior por medio del puerto mapeado externo 51000, lo cual es un problema muy grande de seguridad.

    Restricted Cone

    Host A: 192.168.0.100 : 50000 -> SNAT -> 80.25.213.2 : 51000 | El puerto Interno del host A es 50000, mapeado al puerto externo 51000.
    Host Y : 212.251.23.5 : XXXXX
    Host Z: 120.21.0.25 : WWWWW

    El Host A envía un paquete IP al puerto XXXXX del Host Y a través de su puerto interno 50000.

    Siendo XXXXX y WWWWWW un puerto cualquiera, en este caso solo el Host Y podrá enviar un paquete al puerto 50000 del Host A enviándolo a la IP pública de este 80.25.213.2 y a su puerto exterior 51000. El Host Z en contrapartida no podrá enviar ningún paquete IP al Host A por medio de su puerto externo, ya que la tabla NAT del router del Host A no posee tiene registrada ninguna conexión previa al host Z. Para que el Host Z puda comunicarse con el Host A del mismo modo que lo hace el Host Y, el Host A deberá de iniciar una conexión al Host Z.

    La ventaja de este sistema es una de las principales barreras de seguridad de un router, es en sí mismo un poderoso Firewall. Solo con esta función, ningún Host externo podrá comunicarse con ningún Host de nuestra red salvo que se haya iniciado previamente la comunicación por parte de nuestra red. Es decir, el 90% de todos los posibles ataques a nuestra red serán inmediatamente cortados. ¿Por qué? Porque en el mejor de los casos los host externos tan solo podrán alcanzar el router, los paquetes nunca pasarán más allá de este. Cualquier malware que requiera de una conexión activa externa, automáticamente será anulado, puesto que no será nuestros dispositivos los que inicien la comunicación. Pero la seguridad trae consigo que podamos necesitar para nuestros propios fines precisamente el comportamiento que NAT nos está protegiendo, como se ha visto en Full-Cone.

    Hay que tener en cuenta que el Host Y podrá realizar dicha comunicación por cualquiera de sus puertos.

    Restricted-Port Cone

    Host A: 192.168.0.100 : 50000 -> SNAT -> 80.25.213.2 : 51000 | El puerto Interno del host A es 50000, mapeado al puerto externo 51000.
    Host Y : 212.251.23.5 : 1234
    Host Z: 120.21.0.25 : WWWWW

    El Host A envía un paquete IP al puerto 1234 del Host Y a través de su puerto interno 50000.

    El Host Y podrá enviar un paquete al puerto 50000 del Host A enviándolo a la IP pública de este 80.25.213.2 y a su puerto exterior 51000, siempre y cuando lo haga por su puerto 1234, que fue el puerto al que el Host A se conectó. El Host Z en contrapartida no podrá enviar ningún paquete IP al Host A de ninguna de las formas.

    Además de añadir la funcionalidad de Restricted Cone, se añade una capa de seguridad adicional, y es que el puerto usado por el host externo con nuestro hsot interno tendrá que ser el mismo al que se conectó el host interno. Esto es importante. Generalmente los puertos de los host externos suelen estar asociados a servicios concretos. Por ejemplo el puerto 80 suele estar asociado a servidores Web. En un esquema de Restricted Cone, el Host A podría realizar la conexión inicial al puerto 80 del host Y con la intención de recuperar una página web, y el Host Y aprovechando dicha conexión podría en vez de devolver por el mismo puerto 80 la página web usar un puerto al que tenga asociado algún programa o finalidad maligna. El dispositivo NAT no verificaría en ningún momento si el puerto del host Y es el mismo, le sería completamente indiferente. En un esquema de Restricted-Port Cone, si el puerto no coincide el dispositivo NAT no permitiría el reenvío de los paquetes al host A.

    Hay que tener en cuenta que no se soluciona el problema que plantearemos en el siguiente método.

    Symmetric Cone

    Host A: 192.168.0.100 : 50000 -> SNAT -> 80.25.213.2 : 51000 | El puerto Interno del host A es 50000, mapeado al puerto externo 51000.
    Host A: 192.168.0.100 : 50001 -> SNAT -> 80.25.213.2 : 51001 | El puerto Interno del host A es 50001, mapeado al puerto externo 51001.

    Host Y : 212.251.23.5 : 80
    Host Z: 120.21.0.25 : 80

    El Host A envía un paquete IP al puerto 80 del Host Y por su puerto 50000 y otro al puerto 80 del Host Z a través de su puerto interno 50001.

    En este caso, incluso en un esquema de Restricted-Port Cone NAT, el host Z podría realizar una conexión al puerto 50000 del Host A, aunque dicha conexión se usase para conectarse al host Y y no al Host Z. Se cumpliría la restricción de puerto, dado que tanto el host Y como el Z se comunican por el puerto 80, y se cumpliría la premisa de una comunicación previa. Con Symmetric Cone, el dispositivo NAT registraría un seguimiento integral de las comunicaciones de entrada/salida de este. En este caso, el Host Y solo podría comunicarse con el Host A por el puerto externo 51000, y el Host Z solo podría hacerlo por el puerto externo 51001.

    No obstante, NAT plantea diversos problemas reales que puede hacer que ciertas aplicaciones sean inviables de usar. El caso más típico es por ejemplo los clientes FTP. El protocolo FTP tiene dos métodos de funcionamiento fundamentales: Modo Pasivo y Modo Activo. En Modo activo, una vez que el cliente FTP realiza la conexión al servidor FTP externo, el servidor FTP externo se conectará a un puerto DIFERENTE del cliente. Esto no es posible hacerlo con NAT, ya que NAT esperará que la única conexión entrante se realice por el mismo puerto que cursó la conexión. El modo Pasivo por otro lado usa el puerto 21 para todo, con lo que el cliente FTP funcionaría perfectamente.

    Este tipo de problemas se han ido solucionando con diferentes aproximaciones. Para ello la mayoría de routers permiten el mapeo de puertos indiscriminado, es decir, abrir de forma permanente un cierto número de puertos al exterior que estarán siempre mapeados a ciertos puertos de un host específico de la red. Otros por ejemplo permiten sistemas como el disparo de puertos, que es un mapeo de puertos similar, pero de forma dinámica, es decir cuando el cliente realiza la conexión al exterior por un puerto concreto, el router mapearía en ese justo momento y no antes una serie de puertos que podrían ser usados por el host remoto para la comunicación. No obstante el problema de estos métodos es el mismo, en ambos casos se necesita saber con antelación que puertos son los que los hosts remotos pueden necesitar, con la idea de poder tenerlos abiertos antes de realizar la conexión. Cuando son aplicaciones concretas conocidas o son pocos puertos, no es un problema demasiado grande (aunque bastante inseguro). Pero este tipo de soluciones se hacen imposibles si no conocemos los puerto que puede necesitar el host remoto. Es aquí donde se requiere de tecnologías que hagan NAT transversal, es decir que puedan saltarse el dispositivo NAT. NAT transversal no es algo tan simple de realizar, y los routers que disponemos deben de ser capaces de realizar ciertas funciones un tanto más avanzadas. Generalmente basadas en túneles u otros protocolos.


  • Servidor DNS

    Ya sabemos que son los servidores DNS, así que no vamos a describirlos ahora. ES cierto que los servidores DNS requieren generalmente una gran capacidad de procesamiento para funcionar correctamente, pero podemos encontrar entornos en los que no necesitemos de servidores específicos de DNS, y podamos descargar dicha tarea en un router. Si bien es cierto que a día de hoy el software más extendido para los servidores DNS es BIND, DNSmasq es más común encontrarlo en dispositivos integrados como los routers, que no quiere decir que no podamos encontrar routers con BIND. Lo cierto es que para redes relativamente pequeñas puede ser suficiente un servidor DNS integrado en el mismo router que sea capaz de resolver cualquier nombre de host de cualquier equipo de la propia red interna.


  • Firewall

    Aunque me gustaría tratar todo lo referente a Firewalls en otro tema, lo cierto es que prácticamente cualquier router a día de hoy implementa funciones de Firewall, de cortafuegos. Como ya vimos, NAT es en sí mismo un pequeño cortafuegos, pero este se suele extender para dotar a una red de mayor seguridad.

    A día de hoy lo normal es contar con Firewalls tipo SPI. SPI (stateful packet inspections) sería algo así como Firewalls de inspección intensiva de paquetes, y su funcionamiento es similar al que realiza NAT. La idea de SPI es mantener un rastreo constante de todos los paquetes que entran y salen de la red, construyendo tablas de seguimiento de paquetes y permitiendo o denegando su paso a través de él en función de unas reglas. Como digo en esencia es similar a NAT, el cual mantiene unas tablas que realizan igualmente un seguimiento de las conexiones realizadas. En cambio, auque puedan tener funciones similares no tiene nada que ver uno con el otro. La finalidad de NAT es la de traducir direcciones, no actuar de cortafuegos (aunque sirva para ello).

    Gracias a Firewallos tipo SPI, podemos por ejemplo definir reglas no solo basadas en el origen o destino de los paquetes que se envían o se reciben, sino que podemos crear reglas mucho más complejas, como por ejemplo permitir tan solo un determinado número de conexiones por minuto, permitir tan solo paquetes con determinados flag activados, crear protecciones para ataques de denegación de servicio (DoS)… Con un buen firewall SPI se puede crear prácticamente cualquier filtro que necesitemos.

    Las implementaciones en routers van desde implementar un NAT simple con ellos hasta crear verdaderas puertas seguras a nuestras redes. Quizás la implementación más usada en los routers es el uso de la suite Netfilter (aka iptables) para dicho propósito.


  • VPN

    Virtual Private Network, o red privada virtual es una tecnología usada ampliamente sobre todo en grandes redes, aunque cada vez más se está viendo su uso en redes domésticas y PYMES. Básicamente una VPN es una infraestructura que permite conectar entre sí dos redes a priori independientes separadas generalmente por Internet. Es decir, una tecnología que nos permite conectarnos a la red interna de otro lugar, sin estar conectados físicamente a ella, tan solo a través de internet. Es evidente que puede usarse para muchas otras cosas, como por ejemplo para cifrar el tráfico en una red local o usar VPN para crear túneles entre diferentes ubicaciones.

    La función de VPN correspondía casi siempre a equipos configurados como clientes o servidores de este, o dispositivos integrados específicos para ello. No obstante está siendo cada vez más habitual encontrar routers incluso de segmento medio incorporar funciones de VPN. La mayoría de ellos tan solo para actuar como clientes, otros poseen capacidades de actuar de servidores. Esto tiene mucha más utilidad de la que uno puede pensar. Veamos la utilidad de que un router posea características de cliente o servidor VPN:

    Imaginar que tenemos una pequeña empresa de centros educativos por toda la comunidad andaluza. Cada centro posee una red propia conectada a Internet, y en uno de ellos está un servidor de bases de datos que es donde se almacenan todos los datos de los usuarios matriculados. Cada una de las redes locales de cada centro evidentemente se encuentran separadas incluso por cientos de kilómetros. En este tipo de empresas es normal la actualización de contenidos entre profesores o entre alumnos, no solo en cada centro sino también entre centros. Una solución sería estar enviando constantemente dichos archivos o documentos por correo, o enviar una vez al mes los nuevos datos de matrículas al servidor central. Pero si tenemso creada una infraestructura de VPN podríamos hacer que las 10 o 20 redes de todas las academias se encontrasen todas ellas entre sí en una red local virtual. Cada router de cada academia estaría configurado como cliente de un servidor VPN, que podría ser precisamente otro router. Dado que todos los equipos de cada academia están conectados a su router, esto significaría que todos los equipos de todas las academias estarían a efectos prácticos en una red local propia, todos serían visibles entre ellos, y todos los servicios de red estarían disponibles. Cualquier profesor podría acceder en cualquier momento a la base de datos centra, o compartir un archivo con otro profesor o alumno.

    Existe no obstante otro ejemplo de VPN muy extendido, que es en los juegos Online. Casi todos permite siempre dos tipos de acceso a multijugador, partidas LAN y partidas en Internet. Pues bien, configurando una VPN sería posible realizar partidas en LAN, aun cuando nuestros compañeros estuviesen a miles de kilómetros de nosotros, sin necesidad de publicar las partidas en Internet.

    El como se hace posible este tipo de conexiones a través de Internet, es simple: Túneles. Cuando hablamos de Túneles en redes, generalmente nos referimos al envío de datos encapsulados dentro de otros protocolos. Es decir, enviamos datos de un protocolo por medio de otro protocolo. Un ejemplo simple sería intentar comprender como es posible crear una VPN. Sabemos que las redes locales generalmente usan frames Ethernet, y también sabemos que los frames Ethernet no son jamás transmitidos por Internet. Pero entonces, como es posible que podamos comunicarnos en red local si estamos en la otra parte del mundo? Internet usa paquetes IP para transmitir datos, y generalmente TCP o UDP como protocolos de transporte de estos, pero ninguna especificación dice que tipo de datos puedo enviar por TCP o UDP u otros protocolos de transporte. Es decir, que podría coger un frame Ethernet, meterlo dentro de un paquete IP y enviarlo al otro lado del mundo. Si el otro extremo está preparado para ello podría leer dicho paquete IP, extraer de él el frame Ethernet y enviar dicho frame Ethernet al equpo de su red local. Eso es un Tunel, en este caso se estaría encapsulando un frame Ethernet en un paquete IP, es decir un protocolo de nivel 3 (de red) como IP encapsula o lleva consigo un protocolo de nivel 1 y 2 como Ethernet.

    Existen varios protocolos estándares para VPN, quizás uno de los más antiguos e inseguro (y aun muy extendido) sea PPTP, del cual es fácil encontrar routers con soporte de cliente para él. Un paso más adelante sería L2TP, aunque es menos común que PPTP suele ser más seguro cuando se combina con protocolos de seguridad como IPsec. IPSec es un protocolo de encriptación que fue designado en principio como requerimiento para IPv6, pero su uso está muy extendido por la gran seguridad que brinda no solo a los túneles que pueden crearse, sino para el cifrado de paquetes IP. Quizás, la suite más usada en todo el mundo sea sin duda los clientes/servidores VPN de CISCO o la implementación gratuita OpenVPN, ambas altamente seguras.

    No obstante alguno de estos protocolos presentan dificultades para operar cuando la red se encuentra detrás de un dispositivo NAT. Es por ello que la mayoría de los routers, soporte o no VPN, suelen soportar opciones especiales para permitir el paso de paquetes que usen estos protocolos. Esto es necesario si tenemos en cuenta q los protocolos comentados pueden tener encriptado en sus datos el puerto o el destino de dichos paquetes, con lo que el dispositivo NAT los filtraría de inmediato.Esto suele denominarse Passthrough, en cierto modo es algo similar a lo que se pretende cuando se realiza NAT transversal.


  • QoS

    Lo ideal sería vivir en un mundo en el que no existiesen límites físicos, en el que la información pudiese fluir a velocidades infinitas en caudales infinitos. Pero esto no es la realidad. Es por ello que cualquier red, sea grande o pequeña puede en un momento dado saturarse. Lo normal sería aplicar una política de balanceo, es decir si dispongo de un enlace a Internet de 10Mb/s y 10 clientes conectados a él descargando al mismo tiempo, por ley salomónica cada host tendría aproximadamente 1Mb/s del ancho de banda disponible. Este sistema en realidad es justo, pero nada efectivo en multitud de escenarios. Imaginar que de los 10 clientes que están haciendo uso de dicho ancho de banda, 5 lo están usando para ver páginas web, 3 para descargar archivos y 2 para realizar videoconferencias. Ya no solo son diferentes las necesidades de cada uno en cuanto a ancho de banda se refiere, sino que también poseen diferentes necesidades de fiabilidad de datos o la latencia de estos. Veamos 4 ejemplos típicos en las que las necesidades son completamente diferentes:

    Descarga de Archivos: Cuando descargamos cualquier archivo, generalmente no nos preocupa demasiado si hay muchos errores de transmisión o una latencia alta. Recordar que la latencia no tiene nada que ver con la velocidad de descarga, sino que mide el retraso de la información, es decir podemos tener un flujo constante de 10Mb/s y a la vez tener una latencia de 10 segundos. En realidad cuando descargamos un archivo lo que solemos desear es velocidad pura y dura de descarga. Incluso cuando la transferencia se abortase, tampoco nos supone un gran problema la mayoría de las veces.

    Videconferencias: A diferencia de la descarga de archivos, aquí no necesitamos una gran capacidad de la red, de los 10Mb a lo mejor tendríamos suficiente con 64KB/s. Del mismo modo que con la descarga de archivos, en la videoconferencia la tasa de errores no es importante, no nos importa demasiado que de cuando en cuando el sonido no sea muy claro o el video se pixele o muestre bloques. Pero a diferencia de la descarga de archivos sí tendremos una exigencia muy alta de latencia, necesitamos que la videoconferencia sea en la medida de lo posible en tiempo real, sería imposible mantener una videoconferencia con una latencia ya no de 10 segundos, con 3 segundos sería suficiente para arruinar toda la conversación. Es decir, decimos algo y hasta 3 segundos despues el otro no escucha lo que decimos, tiempo en el que dicha persona ha podido estar hablando. Es evidente que lo fundamental aquí son tiempos de retraso mínimos.

    Cirugía Remota: Esto no es ciencia ficción, es una realidad. Imaginar una operación a distancia con las nuevas tecnologías de las que disponemos. Tecnologías que no requieren en realidad de anchos de banda enormes, en este caso quizás con 100KB/s sería más que suficiente. En cambio, la latencia sería aquí bastante importante. Pero más importante en este caso sería la fidelidad de los datos. Que en un video aparezca de cuando en cuando un error en los colores o e la imagen puede ser un poco molesto, pero que un robot manejado de forma remota corte con un bisturí un centímetro más o un centímetro menos, sí es la diferencia entre la vida o la muerte.

    Descarga de archivos P2P: Normalmente las pretensiones suelen ser similares a las descargas de archivo, salvo con la salvedad de que generalmente deseamos que sean aplicaciones con la menor prioridad de todas. Es decir, el último en solicitar ancho de banda. Generalmente deseamos que el navegador u otras aplicaciones tengan mayor prioridad sobre el ancho de banda que las redes P2P, que generalmente tenemos ejecutas de fondo. Esto no quiere decir que dichas descargas no puedan hacer uso del máximo de la red, solo que si tenemos otras aplicaciones, estas tengan preferencia.

    Esto es lo que hace QoS (Quality Of Service). Las tecnologías QoS se basan ni más ni menos en estos principios , sistemas de control de tráfico para evitar no solo saturaciones en la red, sino aplicar diferentes reglas a diferentes tipos de tráfico. Gracias a los mecanismos QoS, un usuario doméstico podría por ejemplo tener abierto algún programa tipo eMule o Torrent, mientras que a la par descarga archivos por el navegador, mientras que ve otras páginas y mientras que su mujer está hablando por un teléfono VOIP, sin que ninguna de dichas tareas degrade en absoluto el rendimiento de cada una de las demás. No obstante estos mecanismos son bastante complejos, y una mala configuración de ellos puede tener consecuencias bastante impredecibles. Por regla general se suelen combinar diferentes métodos:

    Limitación de ancho de banda: Quizás sea el sistema más simple, limitar a cada cliente o servicio directamente su capacidad a usar. Por ejemplo, podríamos limitar el PC que tenemos abandonado en nuestro hogar y que tan solo tenemos para el eMule, a usar tan solo un 10% de la red. o usar sistemas más complejos, que ajustan de forma dinámica estas limitaciones en función de los demás dispositivos de red.

    Programación: Sistemas que controlan y supervisan las peticiones de los clientes, y según estas las sirve o no en función de ciertas reglas

    Control de la congestión: Si la red llega a su límite, que sucede? La idea es evitar que la red pueda saturarse. El ejemplo más fácil de este tipo de tecnologías es simplemente el descartar (tirar) aquellos paquetes de datos que tengan menos prioridad, con lo que los paquetes con mayor prioridad continuarán llegando correctamente a sus destinos.

    Un buen sistema QoS usará todos los sistemas de control que esté a su alcance para obtener en la medida de lo posible el mejor manejo de los paquetes. Posiblemente el mejor sistema QoS en la actualidad sea DiffServ (Differentiated Services), aunque no es común verlo implementado o usado en redes domésticas (por desgracia). Ya es relativamente habitual encontrar routers con soporte QoS, aunque suelen usar sistemas poco eficientes en su mayoría, aunque fáciles de configurar. Implementar y configurar correctamente QoS en un router doméstico, puede implicar tener una red mucho más ágil  y eficaz, por no decir los beneficios en una red empresarial.



Otros: Puertas de Enlace Residenciales, Modems y Puntos de Accesos

La última serie de dispositivos que vamos a ver, son posiblemente los más usados en la actualidad en el hogar. Como ya he dicho, es muy diferente la estructura/arquitectura de red que puede tener o necesitar un hogar a la que puede tener o necesitar una empresa. Las tecnologías son diferentes, los accesos a la red son diferentes, el número de equipos, la seguridad necesaria… es precisamente por estos motivos por los cuales un usuario normal no tendría que saber nunca que es un puente o un Switch, que es un punto de acceso o que es en realidad un router. Si escogiésemos al azar a un transeúnte y le preguntásemos que es un Router o un Modem, indistintamente te dirían con bastante probabilidad que es “algo de Internet” o el aparato que pone el ISP para Internet. Si le preguntamos que sabe de puentes, nos responderá casi con toda seguridad que es una construcción generalmente de metal/hormigón para alcanzar un terreno no accesible de otro modo.

  • Modems

    La gran mayoría de dispositivos de red que manejamos, trabajan siempre de puertas para dentro, en nuestra propia red. Es cierto que tanto estas redes locales nuestras como toda Internet se basan en lo que denominamos la pila de protocolos TCP/IP, pero sin embargo el método y los medios de transmisión de estos datos es muy diferente según cada escenario. Por ejemplo, en una red doméstica lo normal será que los datos sean trasmitidos por cables de par trenzado Categoría 5e+ o WIFI, mientras que los datos viajarán por estos cables como frames Ethernet traducidos a señales eléctricas. En cambio, eso no significa que nuestros datos viajen del mismo modo por todas las infraestructuras de nuestro ISP, y de echo no lo hacen. Por ejemplo en líneas DSL nuestros datos son enviados por el par de cobres de teléfono de toda la vida hasta unas estaciones llamadas DSLAM, allí se multiplexan (combinan) los datos de este usuario con los de otros muchos y se envían todos ellos (juntos) a un Servidor BRAS. Hasta este servidor, todos los datos que se están manipulando se hacen en bloques, no son redes IP en las que se manipulan los paquetes independientes de cada usuario. Una vez llegan a estos servidores, los datos de los diferentes usuarios se separan y ahora sí se comienzan a rutar por la red IP del propio ISP, y de ahí a cualquier parte del mundo. Pero incluso cuando los datos son enviados al otro lado del mundo, sería una locura pensar que nuestros datos vayan a viajar solos por los enlaces troncales, es decir, nuestros datos se multiplexan continuamente con los de otros cientos/miles de usuarios.

    Dado el funcionamiento explicado, es necesario dispositivos intermedios que puedan transferir esos datos entre diferentes partes de estas infraestructuras. Los Routers dirigen el tráfico, pero los Modems son por así decirlo los que cambian el contexto de los datos. De echo, MODEM son las siglas de MOdulador DEModulador, es decir, su función es la de modular señales, trabajando en el nivel 2 y nivel 1 del modelo OSI. Es por eso que en prácticamente cualquier hogar, se disponga de un Cable-Modem o un Modem xDSL. Estos serán los traductores de nuestros frames Ethernet/ATM a las señales moduladas que se enviarán o recibirán de nuestro ISP. Los Modems por tanto son completamente dependientes de la tecnología para la cual fueron usados, es decir un Modem ADSL no tiene por qué funcionar para una línea ADSL2+, y seguro que no lo hace para líneas VDSL. Del mismo modo un Modem DOCSIS 1.0 (una tecnología de cable) no funcionará para redes DOCSIS 3.0, y evidentemente menos aun para líneas DSL.


  • Puntos de Acceso

    Con puntos de acceso nos referimos intrínsecamente a puntos de acceso WIFI. WIFI ha sido una tecnología inalámbrica de gran éxito en los últimos años, aunque no es la única (BlueTooth). Una vez que desarrollas una tecnología que tenga una aplicación directa en las redes actuales, es interesante integrarla a esta de algún modo. ¿Cómo se hace? Si recordamos, una de las funciones de un Router es precisamente su facilidad para interconectar diferentes tecnologías entre sí. Esto es posible a que del mismo modo que un Router puede hacer uso de Interfaces generalmente Ethernet, puede hacer uso de cualquier otra, si se fabrican con ellas (o se les añade). Si fabricamos un Router con una Interfaz de salida Ethernet y otra WIFI, nuestro Router será capaz de comunicarse a redes Ethernet y Redes WIFI indistíntamente.

    Por lo general, hay 3 formas básicas de hacer esto. La primera es por medio de chips integrados en los mismos dispositivos, tales serían los casos de la gran mayoría de los dispositivos. Evidentemente todos los adaptadores de red en última instancia son chips integrados, pero nos referimos al sistema por el cual se dota de WIFI a un dispositivo. El segundo caso más extendido sería por expansión del hardware por medio de algún conector/puerto/interface, como pueda serlo vía Ethernet, lo que permite dotar con capacidades inalámbricas prácticamente cualquier dispositivo que posea una interfaz de este tipo, aunque otro sistema puede ser el uso de USB. El tener caso sería un poco más complejo de verlo, sería un poco combinación de ambos, en el que se integra directamente un adaptador (chip) inalámbrico, pero usando internamente una interfaz conocida, como Ethernet o USB.

    La gran mayoría de los routers domésticos que se comercializan tienen capacidades inalámbricas integradas. No obstante, es muy habitual la necesidad de disponer de un dispositivo independiente WIFI que permita desde dotar con tales capacidades a un Router o cualquier dispositivo Ethernet, hasta expandir el rango de otros dispositivos inalámbricos. También es cierto que el, cada vez más, bajo precio de los routers WIFI, los puntos de acceso van viendo como su uso como dispositivos propios va disminuyendo cada vez más.


  • Puertas de Enlace Residenciales

    Los podemos llamar también Routers domésticos/residenciales, modem-router… en realidad son la inmensa mayoría de todos los dispositivos que tienen los usuarios domésticos en sus domicilios, la gran mayoría de ellos incluso cedidos o regalados por su propio ISP. De echo, como ya dijimos técnicamente la mayoría de ellos no son Routers, sino que poseen ciertas capacidades de estos. Su uso es una cuestión meramente económica, de espacio y de estética.

    Si enumeramos el equipo que necesitamos para poder conectar un solo dispositivo por medio de una línea ADSL a Internet, necesitaríamos tan solo un Modem DSL que pudiésemos conectar a nuestro PC. Si quisiésemos poder conectar más de un dispositivo de forma simultanea se necesitaría además del Modem DSL un dispositivo NAT que permita conectar todos los dispositivos de la red a Internet, funciones de routers que puedan redirigir el tráfico de un lado a otro… y por supuesto un Switch que permita la conexión de múltiples dispositivos entre ellos. Pero si además queremos conectividad WIFI tendríamso que disponer de un punto de acceso. Eso hace un total de 4 dispositivos!!: Modem, Router, Switch y Punto de acceso. Evidentemente a nadie le gusta tener en su casa 4 dispositivos diferentes para poder tener acceso a Internet en todos sus dispositivos, y la solución por tanto se llama Puerta de Enlace Residencial, o Modem-Router doméstico. ¿Que son? Pues visto desde un punto de vista electrónico es una placa con diferentes chips, pistas de cobre… pero si se aísla cada parte de esta (de la placa), tendríamos que en realidad es una caja negra en la que se han interconectado en la fábrica los 4 dispositivos entre sí. Esto evidentemente no es del todo correcto, pero funcionalmente tanto a nivel práctico como teórico, es exactamente eso:

    La imagen mostrada podría ser perfectamente una puerta de enlace residencial común. Por un lado tendríamos el MODEM DSL, el cual tendría un puerto de entrada tipo RJ11 (donde se conectaría el cable de teléfono). Por otro lado dispondríamos de un Switch de 5 puertos RJ45, 4 de los cuales se encontrarían expuestos al exterior para poder conectar a ellos 4 dispositivos diferentes, ya fuesen equipos, otros Switchs… lo que se desease. Por otro lado dispondríamos de un pequeño adaptador WIFI que dotaría a la puerta de enlace con tales capacidades. ¿Cual sería el nexo de todos ellos? El Router. Este Router en cuestión dispondría de 4 Interfaces físicas diferentes, llamadas PPP, Eth0, Eth1 y Lo, y una Interfaz adicional virtual llamada Br0:

    PPP: Esta sería la Interfaz del Router encargada de realizar el acceso/conexión al MODEM DSL para poder realizar una conexión PPPoE al ISP. Todo lo que envíe por dicha Interfaz irá directamente a nuestro ISP, para después alcanzar cualquier parte del mundo. Del mismo modo todo lo que llegue por dicha interfaz, se procesará en el Router y se determinará su destino.

    Que todas las Interfaces (Y su homólogo en el módulo respectivo) tengan el símbolo de un Conector RJ45 no es un capricho, y es que podríamos verlo como si realmente estuviesen interconectados  ambos por un cable Ethernet. Evidentemente todo estos dispositivos son integrados, ¿pero que diferencia existe realmente entre un conector RJ45 externo (que tiene 8 pins) a 8 pistas de cobre en la baquelita? En realidad un conector no es más que una pieza que nos ayuda sacar fuera dichas pistas para poder conectar algo de forma externa. Si lo que se quiere conectar es un dispositivo interno, no tiene sentido conector alguno. Es decir, que exista o no un conector físico, no significa que el Router se comunique o se deje de comunicar con las demás partes por medio de Ethernet.

    Eth0: Sería la Interfaz del Router conectada al Switch. A través de ella, el router procesaría todas las solicitudes realizadas al exterior de la red formada por el Switch. Esto es a tener en cuenta, ojo, todos los equipos conectados al Switch no requieren de un Router para hablar entre ellos, el router para ellos es la puerta de enlace, el destino de sus paquetes cuando el host a alcanzar no se encuentra dentro de su red. El Router por tanto tomará las peticiones de entrada (de entrada para él, es decir de salida para los dispositivos conectados al Switch) y las procesará, mediante la tabla de rutado determinará por qué interfaz debe de enviar dichos datos para que puedan llegar a su destino. Del mismo modo cuando el Router tiene que enviar un paquete entrante por su Interfaz PPP hacia el Switch, lo realizará por la Interfaz Eth0

    Eth1: La interfaz Wifi, o la Interfaz a la que está conectado el adaptador WIFI del propio Router. Todos los datos que se envíen o reciban a través de WIFI cruzarán dicha Interfaz. Pero cuidado!! A diferencia de como sucedía con el Switch, aunque el paquete sea enviado a otro host de la misma red (ya sea el otro conectado por WIFI o Ethernet), este cruzará siempre por la Interfaz Eth1

    Br0: Bro es una Interfaz Virtual que se crea en el router para crear un puente entre la Interfaz Eth0 y Eth0. Si recordamos los puentes, es una forma de crear redes. Cuando se realiza un puente de dos Interfaces como ya vimos, todos los dispositivos a ambas partes del puente pasarán a constituir una única red entre ellos, aunque constituyesen dos segmentos de red diferente. Dicho de otro modo, es la forma más simple de la que disponemos para unificar de forma más o menos completa todos los equipos conectados al router, ya sean de forma inalámbrica o por medio de cable, para que formen entre ellos una única red. Así, si el Router tiene que enviar un paquete a la red local, no tiene que saber si debe de enviarlo por la Interfaz Eth1 o a la interfaz Eth0, cada una de ellas dos redes independientes, sino que sabe que lo tiene que enviar a la Interfaz Br0, es decir al puente. Por regla general, cualquier puerta de enlace residencial utiliza este procedimiento si dispone tanto de alguna interfaz inalámbrica.

    Lo: Lo (Loopback) podríamos verla como otra interfaz virtual, la dirección de loopback del propio router, que ya ha sido explicada en más de una ocasión su utilidad.

    Con todo eso, solo hay que establecer una tabla de rutado para que los paquetes puedan circular de forma correcta por el router hacia cada uno de los dispositivos anexos. Por ejemplo, si el destino es el propio router se usará la Interfaz Lo, mientras que si el destino es Internet se usará la Interfaz PPP. Si se quiere, se puede volver a la tabla de rutado de ejemplo del comienzo de la sección de “Routers”, y se comprenderá esto mucho mejor. Esto por supuesto es un poco más complejo dado que nuestro router tendrá funciones NAT o un Firewall implementando, o será a lo mejor el mismo Firewall el que está implementando NAT. Todo eso, en conjunción con otras funciones extras es el papel fundamental que realiza aquí dicho Router. De este modo, se logra tener un solo dispositivo que posee todas las cualidades básicas de cada una de las partes que lo forman internamente. Evidentemente este tipo de dispositivos tan solo existe en el mundo doméstico, y los Switchs o Routers decentes que existen se aleja muchas veces enormemente de las funciones tan específicas de nuestros Routers domésticos