10   INTERNETWORKING

 

Autor: Rogelio Montañana

Licencia Creative Commons
Esta obra está bajo una Licencia Creative Commons Atribución-NoComercial-CompartirIgual 4.0 Internacional.

 

10         INTERNETWORKING.. 10-1

10.1     INTRODUCCIÓN.. 10-1

10.1.1      Dispositivos básicos de Internetworking. 10-1

10.2     CORTAFUEGOS. 10-1

10.3     TÚNELES. 10-1

10.3.1      Redes Privadas Virtuales (VPNs) 10-1

10.4     IPSEC.. 10-1

10.5     TRADUCCIÓN DE DIRECCIONES (NAT) 10-1

10.5.1      Tipos de NAT.. 10-1

10.5.2      Limitaciones de NAT.. 10-1

10.6     EJERCICIOS. 10-1

10.7     SOLUCIONES. 10-1

 

10.1INTRODUCCIÓN

 

El término internetworking se utiliza para designar la unión de redes diferentes a cualquier nivel (físico, de enlace, etc.) de forma que desde los niveles superiores se aprecie como una única red homogénea. Las redes pueden diferir en el medio físico (por ejemplo Ethernet-Token Ring o LAN-WAN) o en la pila de protocolos utilizados (TCP/IP, DECNET o SNA, por ejemplo).

 

10.1.1             Dispositivos básicos de Internetworking

 

Algunos de los dispositivos utilizados para realizar internetworking son los siguientes:

 

 

 

 

Muchos routers pueden también actuar como puentes MAC, e incluso como routers para unos protocolos y como puentes para otros. Se suele utilizar la denominación brouter para designar estos equipos, indicando así su doble funcionalidad.

 

La mayoría de los routers actuales soportan múltiples protocolos; así es posible con un solo router unir dos LANs en las que coexistan TCP/IP y DECNET, por ejemplo, sin necesidad de utilizar múltiples líneas o routers; es importante destacar que un router multiprotocolo no suministra una comunicación entre los diferentes protocolos que soporta, simplemente permite que los diversos protocolos de red compartan la infraestructura de comunicaciones, es decir si dos LANs tienen máquinas unas con TCP/IP y otras con DECNET un router multiprotocolo permitirá la comunicación entre las máquinas TCP/IP de una y otra LAN, o de las máquinas DECNET de una y otra LAN, pero no la comunicación de una máquina DECNET con una TCP/IP.

 

Respecto al protocolo de routing un router multiprotocolo puede funcionar de dos maneras:

 

o    Routing integrado: todos los protocolos enrutados comparten un protocolo de routing común; en este caso cada router mantiene únicamente una tabla de rutas, y efectúa el cálculo de rutas únicamente una vez; todos los protocolos enrutados utilizan las mismas rutas, por lo que todos los routers de la red deben soportar todos los protocolos. Ejemplos de protocolos de routing integrado son el IS-IS y EIGRP, que están preparados para entornos multiprotocolo.

 

o    Buques en la noche ('Ships in the night', SIN): esta  técnica consiste en utilizar un protocolo de routing diferente para cada protocolo enrutado; en este caso los algoritmos utilizados y la topología de la red puede variar para cada protocolo y los cálculos han de hacerse independientemente para cada uno; evidentemente las rutas elegidas pueden no ser las mismas para todos los protocolos. Cada router encamina los paquetes de cada protocolo de forma independiente y éstos viajan por las líneas sin verse unos a otros, de ahí el nombre de Ships in the Night que recibe esta técnica. Con esta técnica cada router sólo ha de enrutar los paquetes correspondientes a aquellos protocolos en los que participa.

 

Por ejemplo la red de la Universidad de Valencia soporta dos protocolos, TCP/IP y Appletalk. Como protocolo de routing se utiliza EIGRP que permite routing integrado, con lo que se simplifica la cantidad de proceso en los routers, que de esta forma no han de realizar dos veces el cálculo de las rutas óptimas.

 

 

Los problemas que se plantean en la interconexión de redes diferentes a nivel de pasarelas de aplicación son en cierto modo parecidos a los que se dan a niveles inferiores, como ocurre al interconectar redes Ethernet y Token Ring. Por ejemplo, si se dispone una pasarela de correo electrónico entre dos redes diferentes, una de las cuales implementa acuse de recibo y la otra no, se plantea el problema de qué hacer en la pasarela cuando un mensaje es enviado de la primera a la segunda; a lo sumo se podría acusar recibo cuando el mensaje se recibe en la pasarela, pero eso no significa que el mensaje haya llegado a su destino; la otra alternativa sería simplemente no enviar ningún acuse de recibo en este caso.

 

Además de permitir la interconexión de protocolos distintos las pasarelas de aplicación también se emplean para conectar redes con el mismo protocolo. Existen diversas razones por las que esto puede ser conveniente, como por ejemplo las siguientes:

 

o    Seguridad (cortafuegos): si se quiere tener un control riguroso del tráfico entre una determinada red y el exterior se dispone un cortafuegos que aísle dicha red; a menudo los cortafuegos (o firewalls) actúan como pasarelas a nivel de transporte o de aplicación.

 

