Aunque la mayoría de las aplicaciones son independientes de esta capa al utilizar protocolos IP, hay excepciones, por ejemplo muchos juegos operan sobre layer2. Lo mismo ocurre con mecanismos que utilizan posibilidad de broadcast de las redes ethernet.

Tanto en una red Ethernet como en una Wifi, cada tarjeta tiene una dirección que es única, la dirección MAC (es como un número de serie que no se repite, cada fabricante tiene asignado un rango de direcciones MAC para evitar que se repitan). Son 48 bits, o lo que es lo mismo, 12 caracteres hexadecimales. Suelen representarse así: 00:09:6C:EF:E4:69.

Las direcciones MAC al ser únicas en principio se pueden usar para filtrar paquetes en un cortafuegos o para restringir el acceso en un Access Point Wifi. Error. Lo más probable es que nuestra tarjeta nos permita cambiar la dirección ARP con un simple ifconfig eth0 hw ether 00:09:6c:EF:e4:69. Este cambio es temporal, dura hasta que lo volvamos a cambiar o reiniciemos la máquina. Además en muchas tarjetas se puede hacer el cambio permanente, pues la dirección MAC se escribe en una memoria flash dentro de la tarjeta. En este caso la herramienta a utilizar se llama ethertool y la opción que cambia la MAC es phyad.

El hardware de las tarjetas de red y de los hubs no sabe nada de direcciones IP, lo único que entiende es el formato de los paquetes ethernet, con sus direcciones MAC.

Es un error pensar que las tramas Ethernet se generan en el hardware o en el sistema operativo sin posibilidad de manipulación. En GNU/Linux mediante los sockets RAW es posible escribir tramas Ethernet. Así mismo mediante TUN/TAP tanto en GNU/Linux como en la mayoría de los sistemas operativos es posible leer/escribir por medio de un dispositivo tanto tramas ethernet como paquetes IP. Si en nuestra red existe un túnel (por ejemplo para hacer una VPN) es posible generar paquetes Ethernet en un equipo remoto, enviarlos vía Internet y que un nodo en la red local los emita como si hubieran sido generados localmente.

En una red Ethernet para unir los distintos equipos se usa un hub o un switch. Un hub opera a nivel físico y es muy primitivo: no deja de ser el equivalente en conectores de red a un "ladrón" en clavijas para enchufes. También se le compara con un repetidor. El problema de los hubs es que este modelo es poco escalable cuando existen muchos equipos en una red (especialmente si se enlazan varias redes locales físicamente para no usar enrutadores, simplificando la configuración de la red y que funcionen servicios que usan broadcast a nivel Ethernet como DHCPD (en realidad también se puede tener un único servidor para varias subredes no conectadas a nivel de enlace de datos si se usa un bootp/DHCPD agent relay), o esté disponible funcionalidad como wake-on-lan o servicios de autoconfiguración PnP). Un hub es poco escalable porque lo que se hace es transmitir para cada nodo todos los paquetes.

La alternativa a los hub son los switchs. La diferencia entre un hub y un swtich es que el segundo analiza las tramas ethernet que pasan por él; si ve que un paquete ha entrado por un puerto (cada conector para un cable de red es un puerto) registra la dirección MAC de origen junto con el puerto en una tabla llamada CAM, de modo que si llega un paquete para esa dirección no lo envía por todos los puertos sino sólo por ese. Hoy en día si vamos a una tienda a comprar un hub, lo normal es que ya no lo tengan y sólo vendan switchs.

En una red local Ethernet pueden coexistir paquetes de distintos protocolos, por ejemplo tráfico IP y tráfico AppleTalk. También es posible que sobre una misma red Ethernet haya más de una subred IP: si los rangos no se solapan tampoco habrá problemas.

Sobre la capa física va la capa IP; en realidad pueden ir otro tipo de capas de protocolos distintos a IP, como IPX, el protocolo de Netware, pero nos centraremos sólo en los paquetes IP que son los que se usan en la casi totalidad de las redes locales de hoy en día además de por supuesto en Internet.

Un paquete IP se llama datagrama. La información más importante que incluye un datagrama es la IP de origen y la IP destino.

Las direcciones IP a diferencia de las MAC están pensadas para ser enrutables, es decir, hay unos nodos enrutadores que examinan la dirección destino y deciden por qué camino siguen los paquetes. Gracias a que las direcciones IP se asignan por grupos a las distintas organizaciones y proveedores de Internet es factible establecer rutas. Esto con las direcciones MAC sería imposible: como vienen a equivaler a números de serie del hardware son inútiles para enrutar: puedo tener dos equipos juntos con MACs que no tienen nada que ver porque son de fabricantes distintos o uno tiene años más que el otro: quizás el nodo con la siguiente MAC a la nuestra se vendió en una ciudad de Japón.

Hay rangos de direcciones IP que están reservados para uso privado dentro de una organización. Por ejemplo todas las direcciones que empiezan por 192.168.. En las empresas, o en los hogares cuando se tienen varios ordenadores en casa y se quiere compartir la ADSL, lo habitual es usar direcciones de este tipo (privadas) en lugar de direcciones IP públicas. Las direcciones privadas no son enrutables fuera del ámbito en que se usan, por lo que no son utilizables para conectarse fuera de la red local. Por ejemplo no podemos conectarnos vía mensajería instantánea a un usuario de Internet utilizando la IP 192.168.120.7, porque los paquetes de respuesta no nos llegarían, dado que esa IP no es pública y no es pública porque puede haber mucha gente que la está usando en su red local. La solución está en el uso del NAT (Network Address Translator). El enrutador de salida a Internet de nuestra red modifica el paquete IP para que use como dirección IP origen la IP pública que tiene asignada la empresa y guarda en una tabla información para saber