o    Eficiencia (servidores proxy/cache): los servidores cache permiten capturar una copia de la información que un usuario se trae del exterior para disponer de ella a<nte la eventualidad de que más tarde otro usuario requiera la misma información. Esto mejora el tiempo de respuesta al usuario ya que la información solicitada se le sirve localmente y reduce el nivel de ocupación de la línea WAN o la conexión a Internet, normalmente de elevado costo. Para realizar su función los servidores caché actúan como pasarelas del nivel de aplicación, normalmente para el protocolo http.

 

o    NAT (traducción de direcciones): Como veremos más adelante existen situaciones en las que es necesario manejar un direccionamiento diferente en la red interna y la externa; en estos casos es preciso utilizar un dispositivo NAT (Network Address Translation) que nos permita el intercambio de paquetes entre ambas redes. Algunas aplicaciones requieren una complejidad mayor en el proceso de traducción de direcciones hasta el punto de que esto solo es posible mediante un programa que interprete y modifique la información contenida en el paquete a nivel de aplicación.

 

10.2CORTAFUEGOS

 

Especialmente con el crecimiento comercial de la Internet muchas empresas se enfrentan ante la necesidad de conectar sus redes al exterior; sin embargo esto plantea varios problemas de seguridad por diversos motivos, por ejemplo:

 

o    Los ordenadores de la red local contienen información de carácter confidencial cuya salvaguardia resulta vital para la empresa.

 

o    Del exterior pueden llegar virus u otro tipo de programas que perjudicarían seriamente los ordenadores de la empresa.

 

o    Los empleados pueden utilizar la conexión a Internet para salir a lugares no autorizados (por ejemplo servidores de información no relacionados con su actividad en la empresa).

 

Para resolver los problemas de acceso seguro hacia/desde el exterior se ha creado el concepto de cortafuego o firewall, que consiste en un dispositivo formado por uno o varios equipos que se sitúan entre la red de la empresa y la red exterior (normalmente la Internet); el cortafuego analiza todos los paquetes que transitan entre ambas redes y filtra los que no deben ser reenviados, de acuerdo con un criterio establecido de antemano.

 

En su versión más simple el cortafuego consiste únicamente en un router en el que se han configurado diversos filtros, por ejemplo impidiendo o limitando el acceso a determinadas direcciones de red, o el tráfico de ciertas aplicaciones o una combinación de ambos criterios. Dado que los usuarios siguen teniendo conexión directa a nivel de red con el exterior esta solución no es muy fiable; además las posibilidades de definir filtros en los routers son limitadas y el rendimiento se resiente de forma considerable si al router se le carga con una tarea de filtrado compleja.

 

El siguiente nivel de cortafuego está formado por un host que conecta por una parte a la Internet y por otra a la red corporativa, actuando él como router. El host implementa un servidor Web proxy que actúa como pasarela de aplicación para los servicios que se quieren permitir, limitado por las restricciones, filtros o reglas que se han especificado. El ordenador que actúa como barrera entre la red interna y la Internet se denomina host bastión (‘bastion host’) en terminología de cortafuegos. Esta solución ofrece una seguridad mayor que la anterior ya que el servidor proxy , al ser un host, puede procesar filtros mas complejos que un router; pero si un usuario malintencionado (hacker o cracker) consiguiera instalar un programa 'espía' (sniffer) en el host bastión podría capturar tráfico de la red interna de la empresa, ya que está directamente conectado a la LAN.

 

En un nivel mayor de seguridad el cortafuego se implementa mediante un host y dos routers, conectados entre sí por una pequeña red local; uno de los routers conecta a su vez con la red local de la empresa y el otro con la Internet; el host implementa una pasarela multiaplicación (servidor proxy) como antes, pero al no estar el directamente conectado a la red local de la empresa incluso en el caso de que un hacker consiguiera instalar en él un sniffer no podría capturar tráfico confidencial, pues solo podrá ver los paquetes dirigidos a él. En este modelo la red que une los routers con el host se denomina zona desmilitarizada o zona DMZ (Demilitarized Zone, algo así como una zona neutra de seguridad). En ocasiones se utilizan otras variantes de arquitectura de cortafuego aún mas complejas.

 

En seguridad de redes, además de una buena arquitectura de cortafuego es importante comprobar que no hay 'agujeros' que permitan el acceso no controlado por otras vías. Por ejemplo, en una empresa con una red altamente protegida podría una oficina regional haber establecido una conexión local con otra institución sin conocimiento de los responsables de seguridad, o disponer de un sistema no seguro de autentificación de usuarios en el acceso por red conmutada para teletrabajo. En suma, que además de un buen cortafuego hay que tener una política de seguridad rigurosa si se quiere que las medidas sean efectivas, de lo contrario habremos puesto una puerta blindada, pero nos pueden entrar ladrones en casa por el 'trastero' con gran facilidad.

10.3TÚNELES

 

En ocasiones se quiere intercambiar paquetes entre dos redes que utilizan el mismo protocolo, pero que están unidas por una red que utiliza un protocolo diferente. Por ejemplo supongamos que un banco dispone de una red de área extensa con protocolo SNA que une todas sus oficinas, y dos de éstas disponen además de redes locales TCP/IP. Si se desea que estas dos oficinas intercambien tráfico TCP/IP sin establecer para ello una nueva línea ni instalar routers multiprotocolo en todo el trayecto se puede establecer un túnel entre ambas oficinas. Los dos nodos SNA ubicados en los extremos del túnel serán los encargados de añadir a los paquetes IP la cabecera SNA adecuada para que lleguen al otro extremo. Los paquetes IP viajarán ‘encapsulados’ a través del túnel en paquetes SNA, de forma que los paquetes IP no sean vistos por la red SNA. Los conceptos de túnel y de encapsulado de paquetes van siempre asociados entre sí.

 

En Internet hay situaciones en las que los túneles se utilizan de forma habitual; por ejemplo la interconexión de routers multicast a través de routers unicast para constituir la red MBone, o la interconexión de ‘islas’ IPv6 para constituir el 6bone. En estos casos los túneles se utilizan para enviar paquetes del mismo protocolo (IP) pero de distinto tipo (multicast en unicast) o versión (IPv6 en IPv4). En algunos casos resulta útil encapsular incluso un paquete en otro del mismo tipo y versión; por ejemplo encapsulando un paquete IPv4 en otro podemos forzar la ruta que ha de seguir, cumpliendo así una función similar a la opción ‘loose source routing’ de la cabecera IP, pero sin las limitaciones que tiene ésta en el número de direcciones. Otro uso del encapsulado podría ser para superar el valor máximo del campo TTL; al utilizar encapsulado la cabecera interior empezaría a descontar su TTL sólo a partir del punto de salida del túnel.

 

Uno de los usos más habituales de los túneles actualmente es para la creación de redes privadas virtuales o VPNs, como veremos a continuación.

 

Los túneles no son una solución deseable en sí mismos, ya que a lo largo del túnel los paquetes han de llevar dos cabeceras, lo cual supone un mayor overhead; además los extremos del túnel se convierten en puntos simples de fallo y potenciales cuellos de botella en el rendimiento de la red.

 

10.3.1             Redes Privadas Virtuales (VPNs)

 

Entendemos por red privada virtual o VPN (Virtual Private Network) la interconexión de un conjunto de ordenadores haciendo uso de una infraestructura pública, normalmente compartida, para simular una infraestructura dedicada o privada. Entre las características propias de una red privada virtual se encuentra la posibilidad de utilizar direccionamiento no integrado en la red del proveedor del servicio.

 

Existen muchas maneras de crear y utilizar VPNs, tanto en IP como en otros protocolos. Aquí solo comentaremos algunas de sus posibilidades más habituales para que sirvan como ejemplo de su aplicación.

 

Supongamos que un viajante quiere conectarse remotamente a la red de su empresa para consultar una base de datos y para ello emplea los servicios de un proveedor comercial cualquiera, ya que esto le permite conectarse a su red pagando tarifa metropolitana. Supongamos también que por razones de seguridad o de licencias de software la empresa se ha visto obligada a limitar el acceso a dicha base de datos únicamente a los ordenadores de la red de la empresa, es decir aquellos que tienen direcciones IP de su red (supongamos que se trata de la red 199.1.1.0/24). Como nuestro viajante al conectarse recibe una dirección IP de la red de su proveedor (supongamos que se trata de la red 200.1.1.0/24) no le es posible acceder a dichos servicios.

 

Este problema puede resolverse creando un túnel VPN (Virtual Private Network) entre el ordenador del viajante y un ordenador de la red de su empresa. El túnel le va a permitir a nuestro usuario remoto acceder a la red de la empresa como si estuviera conectado en la red local (aunque con una velocidad que dependerá obviamente de la conexión física que utilice). El túnel se creará entre su ordenador y un equipo que denominaremos ‘servidor de túneles’ ubicado en la red local de la empresa, el cual se encargará de encapuslar y desencapsular los paquetes de este usuario. Veamos en detalle como funcionaría el túnel VPN en este caso concreto.

 

En primer lugar, la empresa deberá tener el servidor de túneles conectado a su red local; dicho servidor puede ser un equipo específicamente diseñado para este fin, un router o un servidor de propósito general Linux o Windows 2000 Server por ejemplo (el software necesario para actuar como servidor de túneles VPN está incluido en Windows 2000 server). Supongamos que el servidor de túneles está conectado a la red local mediante una interfaz Fast Ethernet y que tiene la dirección IP 199.1.1.10. Además de disponer de una dirección propia el servidor de túneles debe tener asignado un rango de direcciones que utilizará para establecer los túneles. Supongamos que no esperamos más de 10 usuarios simultáneos de este servicio, por lo que reservamos para este fin las últimas 10 direcciones útiles de la red de la empresa, es decir el rango que va de la 199.1.1.245 a la 199.1.1.254 ambas inclusive.

 