Siempre que hay enrutado y esto incluye casos especiales como tener una VPN en un nodo, hay que activar el forwarding. Para ello hay que ejecutar echo 1 > /proc/sys/net/ipv4/ip_forward. El forwarding consiste simplemente en que si un paquete viene por una interfaz de red (por ejemplo eth0) y se ve por la tabla de rutas que está destinado a la red de otra interfaz (por ejemplo la eth1) se traspasa a esa otra interfaz. También es posible activar el fordwarding para unas interfaces de red sí y para otras no, por ejemplo para eth0 sería /proc/sys/net/ipv4/conf/eth0/forwarding.

Hay una parte de la dirección que indica el nodo dentro de la red pero otra indica la red. Los enrutadores tienen rutas para saber por dónde tienen que encaminar los paquetes según la parte de red destino, con una ruta por defecto para los paquetes que no encajan en ninguna de las otras rutas. Los enrutadores sólo suelen tener en cuenta la dirección destino, no la dirección origen, pero en GNU/Linux hay herramientas avanzadas que permiten considerar también la dirección origen.

Sobre los datagramas IP va la capa de transporte. Aquí hay distintos tipos de protocolos, los más famosos son los TCP (que usan casi todas las aplicaciones) los UDP (que se usan para el DNS y para aplicaciones como streaming de vídeo o para construir VPNs).

Hay más tipos de contenidos que UDP y TCP: así, los ICMP son paquetes de control, por ejemplo son los paquetes que se reciben cuando se recibe un error de que no se ha podido establecer una conexión a un puerto o que no hay ruta para llegar a una red. Son también los paquetes que se envían y reciben al hacer un ping para comprobar si llegamos a una red. De los paquetes ICMP sólo nos interesa saber que llevan un campo con el tipo de mensaje, que será el campo por el que filtraremos o dejaremos pasar este tipo de mensajes en nuestro cortafuegos. Con iptables -p icmp -h se ven los tipos de paquetes ICMP

Los paquetes IGMP son paquetes de control para multicast (multidifusión). El origen del modo multicast es que hay comunicaciones en las que los mismos paquetes son de interés de varios nodos destino en lugar de uno solo; el ejemplo más socorrido es una emisión de vídeo. Si se transmite una película usando unicast (el modo normal de comunicación IP) entonces se transmitirá un paquete por cada destinatario, mientras que con multicast en los tramos comunes a todos los destinatarios irá un solo paquete. El multicast se basa en rangos de Ips reservados para este fin, pero no hablaremos más de él porque se usa muy raramente. No hay que confudir multicast con broadcast: este último es enviar a todos los nodos de la red, el multicast es más restringido.

Otros tipos de paquetes de los que no vamos a hablar pero que van directamente sobre la capa IP son distintos protocolos de encaminamiento (para pasarse entre los routers información dinámicamente sobre las rutas que deben seguir los paquetes).

Nos centraremos pues en la distinción entre UDP y TCP. TCP es un protocolo orientado a la conexión. Esto quiere decir que con TCP todos los paquetes que pertenecen a una conexión se numeran (el número de secuencia inicial se genera aleatoriamente para dificultar ataques de seguridad de falsificar una conexión) y se garantiza que llegan todos a destino y en el orden en que se enviaron. Al comienzo de la conexión, el primer paquete TCP lleva un flaq indicando que se quiere establecer una conexión. El protocolo TCP incluye mecanismos para confirmar la recepción de los paquetes (los paquetes que no se confirmen que se han recibido hay que volverlos a enviar) así como mecanismos de control de congestión (detectar que se están enviando más paquetes de los que permite el ancho de banda de la conexión y en ese caso bajar el ritmo).

UDP en cambio es un protocolo sin conexión. Cada paquete es independiente de los demás. No hay ninguna garantía de que el programa llegue a su destino, ya sea porque hay errores o porque la red está saturada: si estamos saturando la red y por eso no llegan los paquetes nos tendremos que dar cuenta nosotros y tomar las medidas oportunas (bajar el ritmo de envío). Así mismo no hay garantía que los paquetes que lleguen lo hagan en el mismo orden en que se enviaron, dado que los paquetes IP pueden ir por rutas distintas.

¿Qué aporta entonces la capa de transporte UDP sobre lo que proporciona la capa de red IP? ¿por qué no enviar los datos directamente como datagramas IP en lugar de como paquetes UDP? El gran aporte de UDP, que también forma parte de TCP, es que además de incluir IP de origen y destino, incluye puerto origen y destino. El puerto destino es útil para poder ejecutar varios servicios en la misma máquina: por ejemplo en el puerto 80 puede estar el servidor web y en el 25 el servidor de correo. Podemos ver al puerto destino como una extensión y a la IP como un teléfono. El puerto origen también es muy útil: cuando el cliente envía un paquete elige un puerto origen libre y gracias a este puerto el servidor puede distinguir, a la hora de responder, entre dos conexiones procedentes de la misma IP.

Por lo que hemos visto, TCP garantiza fiabilidad en la conexión mientras que con UDP si se quiere enviar una secuencia de paquetes todo se complica todo y además no hay garantía de que no se pierdan los paquetes. ¿Qué sentido tiene usar entonces UDP? Para la mayoría de los protocolos de aplicación, ninguno: la mayoría requieren un canal de transporte orientado a la comunicación (que dicho sea de paso, podría ser TCP o cualquier otro actual como sockets UNIX o que se cree en el futuro, el API de programación de Unix es independiente del protocolo concreto que esté por debajo). Hay casos, sin embargo, en que UDP es útil:

Finalmente la última capa es el protocolo de aplicación, por ejemplo HTTP (web), SMTP (correo) o XMPP (Jabber). En Unix estos protocolos se escriben utilizando sockets, que se utilizan (sobre todo cuando la capa de transporte es TCP) prácticamente igual que los ficheros.