Supongamos ahora que nuestro viajante se conecta por red telefónica a su proveedor habitual y que mediante la asignación dinámica de direcciones de PPP recibe de éste la dirección 200.1.1.20. A continuación se conecta con el servidor de túneles y, previa autentificación mediante usuario/contraseña, el servidor crea un túnel para él y le asigna la dirección 199.1.1.245. A partir de ese momento los datagramas que envíe el viajante llevarán dos cabeceras, una exterior y otra interior. Si el viajante hace desde su PC un ping a una dirección cualquiera de la empresa (por ejemplo la 199.1.1.69) enviará un datagrama cuya cabecera exterior llevará como dirección de origen 200.1.1.20 y de destino 199.1.1.10 (el servidor de túneles) y en la cabecera interior llevará como dirección de origen 199.1.1.245 y como destino 199.1.1.69; este datagrama hará su viaje en dos etapas; en la primera llegará al servidor de túneles (199.1.1.10), que lo despojará de su cabecera exterior y procesará a continuación la cabecera interior, enviando el datagrama al destino deseado en la red de la empresa. El datagrama de respuesta al ping seguirá un proceso simétrico inverso, es decir hará la primera parte de su viaje con una sola cabecera que contendrá 199.1.1.69 como dirección de origen y 199.1.1.245 como destino; ese datagrama será entregado al servidor de túneles, que se encargará entonces de incorporarle la cabecera exterior con dirección de origen 199.1.1.10 y de destino 200.1.1.20; cuando llegue al ordenador del viajante el software cliente VPN le despojará de la cabecera exterior y lo procesará como un datagrama dirigido a él proveniente de 199.1.1.69. Así pues el uso del túnel VPN permite a nuestro viajante acceder a la red de su empresa como si estuviera conectado en la red local detrás del servidor de túneles. El software necesario para crear túneles VPN como el descrito en este ejemplo está integrado en sistemas tales como Windows 98 o Windows 2000 profesional.

 

Obsérvese que mientras está operativo el túnel todo el tráfico del usuario remoto con cualquier destino de Internet (pertenezca o no a la empresa) se realiza a través del servidor de túneles. Esto significa que el usuario sufrirá las limitaciones asociadas a la capacidad del servidor de túneles y, si accede a destinos ubicados fuera de la red local de su empresa sufrirá también las limitaciones que le imponga la conexión a Internet que tenga su empresa; por tanto lo lógico sería utilizar la conexión a través del túnel únicamente cuando se requiera acceder a servicios de acceso restringido dentro de la red de la empresa.

 

Además de conectar un ordenador aislado como en el ejemplo anterior es posible establecer un túnel VPN entre routers. Esto nos permite conectar toda una red local a través de un solo equipo, y además no requiere soporte de túneles en el host final. En este caso los routers serán los encargados de realizar la labor de encapsulado/desencapsulado de datagramas. Las VPNs permiten conectar por ejemplo una oficina remota a una oficina principal utilizando Internet, con lo que los costes se pueden reducir considerablemente, especialmente si se trata de conexiones de larga distancia. Además, la reciente aparición de conexiones a Internet de alta velocidad y bajo costo (fundamentalmente ADSL y cable módems) hace especialmente atractivo el uso de túneles VPN sobre este tipo de servicios para constituir enlaces internos en una red sin incurrir en los elevados costos de constituir una infraestructura dedicada mediante enlaces punto a punto o circuitos frame relay o ATM.

 

10.4IPSEC

 

Con bastante frecuencia cuando se establecen túneles VPN como hemos visto en los ejemplos anteriores, además de la integración de las direcciones de red se plantea un requerimiento desde el punto de vista de la seguridad, dado que los datagramas viajan por una infraestructura pública en la que la información puede ser capturada y/o modificada por usuarios externos. Por este motivo la constitución de túneles VPN viene acompañada a menudo de un requerimiento de seguridad, constituyendo lo que podríamos denominar redes privadas virtuales seguras.

 

El problema de una comunicación segura a través de una red se resuelve normalmente a nivel de enlace, a nivel de red o a nivel de aplicación. Cada una de estas tres alternativas tiene sus ventajas e inconvenientes:

 

o    Nivel de enlace: La seguridad a nivel de enlace se implementa en los dispositivos que se conectan al medio de transmisión, por ejemplo dos routers que se comunican mediante una línea punto a punto. En este caso los mecanismos de seguridad se pueden aplicar de forma transparente al protocolo utilizado a nivel de red. Sin embargo en una red grande requiere encriptar y desencriptar la información en cada salto que da el paquete; aun en el caso de utilizar dispositivos que realicen esta tarea por hardware el retardo que esto puede introducir cuando el número de saltos es elevado puede hacer inviable el uso de aplicaciones en tiempo real que requieren cierto nivel de Calidad de Servicio. Además implementar seguridad a nivel de enlace requiere controlar la infraestructura de la red, cosa que no es factible cuando se utilizan los servicios de un operador o un ISP. Un ejemplo de seguridad a nivel de enlace se da en las redes de televisión por cable (CATV) en que la información viaja encriptada (DES) entre el Cable Módem y el CMTS (Cable Modem Termination System); al ser las redes CATV un medio broadcast es necesario el uso de encriptación para evitar la captación de información por parte de usuarios que no son los destinatarios de la misma.

 

o    Nivel de red: Esta es la aproximación adoptada por los estándares IPSec. En este caso la seguridad se limita al protocolo IP y otros protocolos sólo podrán aprovecharla si se encapsulan previamente en paquetes IP. La seguridad a nivel de red puede aplicarla el usuario de forma transparente al proveedor del servicio y encaja de forma muy adecuada con el concepto de VPNs pudiendo crear lo que denominamos redes privadas virtuales seguras.

 

o    Nivel de aplicación: esta es la aproximación adoptada por ejemplo en correo electrónico por PEM (Privacy Enhanced Mail) o PGP (Pretty Good Privacy), en HTTP por Secure HTTP o SSL (Secure Sockets Layer), o por SNMP versión 3. El principal inconveniente de abordar la seguridad a nivel de aplicación estriba precisamente en la necesidad de incorporar funcionalidades similares en cada uno de los protocolos del nivel de aplicación que deban utilizarlas, replicando así gran cantidad de tareas en diferentes partes de código. La ventaja es que la seguridad se puede desarrollar de forma selectiva, aplicándola únicamente en el intercambio de información confidencial o importante. Además, al aplicarse los mecanismos de encriptado o validación de la información en el nivel más alto posible el nivel de seguridad obtenido es máximo ya que se reduce el riesgo de que la información pueda ser interceptada o modificada por otros usuario o procesos distintos del destinatario de ésta.

 

Denominamos IPSec al conjunto de estándares que trata todo lo relacionado con el intercambio seguro de información a través de Internet. En realidad IPSec es una arquitectura (descrita en el RFC 4301) y un conjunto de protocolos y mecanismos de autenticación y encriptado.

 

Las principales funcionalidades que incorpora IPSec son las siguientes:

 

o    AH (Autentication Header): en este caso no se pretende garantizar la confidencialidad de la información sino únicamente su veracidad. La cabecera de autentificación asegura al receptor que el datagrama no ha sido alterado durante su viaje por la red, ni en su contenido ni en su cabecera (salvo por la modificación del campo TTL y por consiguiente del checksum, que se han de realizar en cada salto); por consiguiente además de garantizarse el contenido se garantiza la autenticidad del remitente. AH se describe en el RFC 4302.

 

o    ESP (Encapsulating Security Payload): garantiza la confidencialidad de la información. La parte de datos del datagrama (incluida la cabecera de transporte) viaja encriptada de forma que sólo el destinatatrio pueda descifrar su contenido. Opcionalmente ESP puede incluir la funcionalidad de AH, es decir garantizar que el contenido no ha podido ser alterado por terceros. ESP se describe n el RFC 4303.

 

o    ISAKMP (Internet Security Association and Key Management Protocol): consiste en una serie de mecanismos seguros para realizar, de forma manual o automática, el intercambio de claves necesarias para las labores de encriptado y autentificación realizadas por AH y ESP. ISAKMP se describe en el RFC 4306.

 

Podemos distinguir dos modos de funcionamiento de IPSec:

 

a)       Modo transporte: la encriptación se realiza extremo a extremo, es decir del host de origen al host de destino. Para extender en una empresa el uso de IPSec en modo transporte es necesario que todos los hosts tengan una implementación de IPSec.

 

b)       Modo túnel: el encriptado se efectúa únicamente entre los routers de acceso a los hosts implicados. En este caso la información viaja no encriptada en la parte de la red local. El funcionamiento de IPSec en modo túnel permite integrar de forma elegante IPSec en una VPN, ya que el mismo dispositivo que realiza el túnel VPN se encarga de realizar las labores correspondientes al túnel IPSec.

 

Evidentemente el modo transporte es más fiable puesto que ofrece comunicación segura host a host. Sin embargo el modo túnel tiene la ventaja de que permite incorporar la seguridad sin necesidad de incorporar IPSec en los hosts; aunque la seguridad que se obtiene en este caso no es tan alta la sencillez de implantación es mucho mayor y se consiguen la mayor parte de los beneficios del modo transporte, ya que se protege la parte más expuesta del trayecto, que corresponde precisamente a la infraestructura pública o del operador. En función de las circunstancias que rodeen cada caso se deberá optar por una u otra, pudiendo haber incluso situaciones híbridas en las que en una misma empresa determinado tipo de información baste protegerla con el modo túnel mientras que para algún host concreto, que maneje información de mayor importancia, se deba utilizar el modo transporte.

 

Aunque en IPSec se prevé la posibilidad de utilizar una amplia diversidad de algoritmos de autentificación y encriptado el único exigido para todas las implementaciones es el DES (Data Encription Standard) que utiliza claves de 56 bits. Desde hace unos años se sabe que DES es relativamente poco seguro, ya que el código puede ser descifrado utilizando fuerza bruta en un tiempo no demasiado grande con un ordenador potente actual, por lo que también se suele utilizar bastante Triple DES, que es mucho más seguro aunque también algo más costoso de calcular. En un futuro próximo se prevé utilizar el algoritmo AES (Advanced Encryption Standard) del cual aún no existen implementaciones comerciales.

 

Uno de los problemas que plantea la encriptación es el consumo intensivo de CPU. Esto suele ser un problema especialmente en los routers y servidores de túneles que atienden túneles IPSec con la función ESP activada (la función AH no requiere encriptación). En estos casos se pueden concentrar cientos de usuarios y flujos de varios Megabits por segundo en un mismo equipo, que ha de realizar las labores de encriptado/desencriptado para todos ellos, pudiendo verse limitado el rendimiento de las comunicaciones por la capacidad de la CPU del equipo utilizado. Para evitar este problema muchos servidores de túneles y routers permiten incorporar módulos que realizan los algoritmos de encriptación por hardware para hacerlos con mucha mayor rapidez.

 

10.5TRADUCCIÓN DE DIRECCIONES (NAT)

 