Dado que con los sniffers es posible espiar el tráfico de red, un mecanismo de seguridad muy utilizado en las aplicaciones es añadir una capa intermedia en la capa de aplicación sobre la que realmente va el protocolo: esta subcapa lo que hace es cifrar los paquetes y añadirles información de control para detectar si alguien los intenta manipular. El protocolo más estándar par implementar esta funcionalidad es TLS (anteriormente conocido como SSL).

Ojo, puede parecer que un switchs elimina la posibilidad de que un nodo en una red local espíe las comunicaciones entre otros nodos, utilizando un sniffer. Al fin y al cabo con un hub todo el tráfico se reenviaba a todos los nodos y el nodo en escucha realiza una actividad totalmente pasiva e indetectable, pero con un swtich se supone que cada nodo sólo recibe los paquetes que van destinados a él. Lamentablemente no es así, existen sniffers como http://ettercap.sourceforge.net/ que funcionan también con switchs. Así mismo hay sniffers especializados como oreka.sf.net, que sirven para grabar VoIP, generando un fichero de audio.

El problema es el ARP Spoofing/Port Stealing y ARP Poisoning. El ARP poisoning consiste en enviar al nodo que queremos engañar una respuesta ARP en el que indicamos que nuestra dirección MAC es la correspondiente a la dirección IP del nodo que queremos suplantar. La mayoría de los sistemas operativos no ven nada extraño en que les llegue este paquete aunque no lo hayan solicitado y lo almacenan en su caché ARP y en los que no se puede trucar con un ping. El ARP posioning actúa falsificando la IP no la dirección ARP, por lo que es difícil de detectar y evitar por parte del switch. Otras técnicas (Port Stealing) explotan engañar al switch haciéndole creer que tenemos la dirección ARP de la máquina a suplantar (los swtich que no soporten Safe Port, es decir, que permitan que cambie el puerto asociado a una dirección MAC). Así mismo hay ataques que buscan saturar con entradas falsas la tabla CAM del switch, pues necesariamente esta tabla tiene capacidad limitada.

La buena noticia es que estos ataques ya no son pasivos sino activos y son detectables con herramientas apropiadas como arpwatch (que hace escucha pasiva) o el propio ettercap. Más información: http://en.wikipedia.org/wiki/ARP_spoofing

Si necesitamos un sniffer para hacer comprobaciones de red o aprender sobre protocolos, el sniffer recomendado es Ehtereal, que ha cambiado de nombre recientemente a whireshark.