Hace unos años cuando una organización deseaba conectar su red de forma permanente a la Internet lo normal era que solicitara al NIC una red adecuada a sus necesidades (clase B o C normalmente) y asignara números IP de dicha red a todas sus máquinas. De esta forma todos los ordenadores tenían acceso directo a Internet con todas las funcionalidades. Pero debido al crecimiento exponencial de Internet cada vez resulta más difícil obtener números IP del NIC correspondiente; por otro lado, en muchas ocasiones no se necesita, o incluso no se desea, disponer de un acceso directo a Internet con completa funcionalidad, por razones de seguridad fundamentalmente. Estos dos motivos, la seguridad y la dificultad para conseguir direcciones públicas, han impulsado a las organizaciones a hacer un mayor uso de las redes privadas según los rangos especificados en el RFC 1918 (10.0.0.0, 172.16.0.0 a 172.31.0.0, y 192.168.0.0 a 192.168.255.0). Estas redes privadas no pueden en principio intercambiar datagramas directamente con el exterior, por lo que han de utilizar un equipo intermedio que se ocupe de realizar la traducción de direcciones o NAT (Network Address Translation).

 

El NAT puede realizarse en un host (por ejemplo en Linux la función NAT se denomina ‘IP Masquerade’) aunque también se implementa en muchos routers. Dado que generalmente la función de NAT se realiza en la frontera entre una red local y el exterior la opción del router es bastante popular.

 

Normalmente NAT solo traduce paquetes IP correspondientes a ICMP o a los protocolos de transporte TCP y UDP. El resto de protocolos (fundamentalmente protocolos de routing) no se traducen pues no tendría sentido intercambiar información de routing a través de un NAT. Otra restricción que impone el NAT es que solo puede haber un punto de comunicación entre la red privada y la red pública, es decir la conexión al exterior solo puede hacerse en un router, aunque dicho router puede mantener conexiones con varios ISPs simultáneamente.

 

10.5.1             Tipos de NAT

 

Inicialmente los NAT solo permitían iniciar conexiones desde ‘dentro’, es decir desde la red privada hacia el exterior. Este modo de funcionamiento, que se considera una medida de seguridad, se denomina NAT tradicional. Mas recientemente se ha extendido el uso de NATs que también permiten el inicio de la sesión desde fuera, por lo que a este tipo de NAT se le denomina NAT  bidireccional.

 

La traducción se puede hacer de dos maneras: modificando únicamente la dirección IP, que es lo que denominamos NAT básico, o cambiando también el número de puerto TCP o UDP, que llamaremos NAPT (Network Address Port Translation).

 

Por último, si la traducción entre la dirección pública y la privada se realiza de acuerdo con una tabla de equivalencia que se carga en la configuración del dispositivo NAT y si dicha tabla no se modifica dinámicamente decimos que se trata de NAT Estático. En cambio si la tabla de equivalencia es gestionada dinámicamente por el dispositivo NAT de forma que las direcciones y/o números de puerto se puedan reutilizar decimos que tenemos un NAT dinámico. Generalmente el NAT estático es bidireccional mientras que el NAT dinámico es unidireccional (también llamado tradicional).

 

Combinando el NAT Básico o el NAPT con las modalidades estática y dinámica obtenemos cuatro combinaciones de NAT que pasamos a describir a continuación:

 

·         NAT básico estático. La tabla de equivalencias IP privada – IP pública está incluida en la configuración del dispositivo NAT y solo se modifica por decisión del administrador de la red. La correspondencia es biunívoca, es decir a cada dirección privada le corresponde una pública y viceversa. Los números de puerto no se modifican. Con este tipo de NAT es preciso disponer de un número de direcciones públicas igual al de direcciones privadas. Este NAT tiene interés fundamentalmente en situaciones en las que se desea máxima sencillez y no se necesita reducir el número de direcciones públicas, por ejemplo se quiere conectar a Internet una red clase C privada y se dispone para ello de una red clase C pública.

 

·         NAT básico dinámico. La tabla de equivalencias de IP privada a IP pública se construye de forma dinámica, a medida que lo requieren los hosts. Las entradas caducan al terminar la conexión (TCP) o pasado un tiempo de inactividad (UDP), lo cual permite la reutilización de las direcciones.  Los números de puerto no se modifican. El número de direcciones públicas puede ser inferior al de direcciones privadas, pero ha de ser suficiente para el número de ordenadores que se quieren conectar simultáneamente al exterior. Permite un ahorro de direcciones frente al NAT estático, pero al no modificar el número de puerto es más fácil de implementar y tiene menos restricciones que el NAPT. En cierto modo es equivalente a utilizar DHCP con aisgnación dinámica de direcciones.

 

·         NAPT (Network Address Port Translation) estático. En este caso la tabla de equivalencia se carga de forma estática en la configuración del equipo, pero las entradas incluyen no sólo la dirección IP sino también el número de puerto (TCP o UDP). El NAPT estático permite virtualizar servidores: por ejemplo es posible asignar el puerto 21 (servidor FTP) de una dirección pública del NAT al puerto 21 de un host en la red privada, y el puerto 80 (servidor Web) de la misma dirección a otro host de la red privada.

 

·         NAPT (Network Address Port Translation) dinámico. En este caso la tabla de equivalencias se construye dinámicamente a medida que los hosts lo requieren, como en el NAT básico dinámico. Sin embargo, a diferencia de aquel las entradas de la tabla incluyen no solo la dirección IP, sino también el número de puerto. En el caso de TCP las entradas caducan al terminar la conexión. EN UDP, donde no hay conexión como tal, las entradas caducan pasado un tiempo de inactividad. En ambos casos es posible aprovechar una misma dirección IP pública para conectar al exterior diversos ordenadores simultáneamente, ya que se aprovecha el número de puerto UDP o TCP para multiplexar conexiones de hosts diferentes. Este NAT permite un aprovechamiento máximo de las direcciones públicas, pero tiene mayor complejidad de implementación.

 

Las cuatro modalidades antes descritas pueden coexistir en una misma red, por ejemplo utilizando NAT o NAPT estático para los servidores que deban ser accesibles desde el exterior y NAT o NAPT dinámico para el resto de los hosts.

 

Las modificaciones que NAT introduce en el paquete IP son las siguientes:

 

·         Cabecera IP: Además de modificar las direcciones de origen y/o destino el valor del campo checksum en la cabecera del datagrama cambia y por tanto ha de recalcularse.

 

·         Cabecera de transporte (TCP/UDP): El campo checksum en la cabecera de transporte (TCP o UDP) ha de recalcularse, ya que la pseudocabecera incluye las direcciones IP de origen y destino. Además en el caso de NAPT se ha de modificar el valor del puerto de origen o destino.

 

·         Mensajes ICMP: Los mensajes ICMP siempre incluyen en la parte de datos la cabecera a nivel de red y de transporte del paquete IP que originó el mensaje ICMP. El dispositivo NAT ha de localizar allí la dirección IP y modificarla. En el caso de hacer NAPT se ha de modificar también el número de puerto TCP/UDP que aparece en la cabecera embebida.

 

·         Mensajes SNMP. Los mensajes de gestión, que notifican cambios en la situación de los diferentes dispositivos, suelen llevar en su parte de datos direcciones IP que el NAT debe localizar y modificar.

 

10.5.2             Limitaciones de NAT

 

A medida que aumenta el nivel de sofisticación aumenta como es lógico la complejidad del NAT. En el caso del NAT o NAPT dinámico el router ha de conservar una información de estado, ya que ha de mantener control de las conexiones existentes. Esta información de estado hace más difícil establecer un router de backup ya que esta información de estado ha de trasladarse a dicho router en caso de caída del principal. Además el router ha de tomar decisiones respecto a cuando termina una conexión para liberar la correspondiente entrada en su tabla (la de dirección IP en el caso de NAT o la de dirección IP y el puerto TCP/UDP en el caso de NAPT). En TCP es fácil detectar el cierre de la conexión a través de los segmentos que tienen el bit FIN puesto, pero en UDP no existe un procedimiento explícito de desconexión, por lo que en estos casos normalmente se fija un tiempo de inactividad a partir del cual una conexión se considera inexistente, o bien se espera a tener que liberar recursos y entonces se cierra la conexión que lleva más tiempo inactiva.

 

Incluso en el caso más sencillo del NAT básico estático se plantean problemas de difícil solución que hacen que determinadas aplicaciones no funcionen a través de estos dispositivos. Algunos ejemplos de situaciones en las que el NAT tiene dificultades o no funciona son las siguientes:

 

·         Protocolo FTP. En el momento de establecer una conexión FTP los hosts intercambian una serie de mensajes que contienen entre otra información sus direcciones IP. Lógicamente estas direcciones han de modificarse. El problema en este caso es que las direcciones no están codificadas en el habitual formato binario de 32 bits sino como caracteres ASCII. Esto plantea problemas cuando el número de caracteres de la dirección vieja y la nueva no coinicide. Cuando la nueva dirección es menor, por ejemplo convertir de “200.200.200.1” (13 caracteres) a “192.168.1.1” (11 caracteres) el proceso de traducción puede optar por rellenar el campo con ceros (“192.168.001.1”) para mantener constante el número de octetos. Pero cuando la traducción se realiza en sentido inverso es preciso aumentar en dos octetos la longitud del segmento TCP correspondiente. Como consecuencia de ello el NAT a partir de ese momento ha de incrementar en dos octetos los contadores de bytes que aparecen en los campos número de secuencia y número de ACK para esa conexión TCP; esto supone que el NAT ha de mantener información de estado para esa conexión, mientras exista. Incluso podría darse el caso de que el aumento en dos octetos del segmento provocara la fragmentación del datagrama correspondiente.

 

·         En general cualquier protocolo del nivel de aplicación que incluya en la parte de datos información sobre direcciones IP o números de puerto TCP/UDP supone un reto para un dispositivo que hace NAT, ya que la detección y modificación de dichas direcciones requiere que el NAT analice y modifique información que se encuentra en la parte de datos del paquete IP, muchas veces perteneciente al nivel de aplicación. Algunos ejemplos de esto son el protocolo de la ITU-T H.323 utilizado en videoconferencia y en telefonía por Internet (voz sobre IP); también se encuentran en este caso los juegos interactivos de Internet, las aplicaciones tipo Napster, etc. Normalmente el funcionamiento de estas aplicaciones a través de un NAT sólo se consigue cuando el NAT está especialmente preparado para ello.

 