Hay más herramientas útiles para depurar problemas en las redes, además de los sniffers. Por ejemplo iftop (http://www.ex-parrot.com/pdw/iftop/ ): muestra consumo de ancho de banda, al estilo de top, mostrando origen y destino de la conexión. Utiliza libpcap (como sniffer) por lo que al ponerlo en la máquina que hace de router podemos ver quién está consumiendo en ese momento más ancho de banda.

Una herramienta extremadamente útil para depurar problemas de red y aprender sobre redes es Netcat. Esta utilidad permite conectarse a cualquier socket TCP/UDP y enviar/recibir datos como si estuviéramos escribiendo en un terminal. De igual modo puede escuchar en un puerto TCP/UDP. Es muy útil por ejemplo para probar antes de montar una VPN si hay visibilidad entre las Ips y puertos: escuchamos con netcat en un lado y desde el otro enviamos. Así, para escuchar tráfico UDP en el puerto 9037 (opcionalmente con -s se podría indicar una IP, en el caso de ser un puesto multihome, con más de una interfaz de red): netcat -u -l -p 9037. Para enviar tráfico a el puerto 9037 desde otra máquina: netcat -u 83.59.36.220 9037

Se recomienda usar tambíen un IDS (sistema detector de intrusiones). El más conocido es snort (http://www.snort.org/), aunque es programa es polémico debido a que las nuevas reglas para detectar intrusiones ya no son libres, aunque sí gratuitas pero distribuidas con varios días de retraso para los clientes no de pago.

Para redes wireless hay programas como kissmet (http://kismetwireless.net/) que actúa de forma pasiva y no es detectable, airsnort (http://airsnort.shmoo.com/) y swscanner (http://www.swscanner.org/)

Los enrutadores tienen más de una dirección IP, dado que tienen una IP en cada interfaz de red que enrutan. Ahora bien, cuando una máquina que tiene varias direcciones IP se comunica con otra máquina ¿qué IP origen figura en los paquetes? la IP de la interfaz de red por la que saldrá el paquete.

Esto puede ser problemático en algunos casos. Por ejemplo en nuestra configuración, en la interfaz eth1 que conecta nuestra red con la red de otra empresa. Resulta que los equipos de la red de la otra empresa no saben cómo llegar a 192.168.200.86: los equipos de ambas redes conocen las Ips 192.168.120.0 y 10.0.0.0, pero no conocen la red 192.168.200.84/30, que es un artificio para comunicar los dos enrutadores. Así pues, cualquier paquete que proceda de nuestro enrutador y vaya a una dirección de la red 10.0.0.0 llevará como IP origen 192.168.200.86, por lo que podrá llegar a destino pero luego no llegarán los paquetes respuesta. Podemos hacer una prueba muy sencilla: un simple ping a una máquina de la red 10.0.0.0 y veremos que la IP origen es 192.168.20.86 y no nos llega la respuesta, mientras que desde otra IP de la red sí.

La solución pasa por utilizar como IP origen 192.168.120.19 también cuando los paquetes vayan a la red 10.0.0.0 y no sólo cuando vayan a la red local. Ante esto caben dos enfoques:

¿Qué solución es más apropiada? Depende. La segunda obviamente es más directa, pues no hay que cambiar programa a programa. Ahora bien, por seguridad desde el enrutador no se debería acceder a más equipos de la otra red que los imprescindibles, por ejemplo los servidores DNS. Obligarse a reconfigurar cada programa que hay lo necesita es obligarse a mantener controlado a qué servicios de la otra red estamos accediendo desde el router.

Para conectarse desde casa o desde otra ubicación a la red del trabajo, hay distintas alternativas:

Supongamos que queremos conectarnos desde casa con el puerto 8080 en la máquina 192.168.1.100 de la red local de nuestra empresa. Para ello contamos con una máquina SSH que está dentro de la red local de la empresa y a la que llegamos a través de un DNAT que hemos hecho en el cortafuegos. En este caso hemos abierto el puerto 34321 del cortafuegos, que tiene la IP pública 87.15.10.120: los paquetes con este destino cambiarán de 87.15.10.120 a 192.168.1.1:22. Así pues, cuando nos conectemos vía ssh a 87.15.10.120:34321, llegamos en realidad al puerto SSH de 192.168.1.1.

La solución está en utilizar la posibilidad que ofrece SSH de crear túneles. SSH es un protocolo que no sólo encripta y garantiza la integridad de los datos, sino que es capaz de encapsular cuantas conexiones necesitemos en una sola. Así, nuestro propósito es que SSH cree un servidor local en nuestra máquina, por ejemplo con el puerto 8081, recoga todo lo que escribamos en él, lo envíe encriptado hasta la máquina 192.168.1.1 (la máquina remota a la que nos hemos conectado vía SSH) y desde allí los desencripte y los envíe al puerto 8080 de la máquina 192.168.1.100; los paquetes de respuesta seguirán el proceso inverso, hasta llegar al puerto 8081 local de nuestra máquina. Observesé que en el caso del túnel los paquetes pasan por la capa de aplicación, mientras que en el NAT simplemente se modifican las cabeceras a nivel IP y TCP para hacer el NAT. La máquina 192.168.1.100 no verá como IP origen de los paquetes a la IP de nuestra casa, sino a 192.168.1.1, la máquina SSH que ha retransmitido el paquete.

En la práctica, hacer el túnel es tan sencillo como:

ssh -N 801020.13 -p 34231 -o ServerAliveInterval 1200 -L8081:192.168.1.100:8080

La opción -N es para crear el túnel pero no iniciar una shell. La opción ServerAliveInterval es para enviar cada 2 minutos un paquete en caso de que la conexión esté inactiva, para evitar que el cortafuegos asuma que la conexión esté muerta y olvide la asociación NAT. Es posible añadir más opciones interesantes. Por ejemplo por defecto el puerto 8081 que ha creado ssh es sólo accesible dentro de nuestra máquina, si quisiéramos que pudieran conectarse a él otras máquinas de nuestra red local, añadiremos la opción -g.

Es posible también crear túneles en los que el puerto servidor se abre en la IP a la que nos conectamos remotamente (en este caso 192.168.1.1) y que se enviara a una IP y puerto de nuestra red local. Esto nos permite crear servidores en la red local de nuestra empresa (para que el puerto sea accesible desde todas las Ips de la red local de la empresa y no sólo desde 192.168.1.1, habrá que usar la opción -g).

Así, si queremos crear el puerto 8087 en 192.168.1.1 y que todo lo que se reciba allí vaya al puerto 9000 de la IP 192.168.7.3 (en nuestra red local de casa) usaríamos:

ssh -N 801020.13 -p 34231 -o ServerAliveInterval 1200 -g -R192.168.1.1:8087:192.168.7.3:9000

Como puede verse, los túneles SSH son muy potentes y un tanto inquietantes desde el punto de vista de la seguridad para un administrador: podemos hacer un túnel para usar el escritorio remoto, para conectarnos a la web de la empresa, para enviar correos desde casa utilizando el servidor SMTP de la empresa, e incluso para ejecutar una aplicación en local que usa una BB.DD. de la red, cambiando la configuración para que use un puerto en nuestra máquina local y usando un túnel. Es más, es posible crear toda una VPN como veremos más adelante, con sólo la posibilidad de crear túneles de SSH.

Por este motivo el administrador de SSH puede desactivar el uso de túneles o especificar exactamente qué túneles se pueden usar, así como permitir o denegar obtener una shell o permitir ejecutar sólo un comando en concreto. Puede así mismo no permitir el acceso al sistema no dándole una contraseña y autenticando por clave pública: el propio fichero de clave pública almacenado en el servidor tendrá las restricciones que se aplican cuando se accede con esa clave, pudiéndose tener distintas claves para un mismo usuario según se le permita ejecutar una tarea u otra.

La funcionalidad de SSH no acaba aquí. Es posible que un usuario se conecte a una máquina y desde ahí a otras. Si utiliza claves públicas para autenticarse, SSH incorpora un sistema, el ssh-agent, que permite autenticar al usuario estando conectado en otra máquina y sin que nuestra clave privada salga de nuestra máquina.

Para usuarios con Windows, en lugar de utilizar el cliente en línea de comandos pueden recurrir a Putty, un programa con interfaz de usuario basada en ventanas y que en realidad también se puede ejecutar en GNU/Linux.

VPN es el acrónimo en inglés de red privada virtual. El objetivo es lograr, mediante la creación de un túnel IP encriptado sobre una red pública como Internet, que los nodos a conectar por la VPN virtualmente estén en una misma red local. Es posible establecer una VPN directamente entre dos nodos, pero lo más habitual es o bien una VPN entre un nodo remoto y la red local de la empresa (esta configuración en inglés se llama con frecuencia road warrior, guerrero de la carretera, hace mención a que un usuario móvil se conecta a la empresa con su portátil y una conexión a Internet desde allí dónde está desplazado) o una VPN que une dos redes, por ejemplo dos filiales de una empresa o una filial con la central.

Hay distintas tecnologías y productos para crear una VPN con implementaciones libres para GNU/LInux:

Hay implementaciones de IPSec para cualquier sistema Unix, MacOS X, Windows XP/2000... Una implementación de IPSec consta de dos partes: la implementación sobre la pila de protocolos TCP/IP, en el kérnel y el demonio y herramientas que se ejecutan en el espacio de usuario para establecer las claves (esto es la parte IKE: Internet Key Exchange). En principio es posible utilizar la parte IKE de una implementación sobre la pila de protocolos de otra. Así, la implementación integrada en el kernel Linux (llamada NETKEY) no incluye herramientas IKE, por lo que hay que usar las de otra implementación: habitualmente se usa la implementación del proyecto Kame (surgido de un consorcio de empresas japonesas como Fujitsu y Toshiba para hacer una implementacion de Ipv6 e Ipsec), que es la implementación usada en Free/NetBSD y en MacOS X; el demonio IKE de Kame se llama Racoon y el conjunto de utilidades portadas para Linux que además de Racoon incluye otras como setkey es ipsec-tools (http://ipsec-tools.sf.net); en Ubuntu Dapper se incluyen los paquetes ipsec-tools y Racoon (se ha sacado en un paquete aparte el demonio porque es posible también usar IPSec sin demonio, utilizando claves precompartidas).

También se puede usar por ejemplo como demonio IKE isakmpd (de la implementación de OpenBSD) o Pluto. Pluto es el demonio IKE de la antigua implementación de IPsec para Linux, FreeSWAN, que nunca llegó a formar parte del kernel; FreeSWAN dejó de desarrollarse pero tomaron el relevo dos proyectos: OpenSWAN (www.openswan.org) y StrongSWAN (www.strongswan.org). Mientras que OpenSWAN sigue desarrollando la pila de protocolos KLIPS como alternativa a la integrada en el kernel, NETKEY, en StrongSWAN no. StrongSWAN es compatible no sólo con IKE1 sino con IKE2: de la compatibilidad con IKE1 se encarga el viejo demonio Pluto, mientras que para IKE2 hay un nuevo demonio llamado Charon. La flexibilidad de programas como StrongSWAN o OpenSWAN son inmensas: incluyendo toda una infraestructura de clave pública basada en certificados X.509, con la posibilidad de utilizar dispositivos como smartcards y teniendo en cuenta aspectos como que los certificados pueden revocarse y ya no ser válidos, que pueden obtenerse de servidores LDAP...

Para usar IPSec hay que abrir en los cortafuegos el puerto 200 UDP, pues lo usa IKE. También hay que tener en cuenta que los paquetes tienen un número de protocolo distinto al IP, por lo que también podría haber problemas en el cortafuegos.

El lado negativo de IPSec es que es una solución muy compleja. Al margen que esa complejidad podrá afectar más o menos al usuario según los asistentes para configurar una VPN (el problema está en que todo se complica más si los sistemas operativos de los nodos a conectar son distintos, frente a la sencillez de usar una implementación de VPN más simple que tenga versión para distintos sistemas operativos) desde el punto de vista de la seguridad son preferibles las soluciones sencillas. Hay gente que no le gusta tampoco de IPsec frente a otras soluciones que se ejecute mucho código en el espacio del kernel (por ejemplo la parte de encriptación, que en el caso de OpenVPN se ejecuta en el espacio de usuario) dado que un error de seguridad ahí es fatal al comprometer todo el sistema, si bien tiene un impacto positivo en el rendimiento. Esta objeción es opinable: es cierto, pero también la información sensible está más protegida a nivel del kernel.

¿Qué inconvenientes tiene usar OpenSSH + PPPD? el principal inconveniente es que no es buena idea implementar el túnel de una VPN sobre TCP, es mejor utilizar UDP. El motivo es porque TPC tiene mecanismos de control de congestión que no funcionan de la mejor forma cuando una conexión TCP a su vez se encapsula sobre una conexión TCP: se produce un efecto multiplicativo que hace que ante una congestión se reduzca la velocidad enormemente y que tarde mucho en coger de nuevo velocidad. Hay una explicación de este fenómeno en http://sites.inka.de/sites/bigred/devel/tcp-tcp.html. Otro argumento para usar UDP es que podemos tener aplicaciones UDP que usan este protocolo por la necesidad de que los paquetes lleguen siempre a tiempo, sin importar si se pierde alguno: como se usa TCP, los paquetes nunca se descartan y se gasta tiempo en retransmisiones.

Paradójicamente, hay casos en los que usar un túnel TCP sí puede tener alguna ventaja sobre un túnel UDP. Si un protocolo UDP está mal diseñado frente a un ataque que selectivamente hace que determinados paquetes se pierdan, el que vaya sobre TCP sería una ventaja puesto que entonces TCP nos garantiza que ningún paquete se pierda ni llegue fuera de orden.

Otro inconveniente es que PPPD requiere privilegios de superusuario, aunque se pueden hacer cambios en la configuración para que no sea necesario, atendiendo a que el programa se ejecuta con el bit setuid. Crear un dispositivo TUN/TAP también requiere privilegios, pero es distinto, porque una vez creado con un programa, se puede hacer que esté disponible para otros programas lanzados sin privilegios.

El hecho de usar protocolos conocidos y una librería muy probada como OpenSSL da mucha fiabilidad a este programa: es relativamente fácil fallar estrepitosamente a la hora de tratar de crear un nuevo sistema de VPN, como revela este interesante escrito de Peter Gutmann (el autor de cryptolib y la impresionante presentación/tutorial de criptografía de más de 800 transparencias)

que habla de CIPE, VTUN y TINC: http://www.cs.auckland.ac.nz/~pgut001/pubs/linux_vpn.txt. Del mismo autor, un artículo más elaborado sobre el tema: http://www.linux-magazine.com/issue/39/VPN_Insecurity.pdf

OpenVPN consta de un único ejecutable (para ambos extremos es el mismo) y un fichero opcional de configuración, además de los ficheros de claves.

Uno de los puntos fuertes es que es multiplataforma: el poder usar exactamente el mismo programa en GNU/Linux, cualquier BSD, Solaris, Mac OS X o Windows XP/2000 supone hacer una VPN en la que intervengan equipos con cualquier sistema operativo sin problemas de interoperabilidad.

OpenVPN permite hacer túneles a nivel de la capa 3 (la opción por defecto y la recomendada, se usa un dispositivo TUN) o a nivel de la capa 2 (usando un dispositivo TAP). Si usamos la capa 2, podemos utilizar un puente. Sólo tiene sentido usar la capa 2 para transferir tráfico no IP o cuando necesitemos la funcionalidad de un puente.

Una funcionalidad interesante de OpenVPN desde su versión 2.0 es crear un único servidor al que pueden conectarse distintos clientes, para crear cada uno su propia red privada virtual con la red local en la que está el servidor.

El sistema X-Window desde sus orígenes se diseñó con vistas a la transparencia de red: una aplicación se visualiza y maneja desde un terminal, pero puede estar ejecutándose en cualquier máquina de la red con la que haya conexión TCP/IP. En la terminología X-Window, el PC del usuario ejecuta el servidor X, mientras que las aplicaciones son los clientes: la idea es que las aplicaciones hacen peticiones al servidor del tipo dibuja este mapa de bits o notificamé determinados eventos. El servidor notifica a los clientes eventos como pulsaciones de teclas o eventos del ratón.

Para ejecutar una aplicación desde una máquina remota a la que nos hemos conectado por ejemplo a través de un telnet o un ssh, lo primero que hace falta es que esté definida la variable DISPLAY, que indica el servidor a utilizar. Así, un valor :0 indica usar el servidor local (si hubiera más de uno, se incrementaría el número); con el valor 192.168.7.10:0, indicaríamos que conecte con el servidor X de la máquina 192.168.7.10.

El siguiente requisito, es que si la conexión es vía red, tiene que estar abierto en el cortafuegos el puerto TCP del servidor X. Este puerto por defecto es 6000 para el primer servidor (:0) y se va incrementando conforme se ejecutan más servidores sobre una misma máquina.

Finalmente, el servidor X tiene que permitir que el cliente se conecte. Hay dos formas:

Mediante la herramienta xauth, podemos leer la cookie en el servidor X; luego también mediante la herramienta xauth, en la máquina remota, podemos añadir la cookie.

En realidad, el método recomendado para ejecutar aplicaciones remotas es conectarnos con ssh con la opción -X (si no añadimos además la opción -Y estamos sujetos a algunas restricciones de seguridad, a decir verdad no totalmente efectivas). Al ejecutar aplicaciones a través de SSH se usa para cada conexión un túnel encapsulado dentro de la conexión SSH, con todas las ventajas que implica: seguridad, al estar encriptado y protegido contra modificación y versatibilidad, pues no hay que abrir ningún puerto en el cortafuegos ni hay problema si nuestra máquina está tras una ADSL con NAT. La idea en que se basa es utilizar un proxy: crea un servidor X en la máquina remota y redirige todo lo que recibe por medio del túnel SSH al servidor X real que tenemos en nuestra máquina local. Gracias a este sistema funciona incluso aunque el servidor X se ejecute con la opción -nolisten tcp, pues la comunicación es local gracias al túnel.

Muchas veces la forma de ejecutar las aplicaciones remotas no es ejecutando aplicaciones sueltas, en nuestro escritorio local, sino ejecutando entero el escritorio remoto. Es decir, nos sale la pantalla de GDM o KDM que nos pide nuestro usuario y contraseña y a continuación entramos en un escritorio Gnome o KDE, pero que en realidad no es el de nuestra máquina, sino el de una máquina remota. Esta funcionalidad se apoya en el protocolo XDMCP, que por razones de seguridad suele estar desactivado (lo implementa el propio GDM/KDM). El protocolo usa el puerto UDP 177, pero sólo inicialmente; para mostrar la propia pantalla de Login ya recurre a la habitual conexión TCP con el puerto 6000, si bien automáticamente configura todo, incluyendo el fichero con la cookie, para que el usuario no tenga que hacer nada especial.

Hay servidores X libres disponibles también para Windows: recomendamos http://x.cygwin.com/.

VNC es un sistema que permite conectarse a un escritorio remoto. El servidor se ejecuta en el ordenador remoto a cuyo escritorio nos queremos conectar y el cliente en nuestra máquina. Toda la pantalla del escritorio se maneja dentro de una ventana, no es posible como con X-Window ejecutar cada aplicación en su ventana, como si fueran aplicaciones locales. Así mismo es un sistema mucho menos avanzado que X-Window, basado simplemente en un framebuffer, retransmitiendo los cuadros que cambian (en cambio en X-Window se almacena información en el servidor, de modo que no hay que retransmitirla cada vez que se muestra por pantalla: como muestra un botón: el protocolo baso X-Window, sin extensiones, tiene 160 tipos de peticiones, respuestas y eventos).

Si VNC es menos avanzado que X-Window, ¿por qué hay gente que usa VNC en lugar de X-Window?

VNC se ejecuta sobre una única conexión TCP, por lo que es muy fácil de securizar utilizando un túnel SSH, que es así mismo una solución interesante para permitir que los traajadores de una empresa puedan manejar en caso de necesidad su equipo de la oficina desde casa.

Muchas distribuciones incluyen una opción de permitir administrar remotamente el equipo (por ejemplo SuSE 10.2). Esta opción se implementa con VNC. También se implementa con VNC el "Apple Remote Desktop".

A veces en lugar de VNC leeremos RFB. Es el nombre del protocolo: Remote Frame Buffer.

Relación de software que implementa VNC: http://en.wikipedia.org/wiki/Vnc

Microsoft añadió soporte a su sistema operativo para poder ejecutar aplicaciones remotamente. En concreto lo implementó para Windows 2000 Server en el componente Windows Terminal Services, un sistema que permite al estilo Unix que varios usuarios estén conectados a la misma máquina. Evidemente para ello hay que pagar licencias, las de Windows 200x Server y la de Windows Terminal Services, esta última en función del número de clientes (una licencia por cliente que potencialemente se pueda conectar; fórmula menos ventajosa que licenciar por usuarios concurrentes y además propensa a abusos, pues la licencia cliente está incluida con algunas versiones de Windows, pero no con otros sistemas potencialmente clientes como GNU/Linux o Mac OSX). Como excepción, hay una licencia especial para usuarios que se conectan a través de Internet, que es la que se usa tienen en Hacienda para permitir que los usuarios de Linux y Windows hagan la declaración de la renta con el programa PADRE: la conexión es utilizando un cliente Cytrix (por Cytrix también se paga) pero a su vez Cytrix requiere Windows Terminal Services.

De todos modos por lo que es más conocido RDP es porque Windows XP Professional (no así Windows XP Home) incluye un servidor RDP limitado a una sola conexión y permitiendo una única sesión (es decir la máquina es monousario: o se usa en local o en remoto, pero no se puede tener a la vez una sesión local y otra remota). Lo mismo ocurre con las versiones más caras de Windows Vista (lo incluye a partir de Ultimate); también se incluye en Windows Media Center, Windows 2003 Server y Tablet Edition 2005. Es el famoso escritorio remoto, para el que existe un cliente libre también para GNU/Linux, rdesktop. con una interfaz gráfica muy intuitiva, tsclient. Teóricamente Microsoft podría cobrar también licencias por clientes

RDP ofrece mejor rendimiento que VNC. Sigue por detrás de X-Window, pero recordemos que X-Window tiene un problema práctico con el round-trip, que RDP. Hasta RDP 6, novedad en Windows Vista (también disponible al parecer para XP SP2) tenía la limitación de VNC: sólo permitía manejar el escritorio entero en una ventana, no una ventana por aplicación. El soporte para ejecutar aplicaciones cada una en su ventana (SeamlessRDP) lo permite excepcionalmente rdesktop con versiones más viejas de RDP utilizando un componente que se ejecuta en el servidor.

Otra ventaja común con VNC es que permite desconectar la sesión e iniciarla desde otra máquina dejando todo como estaba.

Añade alguna innovación como poder utilizar remotamente más dispositivos que el ratón, teclado y pantalla: por ejemplo la tarjeta de sonido o la impresora. Esto en Unix ha sido también siempre posible, a través del demonio de sonido y de impresión, la diferencia aquí es que todo se hace con un solo producto y en RDP 6 se han ido añadiendo más posibilidades.

RDP se ejecuta también sobre una conexión TCP, por lo que al igual que VNC es fácil de entular usando openssh o stunnel. En las últimas versiones permite encriptación usando TLS, mientras que el sistema de encriptación de las versiones viejas basado en usar RC4 no es seguro.

NX ( http://en.wikipedia.org/wiki/NX_technology ) es una tecnología de escritorio remoto desarrollada por una empresa Italiana, NoMachine. NoMachine comercializa su implementación propietaria de esta tecnología. Los clientes son freeware y hay también un servidor freeware, NX Free Edition, para GNU/Linux y Solaris, mientras que el servidor para Windows y MacOSX es de pago.

Lo más interesante es que Nomachine además publica el código fuente necesario para implementar esta tecnlogía bajo licencia GPL. Hay un proyecto que ha desarrollado un servidor a partir de este código fuente, el proyecto FreeNX (http://freenx.berlios.de). El código de FreeNX es bastante complicado de compilar: recomiendan usar la implementación que venga con la distribución. Es el caso de Open SuSE 10.2 y Ubuntu Dapper, pero versiones nuevas de Ubuntu se plantean no incluir FreeNX por lo difícil de manejar el código, auque quizás con las nuevas versiones lo reconsideren. FreeNX incluye el servidor, pero no un cliente. Como cliente mucha gente utiliza el freeware (pero privativo) de Nomachine. Otras opciones son ThinStation (http://thinstation.sourceforge.net/wiki/index.php/ThIndex), knx y sobre todo QtNX (http://blog.gwright.org.uk/articles/search?q=QtNX). QtNX actualmente requiere que para la parte del cliente estén instalados la versión 1.5 del componente (la versión vieja, con menos opciones que la nueva, por ejemplo poder ejecutar aplicaciones cada una en su ventana, modo rootless), pero funciona perfectamente con un servidor de la versión 2.0. Otra implementación completa de NX bajo GPL, al parecer obtenida tras comprar una licencia a NX: http://code.2x.com/linuxterminalserver/downloads. Esta solución es para NX 1.5, no para NX 2.0.

NX se implementa sobre X-Window para acelerarlo sensiblemente y eliminar round-trips. Así, gracias al uso de caché o el utilizar formatos tipo PNG en lugar de bitmaps se logran ratios de compresión del orden de 10:1 a 100:1. Gracias a estas compresiones es utilizable un escritorio remoto incluso a través de un modem.

En una serie de artículos sobre NX publicados en Linux Journal, se muestra como el inicio de sesión en KDE la primera vez supone transferencias de 4,1MB, pero gracias a NX y su caché las siguientes veces se queda en tan solo 35Kb.

NX aplica a X-Window mejoras que ofrece RDP, como el poder desconectar la sesión y conectarse desde otra máquina con todo como estaba (lo logra haciendo que el servidor X se ejecute en la máquina remota, mediante el agente nxagent, a la que se conecta el cliente NX) o el permitir transferencias de ficheros o utilizar por las aplicaciones remotas nuestra impresora o tarjeta de sonido local.

En realidad NX también se puede utilizar sobre RDP o VNC para acelerar también estos protocolos, pero los resultados que se obtienen son inferiores respecto a X-Window: como hemos comentado la tecnología de X-Window es superior a RDP, sólo que había problemas como los round-trips que en la práctica lo hacían poco utilizable sobre redes no locales.

Supongamos que la IP pública de nuestro proveedor es 81.10.20.15; que la salida a Internet es por eth2 y que queremos que todas las conexiones salgan a Internet con esta IP. En este caso ejecutaríamos:

iptables -t nat -A POSTROUTING -o eth2 -j SNAT --to-source 81.10.20.15

Si nuestra IP no es fija, en lugar de SNAT utilizamos MASQUERADE y no incluimos el parámetro --to-source.

Observesé que SNAT no se usa sólo para hacer NAT con la IP de la conexión a Internet. Otro caso típico es si tenemos una VPN: establecemos una red privada entre nuestra máquina y la de la empresa; para acceder al resto de máquinas de la empresa una posible solución es hacer en la máquina en la red de la empresa SNAT a su propia IP de los paquetes procedentes de la red virtual, de modo que los paquetes procedentes de nuestra casa parecerán que salen de la IP a la que nos hemos conectado en la red local.

La regla se añade a PREROUTING si el paquete procede de fuera, OUTPUT si el paquete se ha generado localmente.

Un uso típico de DNAT es abrir puertos en un cortafuegos y redirigirlos a Ips y puertos de la red local.

Otro uso típico es reemplazar un servidor por otro temporalmente, o incluso balancear entre varias Ips. En este último caso en lugar de DNAT usamos BALANCE y especificamos un rango de Ips.

El tercer uso corriente es hacer un proxy transparente. Ahora bien, mientras que hay protocolos en los que en la petición aparece de nuevo la IP o hostname más puerto (por ejemplo en HTTP aparece en la cabecera Host) esto no tiene por que ser así, de modo que el proxy no sabría nada sobre la IP y puerto destino. Por este motivo este caso de DNAT se hace con un target especial (REDIRECT) que sólo funciona sobre la propia máquina, porque así netfilter le pasa la IP y puerto destino a la aplicación a través del sistema operativo.

SQUID es un proxy que puede funcionar como proxy transparente. Es posible ejecutar SQUID en una máquina distinta que el enrutador, utilizando la tabla mangle de iptables para marcar los paquetes con destino a SQUID y utilizar la herramienta ip (del paquete iproute; este programa es necesario para realizar operaciones avanzadas que no se pueden hacer con otras herramientas como route, por ejemplo enrutar por IP de origen o por políticas. En este caso se usa una política que es que el paquete haya sido marcado desde netfilter, de modo que lo que hacemos es enrutar a la máquina de SQUID el tráfico que queremos que procese.

Hay diversas herramientas para monitorizar redes y dar información sobre el ancho de banda consumido. Estas aplicaciones normalmente funcionan como sniffers, poniendo la tarjeta en modo promiscuo y recompilando información a través de libpcap. La aplicación sin duda más recomendable es iptraf (http://iptraf.seul.org/). Tiene interfaz de consola, con ncurses. Una relación extensa de herramientas para monitorizar el consumo de ancho de banda está en http://www.ubuntugeek.com/bandwidth-monitoring-tools-for-linux.html.

La otra posibilidad es utilizar el propio netfilter. Cara al rendimiento tenemos la ventaja que se ejecuta en el espacio del kernel.

Si ejecutamos iptables -L -v (se puede especificar una regla en concreto si no queremos ver todas) aparece junto con cada regla el número de paquetes que se han ajustado a esa regla y el total de bytes. Así, podemos escribir un script que cree una nueva cadena; en esa cadena añadimos una regla por cada IP de la red local, precisamente con su IP como selector (origen o destino, según lo que queramos monitorizar) y como target, RETURN. De este modo los contadores reflejarán los paquetes y bytes enviados/recibidos por/para cada una de esas Ips. Esta información es útil por ejemplo para detectar virus que tratan de hacer escaneos de puertos y que a veces provocan que la tabla NAT del router ADSL se sature. En este caso apreciaremos que desde esa IP se envían muchos paquetes, aunque probablemente con pocos bytes.

Para poner los contadores de una cadena a cero se usa la opción -Z.

Ejemplo de script para crear y borrar reglas para tener contadores:

#!/bin/sh

ipmasalta=198

start() {

iptables -N contadores

contador=1

while [ ${contador} -le $ipmasalta ]

do

iptables -A contadores --source 192.168.15.$contador -o eth2 -j ACCEPT

contador=`expr $contador + 1`

done

iptables -A FORWARD -j contadores

}

stop() {

iptables -D FORWARD -j contadores

contador=1

while [ ${contador} -le $ipmasalta ]

do

iptables -D contadores --source 192.168.15.$contador -o eth2 -j ACCEPT

contador=`expr $contador + 1`

done

iptables -X contadores

}

Existe un proyecto (http://ipac-ng.sourceforge.net/) que crea las reglas, recopila la información y la guarda, para finalmente visualizarla.

Otro sistema basado en netfilter es el módulo de webmin para monitorizar el ancho de banda.

Además con el módulo account es posible añadir una sola regla para registrar la información de toda una red y que desglose el resultado a nivel de tcp, udp, icmp y resto. Para más información ver http://www.svn.barbara.eu.org/ipt_account/wiki/Usage

Hay muchas web y sistemas para que un equipo con IP dinámica pueda dar de alta su IP en un DNS cada vez que se conecta o cambia. Básicamente lo que se hace es conectarse a un servidor, que analiza la IP de origen: esa será la IP que registrará, tras comprobar que el usuario aporta unas credenciales que le autorizan para cambiar su entrada DNS.

No hay un único sistema, por lo que hay unos programas que sirven para unos sitios y otros para otros, habiendo programas que soportan varios protocolos, como ez-ipupdate.

El paquete http://gnudip2.sourceforge.net/ sirve para implementar nuestro propio servidor de DNS dinámico, junto con el cliente y la descripción del protocolo.