·         La comunicación de aplicaciones NetBIOS sobre TCP/IP tiene problemas parecidos a las aplicaciones del apartado anterior: la información sobre direcciones IP aparece de forma no consistente y con desplazamientos variables en la información intercambiada por los hosts, lo cual hace difícil que los NAT las modifiquen; como consecuencia de ello no es posible utilizar TCP para transportar NetBIOS cuando se atraviesa un NAT.

 

·         IPSec solo puede utilizarse de forma limitada a través de un NAT. Esto se debe a que IPSec incorpora una cabecera de autentificación (AH, Autentification Header) que permite al receptor detectar si el paquete IP ha sido modificado en ruta. Evidentemente la cabecera AH no incluye el campo TTL ni el checksum, ya que se sabe que estos campos cambian de valor durante el camino de un datagrama, pero si incluyen las direcciones IP de origen y destino. Como estas direcciones se modifican en el NAT el receptor cuando comprueba la cabecera AH detecta que el datagrama ha sido alterado y lo descarta. Cuando se hace NAT sólo es posible utilizar IPSec en modo túnel y sólo si el túnel se realiza en el mismo dispositivo que hace el NAT, o después. En estos casos la cabecera AH se calcula después de haber realizado el cambio de direcciones.

 

A pesar de todas las limitaciones reseñadas NAT resulta un mecanismo muy útil en un amplio abanico de situaciones, por lo que es seguro que se seguirá utilizando NAT en Internet durante bastantes años, al menos hasta que se generalice el uso de IPv6. Con ese nuevo protocolo y su abundante espacio de direcciones parece difícil concebir un escenario en el que tenga sentido utilizar NAT.

 

Los aspectos más relevantes de NAT se discuten en los RFC 1631 y 2663.

10.6EJERCICIOS

 

 

1.       Indique si es verdadera o falsa cada una de las siguientes afirmaciones:

 

 

a)       Para transmitir simultáneamente paquetes de mas de un protocolo a nivel de red (p. ej. IP e IPX) por un circuito ATM se emplea normalmente encapsulado IEEE 802.2.

 

b)       La principal finalidad de un cortafuego o firewall es conectar una red local con el exterior de forma que múltiples usuarios puedan compartir una misma dirección IP.

 

c)       La técnica denominada 'buques en la noche' (ships in the night, SIN) requiere el uso de un protocolo de routing distinto para cada protocolo soportado.

 

d)       El encapsulado es una técnica que permite aumentar la proporción de información útil (datos) que se envía por una línea determinada.

 

 

2.       Una empresa posee dos oficinas, en cada una de las cuales hay instalada una red local. En cada red local funcionan diversos protocolos. Se quiere unir ambas oficinas, estimándose en 128 Kb/s el ancho de banda necesario. La empresa puede disponer de enlaces a 64 Kb/s a un precio especialmente bajo, por lo que utilizará dos de estas líneas. En cuanto a los equipos a utilizar se plantean cuatro alternativas:

 

a)       Cuatro puentes transparentes sin spanning tree

b)       Cuatro puentes transparentes con spanning tree

c)       Cuatro routers multiprotocolo con routing estático

d)       Cuatro routers multiprotocolo con routing dinámico

 

En todos los casos los equipos tienen una interfaz serie (para conectar a la línea de 64 Kb/s) y una interfaz ethernet.

 

Serían válidas las cuatro? Discuta las ventajas e inconvenientes de cada una.

 

10.7SOLUCIONES

 

 

S1.-

 

 

a)       Verdadera.

 

b)       Falsa. La principal finalidad es proteger la red de ataques externos.

 

c)       Verdadera. El nombre pretende reflejar precisamente el hecho de que los paquetes originados por cada protocolo de routing viajan por la misma red física sin verse mutuamente, y normalmente sin interferirse unos con otros.

 

d)       Falsa. El encapsulado, al añadir mas información de control, reduce en la práctica la proporción de información útil que se envía por la línea.

 

 

S2.-

 

a)       Puentes transparentes sin spanning tree: solo se podrá utilizar una línea, teniendo que dejar la otra desconectada ya que de lo contrario se producirán bucles que bloquearían la red. La pareja de puentes no utilizada se podría tener preparada para conectar manualmente la segunda línea en caso de avería en la primera conexión.

 

b)       Puentes transparentes con spanning tree: se podrán conectar las dos líneas y los cuatro equipos, pero de forma automática se desactivará uno de los caminos. El spanning tree permitirá que la segunda línea entre en funcionamiento de forma automática en caso de problemas.

 

c)       Routers multiprotocolo con routing estático: al disponer de dos routers en cada lado se podría repartir el rango de direcciones en dos subredes de forma que cada subred se encamine por una línea distinta. Esto permitiría repartir el tráfico entre las dos líneas de forma estática, cosa que nunca es óptima pero al menos aprovecha las dos líneas en alguna medida. En caso de avería en una de las líneas las subredes correspondientes quedarían aisladas entretanto no se hiciera una reconfiguración manual de los equipos.

 

d)       Routers multiprotocolo con routing dinámico: en este caso el protocolo de routing efectuará un reparto óptimo del tráfico entre las dos líneas; además en caso de avería de una de las líneas el tráfico será reencaminado automáticamente por la línea disponible.

 

Dado que se requiere disponer de 128 Kb/s entre las oficinas las únicas soluciones válidas serían la c) y la d), siendo esta última la mas robusta y la que presenta mejor aprovechamiento de la infraestructura.