Nisu - UJI

Ix41 - Gestión de Servicios de Internet

04 July 2011

Contenido de la asignatura.

  1. Introducción
    1. Calendario de la asignatura
  2. Internet
    1. Repaso de TCP/IP
      1. Arquitectura de Internet
      2. Encaminamiento
      3. Túneles
      4. TCP
    2. Modelo Cliente/Servidor
    3. Cuestiones del tema
  3. Aplicaciones básicas
    1. El súper servidor Inetd
    2. Telnet
    3. FTP
      1. Comandos FTP
    4. Sobre la realización de las prácticas
    5. Práctica de herramientas básicas
    6. Práctica del escritorio remoto
    7. Comandos r
    8. SSH
      1. Preparación del entorno con un par de llaves
      2. Acceso a puertos bloqueados
      3. Uso remoto de aplicaciones locales
      4. Uso del agente, escenario 1
      5. Uso del agente, escenario 2
      6. Uso del agente, escenario 3
    9. Práctica de SSH
    10. Rsync
      1. El remoto es esclavo
      2. El remoto es servidor
      3. Otros usos
    11. Práctica de Rsync
    12. Network File System (NFS)
    13. Cuestiones del tema
  4. DNS, sistema de nombres de dominios
    1. Dominios
    2. Delegación de autoridad
    3. Resolución directa y resolución inversa
    4. Relación entre servidores
    5. BIND
      1. Ficheros de zona
      2. Resolución inversa
      3. IPV6 y named
    6. La resolución de nombres en un ordenador
    7. Práctica del servidor de nombres
    8. Cuestiones del tema
  5. El correo electrónico
    1. Las direcciones de correo
    2. Funcionamiento
    3. SMTP básico
    4. Relays, spam
    5. POP3, IMAP, Webmail
    6. Agentes de transporte
    7. Práctica de postfix
    8. Formato del mensaje
      1. Cabeceras
      2. MIME
    9. Práctica del correo
    10. Cuestiones del tema
  6. El World Wide Web
    1. Fundamentos. URLs
    2. El protocolo HTTP
      1. Operativa
      2. Cabeceras
      3. Operativa
      4. GET y POST
      5. Las cookies
    3. Servidor Web Apache
    4. Práctica de Apache
    5. El lenguaje HTML
      1. Introducción
      2. Estructura básica de un documento HTML
      3. Otras etiquetas
      4. Hipervínculos o enlaces
      5. Tablas
      6. Formularios
    6. El lenguaje PHP
      1. Ejemplos de scripts PHP
    7. Práctica del World Wide Web
    8. Cuestiones del tema
  7. Cuestiones generales
  8. Apéndices
    1. Ejemplos de configuración clásica de redes
      1. Red segmentada
      2. Red segmentada a través de una red privada
      3. ADSL sin NAT
      4. Uso de proxyarp.
      5. Configuración de una interfaz wifi
    2. Ejemplos de configuración moderna de redes
      1. NAT
      2. Varios encaminadores por defecto
      3. Selección de ruta
      4. ADSL con NAT en el router
      5. Varios proveedores
      6. Un ejemplo real.
      7. Otro ejemplo.
      8. Un túnel IP-gre-IP
      9. Un ejercicio práctico
    3. Ejemplos MIME
  9. Más en NiSu ...
Este material no es para imprimir. Son apuntes interactivos que sueden cambiar frecuentemente, léelos en la pantalla, puedes aumentar el tamaño de letra. No despilfarres papel.  

Introducción

Estos apuntes son una aproximación al contenido de la asignatura Gestión de Servicios de Internet.

La asignatura pretende cubrir las capas superiores de la arquitectura de redes, centrándonos en la única red universal, Internet. Así, estudiaremos el funcionamiento y administración de algunos servicios fundamentales de Internet, el servidor de nombres, el correo y el web, sin olvidar aplicaciones básicas de uso profesional y una introducción a las redes.

Los temas se acompañan de prácticas y al final de cada tema hay una colección de cuestiones resueltas. El calendario que se propone es el de prácticas para los grupos presenciales y de teoría y prácticas para el grupo semipresencial.

Internet

La importancia de Internet en nuestra vida diaria justifica la existencia de una asignatura dedicada a la gestión de los servicios de Intenet. Cuando escribimos Internet en mayúscula, nos referimos a una red concreta y muy popular. Se trata de una red de tipo internet (en minúscula), una red basada en el protocolo IP. Por encima del protocolo IP se implementan TCP (añade fiabilidad a las comunicaciones, controlando corrección extremo a extremo, con independencia de las trayectorias de cada datagrama individual y la suerte que haya podido sufrir) y UDP (acceso directo a IP). Estos protocolos permiten que varios programas de un mismo ordenador se pueden comunicar concurrentemente con programas de otros. TCP es tan empleado que a las redes IP se las suele llamar redes TCP/IP.

En 1969 se creó la primera red internet, conocida como ARPANET. Esta red fue la conexión de ordenadores entre tres universidades en Californa y una en Utah, Estados Unidos y disponía de un conjunto de servicios muy pequeño.

Internet ha evolucionado rápidamente desde 1995, desarrollándose numerosos protocolos a nivel de aplicación e innumerables servicios. Uno de los servicios que más éxito ha tenido en Internet ha sido sido el World Wide Web (WWW, o "la Web"), hasta tal punto que que es habitual la confusión entre Internet y este término, quizá porque sobre la Web se construyen innumerables aplicaciones, de hecho la mayoría de las empleadas por el usuario final.

Repaso de TCP/IP

Para administrar un sistema que preste servicios de Internet, aparte de los conocimientos básicos en administración de sistemas operativos, es necesario conocer a fondo la configuración de la red. Por ello ahora repasamos los conceptos básicos de Internet y en los apéndices se incluyen numerosos y complejos ejemplos de configuración de redes.
Arquitectura de Internet
Una red internet se apoya en el protocolo IP. Las ideas fundamentales de una red basada en IP son:
  • Cada ordenador conectado a la red tiene un número de protocolo IP (abreviadamente diremos una dirección IP o más brevemente, una IP) que debe ser único.
  • Los datagramas IP se transmiten encapsulados en un protocolo de nivel inferior (ethernet, wifi, etc.).
  • Diremos que una IP es directamente alcanzable si para llegar a ella basta con emplear el protocolo de nivel inferior.
  • Si una IP no es directamente alcanzable, al menos un equipo directamente alcanzable (encaminador o router) se encargará de encaminar los datagramas hacia dicha IP.
  • El encaminador estará, por otro interfaz, conectado a otra red con la misma situación, con lo que por inducción construimos la red internet. El resultado es una red fácilmente expansible.
En la práctica, para que un equipo quede conectado en una red internet es necesario:
  • Qué conozca qué IPs son directamente alcanzables.
  • Qué IP actuará de router para conectarlo con el resto de la red.
  • Que las demás IPs de la red conozcan una ruta hacia él.
Este último punto es muy importante y fuente de errores en los principiantes. Cablear y configurar un equipo correctamente no es suficiente para que quede conectado, lo principal es que los demás sepan alcanzarlo.

En IPv4, una IP tiene 32 bits. Para una escritura más cómoda, se escribe como x.x.x.x, donde x es un número de un byte. Así por ejemplo, 150.128.97.91 es la IP de este servidor y 18.232.38.214 es la IP que este servidor ve de tu ordenador. Dada una IP, las IPs directamente alcanzables son IPs con un número similar, formando un conjunto determinado por la denominada máscara de red. Así 192.168.27.5/21 indica un conjunto de IPs cuyos 21 primeros bytes son los mismos. La primera sería 192.168.24.0 que no es una IP utilizable para un ordenador, sino que representa la dirección de la red, que se escribe como 192.168.24.0/21. La última es 192.168.31.255, que normalmente tampoco es utilizable y se denomina dirección de broadcast. Si no se especifica la máscara de red, según la IP se deduce una máscara implícita (redes de clase A, B, C, etc,).

Dentro del espectro de direcciones de Internet, existen ciertas IPs reservadas (a veces se les llama privadas) que se caracterizan por no ser nunca encaminadas dentro de Internet. Su próposito es que podamos construir otras redes IP (otras internets), separadas de Internet, pero con IPs que no coincidan con IPs que puedan estar usándose en Internet (las llamadas públicas para distinguirlas de las privadas). Estas IPs privadas son las 10.x.x.x, las 172.16.x.x y las 192.168.x.x. Es decir, que emplearemos estas IPs por ejemplo para montar una red en casa, separada de Internet, pero compatible. Obsérvese que las mismas IPs pueden usarse en muchos sitios, puesto que jamás se encaminan en Internet, no forman parte de ella.

El nivel inferior (enlace) no entiende las direcciones de IP, necesita una dirección física (dirección MAC en el caso de Ethernet). Cuando un ordenador con una IP necesita acceder a otra IP de su red, usa el nivel inferior, y a través del protocolo ARP, pregunta qué ordandor tiene la IP que busca y éste le responde cuál es su dirección en el protocolo inferor, de modo que enviará los datagramas a esa dirección.
El comando: arp -na nos muestra las direcciones físicas de equipos de nuestra red que recientemente han conectado con el nuestro. Se trata de una tabla donde se cachean durante un breve periodo de tiempo las direcciones obtenidas.

El protocolo RARP es el inverso de ARP, Este protocolo es necesario cuando arrancan ordenadores remotos (sin disco) que solo saben su dirección física almacenada en ROM del hardware de red, y necesitan su dirección IP para conectarse. Más avanzados son BOOTP y DHCP, que permiten suministrar como respuesta no sólo la IP que debe asignarse al equipo sino la dirección del encaminador y la dirección de los servidores de nombres que puede usar.

Un ejemplo de configuración básica de una red puede verse aquí.
Desde los núcleos de linux 2.4 la gestión de la red es muy avanzada y se realiza desde el comando ip, que nos permite configurar todo lo relativo al IP. Los parámetros pueden abreviarse al máximo, así que ip address add se abrevia como ip a a en los ejemplos.

Veamos la configuración básica de una red. La figura muestra la clase C 194.1.2.0/24. La primera IP es la del router, del que no nos preocupamos de la parte conectada a Internet, pues operando por inducción entendemos correctamente configurada. Debemos recordar ahora que lo más importante es que los paquetes destinados a esta clase C se encaminen en el resto de Internet hacia este router, cosa que damos por supuesta. Ahora nos queda configurar la red correctamente. Por simetría, basta con escoger cualquier equipo, en la figura lo hemos marcado con una A. Inicialmente ejecutamos el comando:

ip link set dev eth0 up
que provoca la carga los módulos del kernel necesarios (suponiendo module autoload) y levanta la interfaz eth0. Este comando no lo repetiremos en los demás ejemplos.






A





194.1.2.2























194.1.2.3







194.1.2.1















194.1.2.5





eth0
Configuración de A:
 ip a a 194.1.2.2/24 dev eth0
#ip r a 194.1.2.0/24 dev eth0
Esta es la configuración básica de un equipo con una IP de Internet. Dispone de una IP sobre el interfaz eth0 y al añadir la IP, el comando ip amablemente nos enruta la red local, con lo que el comando marcado con # no necesita ejecutarse.
 ip r a default via 194.1.2.1
Al final añadimos una ruta por defecto a través de un router que pertenece a la red que acabamos de enrutar.
Obsérvese que necesito 2 rutas: una local y otra por defecto. Contar las rutas es un sencillo método para no olvidarme de ninguna configuración. En los apéndices se muestran más ejemplos de configuración.
Encaminamiento ^
En el IP clásico, se usa una tabla que asocia redes con las pasarelas por las que estas pueden ser alcanzadas, esta tabla estará presente tanto en máquinas que actúen como encaminador como en otras que sean simples hosts. Cada entrada de la tabla consiste en:
  • Un destino, es decir la IP que se puede alcanzar, que puede ser una red. Se usa la partícula default para referirse a el resto de las direcciones posibles.
  • Una distancia, que indica el número de saltos que se darán para llegar al destino, es habitualmente cero si la configuración es manual,
  • Una máscara, que determina el tamaño de la red destino, puede introducirse manual o automáticamente (según la clase A, B,C).
  • Una pasarela (encaminador, router).
  • Una interfaz.
El encaminamiento basado en la tabla se realiza de este modo:
  • Las entradas se examinan por orden, determinado por el tamaño de la red destino, las más pequeñas primeroi, teniendo en cuenta que un equipo es una red de tamaño 1 y la ruta por defecto es la red mayor.
  • Cuando se encuentra una red que contiene la IP destino se toma esta entrada y el paquete se transmite:
    • por el interfaz que indica
    • directamente o a través de la pasarela si está indicada.
En el encaminamiento clásico sólo existe una tabla de encaminamiento y sólo una ruta por defecto activa. Si hay más de una configurada, se usa la primera; si falla, es decir si el encaminador no responde, se usa la segunda, etc. Pero si el encaminador funciona, la ruta se da por buena aunque el paquete no alcance el destino.

Las necesidades del enrutamiento actual han llevado a que el TCP/IP clásico sufra modificaciones.
La idea clásica de una IP por interfaz ha evolucionado de forma que podemos asignar muchas IPs a un mismo interfaz. Dada la ruta, sabemos la interfaz, pero si esa interfaz tiene asignadas más de una IP, es necesario elegir una de ellas como origen del paquete IP. Dado un destino, si la IP de origen que el kernel selecciona no es la adecuada, el ordenador destino seleccionará una ruta diferente para los paquetes de retorno, lo que implicará problemas de rendimiento y lo más probable es que el paquete ni siquiera llegue al destino, ya que los encaminadores rechazarán la IP de origen.
Por ello debemos conocer como selecciona el kernel la IP de origen y si procede, forzar la selección de una determinada IP cuando nos interese. Las reglas son:
  • La aplicación origen selecciona ya una IP mediante la llamada al sistema bind. El kernel lo respeta y selecciona además la ruta correspondiente.
  • Las tablas de rutas contienen una ruta para el destino dada con el parámetro src del comando ip route
  • Determinada la ruta, el kernel selecciona la primera IP válida con el ámbito (scope) adecuado que esté en la misma subred que el encaminador seleccionado.
  • Si no, se selecciona la primera IP con el ámbito adecuado.

Una sola tabla de encaminamiento no satisface las necesidades del enrutamiento actual. Actualmente pueden definirse varias tablas de enrutamiento y selectores que determinan cuál es la que va a emplearse. Así un selector predefinido establece cual es la tabla principal, compatibilizando con el enrutamiento clásico, pero podemos definir nuevas tablas y selectores que determinen qué tabla usar. Estos selectores trabajan con diversos parámetro, destacando la IP origen y la IP destino.

Otro elemento importante del encaminamiento actual es el NAT (traducción de red), realizado por los routers. En el caso del source NAT (SNAT), cuando un paquete IP llega al router, éste sustituye la IP de origen del paquete por la suya, y reenvía el paquete, de modo que el destinatario lo recibe como si viniera del router. Al devolver la respuesta, ésta llega al router, quien la reenvía al origen real. Obviamente el router tiene que recordar todas y cada una de las transformaciones realizadas para reenviar cada una a su origen real. Éste es el mecanismo que emplean los routers domésticos para que diversos ordenadores de una red local puedan acceder a Internet con una sola IP válida de Internet, la IP del router.
Frente a SNAT, en el DNAT (destination NAT) la IP cambiada es la IP destino. Este es el mecanismo que emplean los routers domésticos para redirigir las peticiones que llegan a la IP pública de Internet, a un determinado equipo dentro de una red local de IPs privadas, necesario para que funciones ciertos programas, como eMule.

Túneles ^
El tunneling es una técnica de empaquetamiento. Consiste en añadir nuevas capas IP sobre un soporte IP ya existente. Supongamos dos ordenadores conectados a Internet, cada uno con una IP válida, pero pertenecientes a dos redes completamente distintas. Cuando uno quiere conectar con el otro sólo tiene que especificar el destino, y los routers intermedios se encargarán de encaminar los paquetes. Podemos imaginar que ambos están unidos por un cable virtual sobre el que podemos establecer sesiones telnet o servicios HTTP. Nada nos impide, sobre este cable virtual, establecer otra estructura IP. En este momento Internet actuará como un túnel para los nuevos paquetes IP que viajarán empaquetados en la estructura IP válida en internet. Entre ambas capas IP pueden existir otros protocolos. Si no los hay será un túnel IP-IP, pero puede haber túneles IP-GRE-IP, IP-PPP-IP, etc. En los apéndices hay un ejemplo de túnel gre.
TCP ^
El protocolo IP permite transferir información de un ordenador a otro, pero no permite distinguir la naturaleza de la misma. Por encima de IP, el protocolo TCP añade un atributo, el puerto, que se emplea para indicar el tipo de información que se está intercambiando. Además, el protocolo garantiza que los datos serán entregados en su destino sin errores y en el mismo orden en que que fuerón enviados.

La cuádrupla (IP origen, puerto origen, IP destino, puerto destino) determina una comunicación entre dos equipos y desde los programas se realiza a través de los sockets. Los sockets son puntos de acceso desde los programas al TCP/IP, manejándose como descriptores de fichero. Los socket no son exclusivos de TCP, aparecen en otros protocolos, como UPD.

Modelo Cliente/Servidor ^

Este modelo consiste en asignar roles a los ordenadores de la red. El ordenador que hace el rol de servidor se encarga de tener una aplicación escuchando peticiones de un determinado puerto. Cuando al servidor le llega una petición al puerto responde al cliente y asi se crea un servicio. El ordenador que hace el rol de cliente se encarga de realizar peticiones al servidor por dicho puerto. Obviamente, un ordenador puede dar varios servicios y ser a su vez cliente de muchos servicios.

Hay una estandarización por la que se asocian puertos y servicios, por ejemplo para conexiones FTP se utiliza el puerto 21. Se pueden definir hasta 216 puertos en un ordenador, la única resticción es que el sistema operativo no permite al usuario utilize puertos menores al 1024, pues son lo que se usan para definir los principales servicios del sistema. Si se quieren definir servicios en los puertos menores al 1024 los tiene que definir el administrador.

Estos son los principales servicios, una lista completa se halla en /etc/services
Puerto Servicio Programas servidores del servicio
21ftpftpd,proftpd,vsftpd
22sshsshd
23telnettelned
25smtpsendmail,postfix,qmail
53DNSnamed
80WEBapache
110pop3in_pop3d, courier_pop, cyrus_pop
143imapin_imapd, courier_imap, cyrus_imap
443httpsmismos que http
992pop3smismos que pop3 con una capa TLS
993imapsmismos que imap con una capa TLS

Cuestiones del tema ^

Quiero transferir un archivo de 1Mbyte y dispongo de una velocidad de transferencia real de 12Mbit. Al elegir el programa a emplear para realizar la transferencia, ¿le exigiré un requisito especial? Resp.
La transferencia del archivo durará menos de un segundo, por lo que cualquier programa vale, ningún requisito especial, usaré el que más cómodo me resulte.
En un aula informática de la UJI, estás trabajando en Linux como usuario autenticado. Tienes en tu home un archivo z.jpg con una imagen y decides transferirlo con ftp a lynx. Después de hacer el put, observas que el fichero en lynx es de un tamaño mucho menor que el original, pero también en el PC del aula. ¿Por qué sucede esto?. Resp.
En una sesión autenticada, el directorio inicial del usuario se comparte con lynx. Al transferir el archivo sobre sí mismo se ha estropeado. Es absurdo usar ftp entre el aula y lynx, ya que son realmente los mismos archivos.
Nota: Lo que realmente sucede es otra cosa, pruébalo y encuentra una explicación.
En un PC del aula de informática has puesto en marcha un servidor de VNC. Desde otro PC intentas conectarte a través de un cliente VNCi (vncviewer, navegador, etc), pero ni siquiera te llega a solicitar al contraseña de VNC del servidor y te avisa de un error de conexión. Luego pruebas a poner el cliente en modo Listen y después inicias la conexión desde el servidor al cliente (con vncconnect o Add new client), y sí que se establece la conexión. ¿Que es lo que esta pasando? Resp.
En el servidor hay un firewall que bloquea las conexiones a los puertos 590x y 580x, por eso, aunque está funcionando, no le llegan las peticiones desde otros equipos. Cuando la conexión se inicia desde el propio servidor si que tiene éxito porque el cliente no bloquea la conexión.
Dos cuestiones, usando Firefox:
  • Una página web me muestra (entre otras cosas) una imagen, cuya URL quiero averiguar. Cuando pulso el botón derecho para desplegar el menú contextual me dice que el botón derecho está deshabilitado. ¿Qué puedo hacer? Resp.
    Deshabilitar el javascript.
  • Una página web me muestra (entre otras cosas) una imagen, cuya URL quiero averiguar. Pulso el botón derecho para desplegar el menú contextual, eligo "Ver imagen" y me sale una imagen transparente de 1 pixel. ¿A qué se puede deber? ¿Cómo podré sacar la imagen que quiero ver? Resp.
    La imágen que veo es el background de una imágen de 1 pixel expandida al tamaño del fondo. Para ver la original, puedo elegir "Ver información de la página" y en la lista de "Media" veré la imagen.
¿Por qué crees que los navegadores rechazan URL de la forma http://usuario@servidor/ ? Resp.
Porque nos proponen entrar en el servidor autenticados y podrían ser una forma de capturar contraseñas.
Visito una página web donde mi navegador no me deja seleccionar el texto que veo. Explica cómo la página puede estar evitando dicha selección y explica cómo saltar ese impedimento. Son varias las posibles razones y las soluciones, explica algunas. Resp.
Una razón es que el texto sea realmente una imagen, con lo que es normal que no pueda seleccionarla, si quiero copiar de forma automatizada el texto tendré que recurrir a un OCR. Si realmente es texto, probablemente lo evita mediate javascript, basta con deshabilitarlo. Si lo evita por alguna propiedad extraña que interpreta mi navegador puedo cambiar de navegador. En cualquier caso, puedo ver el código fuente de la página y copiar de ahí. Si no se ve porque es renderización dinámica, puedo analizar el DOM con cualquiera de las herramientas de que dispone Firefox.
Lo importante es tener claro que es algo que está sucediendo a nivel del cliente y por más que lo intenten, yo siempre podré manipular el cliente. Probablemente existen otras formas de intentar evitarlo, como divs con fondo transparente sobre el texto, pero, inisito, siempre bajo el control del cliente.
Explica cómo se realiza (dí los comandos) una conexión VNC entre dos equipos con linux contra la sesión X principal (display :0), cuando el cliente es quien inicia la conexión. Explica lo mismo pero cuando es el servidor quien inicia (modo Listen). Explica un utilidad práctica real del modo Listen. Resp.
En el caso 1, el servidor debe compartir la sesón X, lo que se realiza en gnome con vino-server y en kde con krfb que suelen ser transparentes para el usuario, quien activa la compartición normalmente desde un menú. El cliente se conecta con vncviewer indicando el host del servidor y el display :0.
En el caso 2, el cliente inicia primero vncviewer -listen y el servidor puede ejecutar x11vnc -conect hostcliente 5500 donde 5500 es el puerto que nos indique vncviewer -listen. También puede usarse en el cliente vncconnect.
La utilidad práctica le modo Listen es hacer mantenimiento remoto de ordenadores que están detrás de un cortafuegos, el técnico tiene un ordenador que sí puede recibir conexiones remotas, pero el cliente no, así que el técnico le dice al cliente que lance el modo Listen contra su oordenador.
Arranco en mi Linux un servidor VNC. Me conecto desde un cliente Windows y veo que las ventanas que me aparecen no son las mismas que tengo en el monitor principal del Linux ¿Por qué? Trabajo un poco desde Windows, desconecto y vuelvo a conectar un rato después, viendo que todo está como lo dejé ¿Por qué no se cerraron las ventanas al desconectar y está todo igual? Resp.
El servidor VNC tiene su propio servidor X, por ejemplo el :1, mientras que el escritorio principal tiene otro servidor X, normalmente el :0. Con esto está todo dicho: las ventanas accedidas desde el cliente VNC son las que se abran sobre ese servidor X, no las del escritorio principal. Y el VNC sirve justamente para conectar con un servidor X sin interferir su funcionamiento. Por eso puedo desconectar y conectar las veces que quiera, que eso no afecta al servidor X que hay en marcha en el Linux.

Aplicaciones básicas ^

El súper servidor Inetd

Los programas que proporcionan servicios de aplicación a través de la red se llaman demonios. Un demonio es un programa que abre un puerto, comúnmente un puerto de algún servicio bien conocido, y espera conexiones entrantes en él. Si ocurre una, el demonio crea un proceso hijo que acepta la conexión, mientras que el proceso padre continúa escuchando más peticiones. Este mecanismo funciona bien, pero tiene unas pocas desventajas; al menos una instancia de cada posible servicio que se quiera proporcionar, debe estar activa en memoria a todas horas. Además, la rutina software que hace la escucha y la gestión del puerto tiene que ser replicada en cada uno de los demonios de red.

Para superar estas ineficiencias, muchas instalaciones Unix ejecutan un demonio de red especial, el cual debe ser considerado como un súper servidor. Este demonio crea sockets en nombre de cada uno de los servicios y escucha en todos ellos simultáneamente. Cuando una conexión entrante es recibida en cualquiera de esos sockets, el súper servidor acepta la conexión y replica el servicio especificado para ese puerto, pasando el socket a gestionarse a través del proceso hijo. El servidor entonces, vuelve a la escucha. El súper servidor más común se llama inetd, el Demonio de Internet. Se inicia en tiempo de arranque del sistema y toma la lista de servicios que ha de gestionar de un fichero de iniciación llamado /etc/inetd.conf, donde se especifica el programa que debe lanzar para tratar el servicio solicitado.

Ventajas de usar inetd:

  • La aplicación que trata el servicio no sabe nada de TCP/IP.
  • La aplicación no consume recursos si nadie gasta el servicio, sólo esta activo inetd.
Inconvenientes:
  • Útil para aplicaciones que se usen de forma esporádica o para aplicaciones de sesión; pero es muy poco eficiente para servicios que reciben muchas conexiones, como WWW.
  • Ineficiente cuando la carga de los archivos de configuración de la aplicación es muy costosa.
Actualmente existe una alternativa a inetd, xinetd.

Telnet

Telnet es un protocolo informático que emula un terminal remoto para conectarse a una máquina multiusuario. El servidor escucha el puerto 23 y el cliente conecta con él cuando desea mantener una sesión remota. La conexión TCP permanece abierta durante toda la sesión, es decir que la sesión de trabajo remoto dura lo mismo que la sesión TCP.
El cliente telnet intenta realizar la emulación de un terminal físico (actualmente en desuso) y por ello, primero negocia el modelo de terminal a emular, frecuentemente un VT100 o superior. A partir de ahí, el cliente tiene la sensación de que esta en la máquina remota ya que todo lo que teclea lo manda a la máquina remota y todo lo que produce esta lo recibe el cliente.

Este servicio solo sirve para acceder en modo terminal, es decir, sin gráficos, pero fue una herramienta muy útil para reparar problemas a distancia. También se utilizó para consultar datos a distancia, como datos personales accesibles a través de internet, información bibliogáfica,etc.
Los requisitos para acceder a este servicio son muy sencillos: conocer el nombre y la dirección de servidor remoto y estar autorizados mediante un identificador de usuario y contraseña para poder utilizarlo, y es que, claro está, el servidor antes de permitir acceso invoca al programa login para autenticar al usuario remoto, igual que en un terminal físico de un equipo multiusuario.

El principal problema de este servicio es de seguridad ya que todos los datos que se envian y se reciben se envian por la red sin cifrar. Estos datos incluyen el usuario y la contraseña, por tanto, si en el momento de la autenticación, alguien está espiando la red podría obtener estos datos y conectarse a la máquina usurpando la identidad del propietario de la contraseña. Por estas y otras razones éste servicio ha sido masivamente reemplazado por ssh. No obstante, por su naturaleza sencilla de teminal remoto, seguimos empleándolo para realizar conexiones remotas buscando depurar protocolos de más alto nivel como SMTP, POP, HTTP, etc., como veremos en la práctica correspondiente.

FTP

El servicio de transferencia de ficheros permite transferir ficheros entre ordenadores utilizando el protocolo FTP (File Transfer Protocol). Aunque el término FTP hace referencia al protocolo empleado, se suele utilizar indistintamente para nombrar tanto el protocolo como el servicio asociado. Si disponemos de un ordenador que presta dicho servicio y, por otra parte, de un cliente FTP, podremos transferir ficheros desde el cliente hasta el servidor o viceversa. En general es un servicio que requiere autenticación, aunque existen servidores abiertos (se accede con un usuario genérico denominado ftp o anonymous.
El protocolo FTP utiliza el puerto 21 para la conexión entre cliente y servidor, pero para la transferencia de datos se solía emplear el puerto 22, aunque está en desuso. También cabe destacar que el servicio FTP no ofrece integridad alguna de los datos transmitidos y que los datos no se transportan cifrados, como hace por ejemplo scp.

Respecto a la transmisión de datos, existen dos modos. En el modo activo, el originalmente habitual en el FTP, el cliente pide una operación al servidor, pero es éste quien la realiza, es decir, en el momento de realizar una petición de un recurso, será el servidor quién conecte con el cliente. El problema de este modo es que hoy en día es habitual que el cliente esté detrás de un NAT, lo que requiere usar el modo pasivo. En este modo, es el cliente quien inicia todas las conexiones, y se realizan por pueros que se negocian dinámicamente.

El protocolo FTP se compone de una serie de comandos que el cliente envía al servidor solicitando las distintas operaciones que pueden relizarse.

A nivel de uso, a la hora de transferir ficheros hay dos tipos de transferencias posibles, modo texto y binario. Es fundamental establecer el tipo de transferencia adecuado para cada fichero, pues en caso contrario el resultado de la transferencia sería un fichero no válido. La transferencia en modo binario es la requerida en la mayoría de los casos. Al utilizar este modo de transferencia, el fichero que obtenemos es exactamente igual al fichero original.

El problema se plantea en el caso de los ficheros de texto, pues éstos presentan algunas diferencias en función del sistema en el que estemos trabajando. Por ejemplo, en Linux se utiliza un único carácter para representar un salto de línea en un fichero de texto, mientras que en DOS/Windows son necesarios dos caracteres. Si transferimos en modo binario un fichero de texto desde Windows hasta una máquina Linux, el fichero obtenido será exactamente igual al original, pero los editores de texto podrían no reconocerlo de forma adecuada, ya que la representación de los finales de línea no sería la esperada (sobraría un carácter por línea). Del mismo modo, si enviásemos en modo binario un fichero de texto desde una máquina Linux hasta un sistema Windows, el final de cada línea sería incorrecto (faltaría un carácter por cada línea). Cuando establecemos la transferencia en modo texto, los ficheros son modificados en la forma necesaria según el tipo de los sistemas origen y destino. Es decir, los ficheros obtenidos no son "exactamente" iguales a los originales, sino que han sido modificados para adaptarlos al nuevo sistema. Por otra parte, si transfiriésemos en modo texto un fichero binario (por ejemplo, una imagen en formato jpg), se realizarían modificaciones sobre el mismo durante el proceso de transferencia, por lo que el resultado sería un fichero no válido.

El cliente tradicional FTP es un cliente en línea de comandos. Éste cliente muestra un inductor y el usuario introduce comandos. Estos comandos son muy similares a los del propio protocolo FTP, pero no deben confundirse. El comando de cliente denominado site permite enviar comandos del protocolo FTP al servidor directamente. Los clientes visuales, como Filezilla, son hoy en día más habituales, pues el usuario no necesita conocer ningún comando. Ambos tipos de cliente los ensayaremos en la práctica correspondiente. Poner los comando sdel protocolo, no los del cliente.

Comandos FTP

Sobre la realización de las prácticas ^

Para la realización de las prácticas de esta asignatura necesitas tener una cuenta en al.nisu.org. Probablemente tu profesor ya la ha creado, para acceder puedes establecer tú mismo la contraseña, simplemente acude a la página principal de dicho servidor.

Aunque los enunciados de las prácticas están pensados en su mayoría para que puedas realizarlas en casa, lo normal es realizarlas en los laboratorios dentro del horario. Dichos laboratorios no disponen de la integración en el sistema de autenticación de la UJI. Es decir, cuando arrancas el Linux (o Windows) instalado dispones de un ususario genérico usuario. El inconveniente es que no puedes guardar ninguna configuración personalizada de tus aplicaciones. Además, todo lo que dejas en el disco duro queda a la disposición de otros estudiantes y se borra periódicamente.

Para resolver el problema, cuando Linux arranca, una vez ha iniciado el kernel, mantén pulsada la tecla de borrar (la que está encima de "Intro"). Te solicitará usuario y contraseña (la de Nisu, no la de la UJI) y te creará un usuario local con tu alxxxxxx. A partir de ahí podrás trabajar con tu usuario, y tus archivos se guardarán, no en local, sino en red, pues tu directrorio local (del PC del laboratorio) se ha montado sobre el directrorio home_aulas que tienes en tu cuenta en Nisu, que obviamente no debes borrar. Como resultado, nada de lo que guardes en tus directorios queda en el PC, sino que se conserva en Nisu para la próxima sesión.

A esta situación le denominaremos usuario autenticado en el laboratorio.

Comandos r ^

Estos comandos han sido también superados por SSH, que incorpora sus funciones incluso a nivel de configuración. No obstante, al ser mucho más rapido su setup, se emplean en redes locales con alto grado de confianza, como por ejemplo un clúster de computación con procesos distribuidos. Los comandos r son:
  • rexec se utiliza para ejecutar un programa en otra máquina. Un ejemplo de su uso sería rexec B programa, siendo B la máquina donde va a ejecutarse el programa. No suele emplearse directamente por el usuario sino por aplicaciones, para el usuario es más cómodo el rsh.
  • rlogin [-l usuario] servidor permite abrir una sesión de trabajo en el servidor, similar a un telnet. Cuando el servidor recibe la petición:
    • Comprueba que el puerto origen es menor que 1024. Así sabe que es el programa originalmente instalado por el administrador de la máquina cliente.
    • El programa cliente le envía el usuario que ejecuta la petición, que puede ser distinto del usuario solicitado con la opción -l.
    • Consulta el fichero /etc/hosts.equiv. Si el ordenador cliente está en la lista lo admite si el nombre de usuario es el mismo.
    • Si no, consulta el archivo ~/.rhosts (del usuario solicitado). Este archivo se compone de líneas de la forma máquina [usuario cliente]. Si la pareja (máquina cliente, usuario cliente) figura en él, lo admite.
    • Si no, pide la contraseña del usuario solicitado.
  • rsh [-l usuario] servidor comando argumentos, ejecuta el comando en la máquina remota. El proceso de autenticación es como el de rlogin, pero no pide la contraseña si el proceso automático falla, simplemente rechaza la operación. El comando rsh se comporta como rlogin cuando no se especifica ningún comando.
  • rcp ficheros [usuario@]servidor:[path], copia los ficheros en la máquina servidor accediendo con el correpondiente usuario. El procedimiento de autenticación es el de rlogin. Si el path es un fichero sólo puede copiarse un fichero, si es un directorio pueden copiarse varios. Obsérvese que rcp unfichero unservidor:otrofichero es lo mismo que rsh <unfichero unservidor "cat >otrofichero". La opcion -p realiza la copia preservando la hora y los permisos del fichero.

SSH ^

Podemos pensar en SSH como un protocolo pensado para dotar de seguridad a telnet o los comandos r. De hecho los comandos ssh y scp heredan la sintaxis y el comportamiento global de rsh y rcp respectivamente. Vemos muy brevemente las características nuevas de ssh. Para entenderlas bien se requiere conocer un minimo de criptografía de llave pública.
  • En primer lugar la transmisión de datos se realiza cifrada.
    Para ello el cliente debe conocer la llave pública del servidor o aceptarla la primera vez, con las consideraciones de seguridad implicadas.
    A partir de ahí se establece una llave de sesión y se cifra la transmisión.
  • La autenticación puede ser por contraseña o mediante un par de llaves.
    • En el caso de usar contraseña, simple pero incómodo, la contraseña es solicitada cada vez, a diferencia de rsh. Obviamente es la contraseña que el usuario dispone en el servidor, como en rlogin.
    • En el caso del par de llaves, el cliente debe disponer de un par de llaves (que puede haber generado previamente con ssh-keygen), comúnmente de tipo RSA. La llave privada estará en el cliente, normalmente almacenada en ~/.ssh/id_rsa, la llave pública en ~/.ssh/id_rsa.pub.
      Si el contenido de este archivo ha sido añadido al archivo ~/.ssh/authorized_keys del servidor, funcionará la autenticación mediante par de llaves. Si la llave privada está protegida por contraseña, ésta se solicitará al cliente en el momento de cargarla. No debe confundirse con la contraseña del servidor, que no interviene en este modo de autenticación.
    Los modos de autenticación se intentan normalmente de modo secuencial, se intenta primero con el par de llaves y si falla o no está disponible, se intenta con la contraseña del servidor.
  • Permite redirección de puertos, algo similar a un túnel. Se realiza especificando: -L puerto_local:servidor:puerto_remoto y -R puerto_remoto:maquina_local:puerto_local. En los ejemplos veremos cómo usarlo.
  • Permite redireccionar las Xwindow, usando la opción -X.
    Para ello en el remoto se crea un display virtual que es redireccionado al local, mejorándose la transmisión si se emplea además la compresión de datos (con -C).
Un programa complementario a ssh es ssh-agent, el agente SSH. Este programa se inicia con: eval $(ssh-agent), lo que define una serie de variables de entorno. A partir de ese momento cuando lance un ssh, sabrá conectar con el agente. El agente lo que hace es recopilar llaves privadas para autenticación, con ayuda del comando ssh-add. Si además uso ssh -A, para acceder a una máquina remota, la conexión con el agente se propaga, de modo que si hago ssh-add en la máquina remota, la llave se copia en el agente que tengo en mi ordenador.

Para poder comprender lo explicado, es necesario ver algunos ejemplos y realizar la práctica.

Preparación del entorno con un par de llaves
Queremos acceder a un servidor al que tenemos acceso SSH usando autenticación mediante llave RSA. Podemos hacerlo usando ssh-copy-id, pero lo haremos a mano:
ssh-keygen -t rsa
Esto sólo lo hacemos si no tenemos ya una llave. Si ya disponemos de ella, nos saltaremos este paso. Podemos dejar la contraseña vacía.
cat ~/.ssh/id_rsa.pub
Simplemente visualizamos la llave pública que se ha generado.
ssh servidor "cat >>~/.ssh/authorized_keys" <~/.ssh/id_rsa.pub
Añade al fichero de llaves autorizadas del servidor la llave que deseamos. Aquí solicitará la contraseña del servidor.
ssh servidor ls
Comprobamos que funciona: lista los ficheros sin pedir ninguna contraseña.
Acceso a puertos bloqueados
Supongamos que desde casa quiero enviar correo con thunderbird usando como servidor saliente un ordenador que está detras de un cortafuegos y no tengo acceso a su puerto 25. No obstante tengo acceso SSH a ese ordenador.
Configuro entonces thunderbird para que use como servidor saliente localhost, puerto 2500, y ejecuto:
ssh -fN -L 2500:localhost:25 miuser@elservidor
Esto provoca una conexión SSH con el servidor, pero que no hace nada (-N), simplemente se queda en marcha para redirigir puertos, y además no me bloquea el terminal (-f provoca un fork después de la autenticación y la aplicación se queda en segundo plano). La redirección de puertos (-L) hace que cualquier conexión a local por el puerto 2500 se envíe por SSH y se realice en el servidor una conexión a él mismo (localhost) por el puerto 25.
Si no tuviera acceso SSH al servidor de correo, pero sí a otra máquina desde donde sí puedo acceder al puerto 25 del servidor, haría:
ssh -fN -L 2500:elservidor:25 miuser@otramaquina
de modo que las peticiones al 2500 de mi máquina se envían por SSHa la otra máquina remota, y ésta las reenvía al servidor, puerto 25. Es decir, que la conexión SSH entre mi ordenador y la otra máquina es como un tunel que transfiere la conexión a mi ordenador en el puerto 2500 al servidor en el puerto 25.
Uso remoto de aplicaciones locales
El clauer se opera a través de un demonio que escucha peticiones por el puerto 969, pero sólo escucha la IP 127.0.0.1, es decir que sólo pueden operar aplicaciones locales. Meto el clauer en en mi ordenador pero quiero que pueda usarlo un firefox arranco en una máquina remota (donde no hay demonio del clauer). Para ello hago:
ssh -fN -R 969:localhost:969 root@maquina
Necesito ser administrador en la máquina remota para poder escuchar ese puerto, lanzo el proceso con -fN para que sólo redirija puertos y no moleste.
ssh -X user@maquina firefox
Ejecuto firefox con redirección X.
Uso del agente, escenario 1
Sean dos servidores, tengo una llave privada en mi ordenador que me da acceso a ambos, pero para acceder a servidor2 tengo que pasar por servidor1, que no tiene copia de la llave.
eval $(ssh-agent)
Arranco el agente, sólo si no lo está.
ssh-add
Añado mi llave privada.
ssh -A servidor1
Entro en servidor1, manteniendo la conexión con el agente.
ssh servidor2
Desde servidor1 accedo a servidor2. Como tengo la conexión con el agente de mi ordenador, uso la llave, que no está copiada en servidor1.
Uso del agente, escenario 2
Sean dos servidores, la llave para acceder a servidor1 la tengo yo, pero la de acceder a servidor2 está en servidor1 y quiero acceder a servidor2 desde mi casa.
ssh -A servidor1
Supongo el agente arrancado, accedo a servidor1 propagando la conexión con el agente que está en mi ordenador.
ssh-add
En servidor1 añado la llave que hay allí guardada, al agente de mi casa.
exit
Vuelvo a mi ordenador. Esos tres comandos pueden hacerse con uno solo.
ssh servidor2
Ya puedo entrar en servidor2 porque en el agente de mi casa tengo la llave copiada.
Uso del agente, escenario 3
Sean diez servidores. Accedo a los servidores 1...9 a través del 0, pero ni mi ordenador ni el servidor 0 tienen la llave que me da acceso a los demás, está en servidor9. Quiero copiar un mismo fichero de mi ordenador a los 9 servidores 1...9.
ssh -A servidor0 ssh -A servidor9 ssh-add
Con el agente inicado en mi ordenador, accedo al servidor 0 manteniendo la conexión con mi agente, pero sólo para ejecutar el comando que accede al servidor 9, donde cargo la llave. Sigo en mi ordenador, no he entrado en ningún servidor.
for s in 1 2 3 4 5 6 7 8 9; do
ssh -A servidor0 "ssh servidor$s 'cat >fichero'" <fichero
done
Para cada servidor 1...9, copio el fichero pasando por el servidor 0. Obsérvese la necesidad de comillas " fuera y comillas ' dentro. Ver las cuestiones del tema.

Rsync ^

Rsync es una excelente aplicación para mantener copias idénticas de directorios en dos ordenadores, incluso para copiar archivos sueltos entre dos máquinas. Es incluso recomendable para copiar archivos grandes en un mismo ordenador por poder establecer una velocidad de copia controlada que no aumente la carga del sistema. Uno de los puntos de interés de Rsync es su capacidad de transmitir sólo aquellos datos que han sido modificados entre el origen y el destino.

Se puede usar en dos modos básicos: el remoto es un servidor o el remoto es un esclavo.

El remoto es esclavo
Se requiere un modo externo de conectar con la máquina remota (por defecto ssh). No es necesario que haya un servidor Rsync funcionando, sólo que esté disponible el programa rsync en ambas máquinas. Se identifica este modo por la especificación del remoto según servidor:objeto. Ejemplo:
rsync -e ssh --bwlimit=10 -acvP *.avi mon@servidor:sueltos/
Conectará con el servidor remoto vía ssh y arrancará una instancia de rsync en modo esclavo (--server --sender). El resultado es que copiará en servidor los archivos ".avi" del directorio actual utilizando como transporte una sessión SSH. En servidor debe existir el usuario mon, el directorio sueltos y la autenticación será la que exija la sesión SSH. Los archivos se depositarán en el directorio sueltos y la copia se realizará como mucho a 10kbytes/seg.
Digamos que en este modo, rsync es una especie de scp o rcp muy mejorado.
El remoto es servidor
Este modo se establece porque requerimos el objeto remoto mediante la especificación servidor:módulo/objeto.

Por una parte, en el servidor, como root defino en /etc/rsync.conf los módulos que quiero, por ejemplo:
[programas]
Definimos el módulo programas.
path = /home/pepe/prgs
use chroot = yes
Su directorio raíz es éste y forzamos chroot que mejora la seguridad, el cliente no tiene por qué saberlo.
read only = no
Permitimos escritura.
uid = pepe
gid = users
Este es el usuario y el grupo del servidor con que rsync accederá a los archivos, el cliente no tiene porqué conocerlo.
auth users = manolo
secrets file = /etc/rsyncd.secrets
Este es el usuario que debe poner el cliente, la contraseña en el archivo /etc/rsyncd.secrets.
Por otra parte, el cliente conecta con el servidor con el user y el módulo deseado, especificando para el remoto la combinación ::, por ejemplo:
rsync -avcP *.c manolo@servidor::programas/mios/
Copiará manteniendo los permisos y demás, combrobando checksum y mostrando progreso los archivos ".c" del directorio actual a la máquina servidor.
Al especificar el módulo programas, se requiere manolo como identificación. Debe de existir en el servidor el directorio /home/pepe/prgs/mios, que es donde se copiarán los archivos.
Si no se especifica lo contrario, el cliente conecta con el servidor por un puerto concreto (873). En ese puerto se supone un servidor Rsync en marcha (quizá a través de inetd). Si tal servidor no existe, el cliente puede arrancarlo, usando el parámetro -e. Por ejemplo:
rsync -avP -e ssh *.c pepe@servidor::programas/mios/
Conectará con el servidor por SSH, usuario pepe, y entonces arrancará en remoto una instancia de rsync en modo servidor (--server --daemon). En este caso usar un usuario propio de Rsync no tendría sentido, por lo que es conveniente que, al ser a nivel de usuario y no de sistema, rsyncd.conf esté en el directorio HOME del usuario pepe y no requiera ninguna autenticación extra, ya que la autenticación ha sido por SSH.
[programas]
path = /home/pepe/prgs
use chroot = no
read only = no
Éste podría ser el aspecto del fichero rsyncd.conf del usuario pepe. No puede usar chroot, pues es una operación privilegiada del administrador, pero el funcionamiento es el mismo, chroot sólo es una medida de seguridad extra. Como he comentado, no es necesario un fichero de autenticación ni especificar un usuario propio de Rsync, pues el usuario es pepe y se ha autenticado vía SSH.
Es interesante combinar esta característica con la posibilidad de restringir el uso de las llaves en SSH. Sea el siguiente escenario: soy usuario (yomismo) de una máquina, quiero que un amigo mantenga en mi directorio una colección de archivos pero no le quiero dar acceso tipo shell y tampoco puedo ni quiero tener un servidor rsync en marcha. Para resolverlo, en la máquina remota, en mi usuario, en el archivo authorized_keys pongo la llave que mi amigo me diga pero con la opción:

command="rsync --server --daemon --config=rsyncd.conf ."
de modo que cuando se autentique con su llave se ejecuta ese comando. En rsyncd.conf de mi HOME debo colocar:
[ejemplo]
path = /home/yomismo/cosas/
use chroot = no
read only = no
El cliente sólo podrá acceder a cosas. No puedo usar chroot porque rsyncd no es ejecutado por el administrador.
Mi amigo podrá ejecutar comandos como:
rsync -e ssh yomismo@servidor::
Le dirá qué modulos están disponibles.
rsync -e ssh -a yomismo@servidor::cosas/. .
Copiará el contenido del directorio remoto al directorio actual.
rsync -e ssh -a yomismo@servidor::cosas/..
No hace caso del .. , sólo conseguirá listar el directorio cosas.
Como comentario final, vale la pena hacer constar que si se usa :, se presupone -e ssh, pero si se usa ::, se presupone conexión directa, con lo que si se desea vía SSH hay que especificarlo con -e.

Notar también que si queremos montar un servidor rsync autónomo, basta con ejecutar: rsync --daemon, pudiendo cambiar el puerto por defecto (873) con la opción --port, y por supuesto el archivo de configuración.

Otros usos ^
La operación de mover un archivo grande de un disco duro a otro implica copia de datos. En el caso de discos IDE usar mvsuele sobrecargar el sistema. Una solución es:
#!/bin/bash
while true; do
l=$( l=${l%% *}
l=${l/./}
Creamos este script del shell que lee la carga del sistema (le quita el punto) y la almacena en la variable l.
  [ $l -le 200 ] && break
sleep5
done
Si la carga es menor que dos, sale del bucle, si es mayor espera 5 segundos.
rsync -aP --bwlimit=5000 "$1" "$2" && rm "$1"
Realiza la copia con un límite de 5Mbytes/seg de velocidad y si todo va bien borra el original.
Otro uso interesante de Rsync es que permite la copia remota de archivos dispersos. Un archivo disperso es el que se crea sin reservar todo el espacio que indica su tamaño. Por ejemplo, el comando
dd if=/dev/null seek=102400 bs=102400 count=0 of=fichero
crea un archivo de 10Gigas de tamaño, pero que en el disco ocupa 0 bytes. Si copiamos este archivo con scp, la copia creada, local o remota, sí que reserva todo el espacio en disco, en el ejemplo 10Gigas. Si especificamos la opción -S en rsync, logramos que el rsync remoto respete el uso de disco, de modo que el archivo copiado sólo ocupa los bloques realmente usados en el original, en el caso del ejemplo anterior, ocupará igualmente 0 bytes.

Network File System (NFS) ^

Sistema de ficheros remoto que permite compartir archivos entre un servidor y varios clientes. Se aconseja su uso para redes locales, puesto que la transferencia de todos esos datos puede ser pesada, pese a emplear UDP sobre IP y no TCP.
Es importante señalar que está altamente integrado en los sistemas Unix, es decir, que un usuario que use un directorio remoto apenas percibe la diferencia con su sistema local. También que manteniene perfectamente la coherencia del sistema de ficheros, por ejemplo, si desde varios equipos de accede al mismo directorio, y se crea un archivo en él, todos los equipos ven los cambios de forma inmediata. Realmente lo que sucede es que los equipos cliente realizan peticiones RPC al servidor que es quien realiza los cambios, sin generar incoherencias en el sistema de archivos real. Los equipos cliente no perciben el sistema como un "disco" sino como "directorio remoto".

El servidor comparte directorios previamente montados, no importa el tipo de sistema de archivos que se trate. Para compartir un directorio, el servidor debe incluirlo en el erchivo /etc/exports, con el formato:

directorio	maquina(opciones),maquina(opciones),...
La máquina puede ser una sola o un conjunto determinado por nombre o IP, de modo que *.uji.es significaría todas las máquinas cuyo nombre termine en .uji.es y 192.168.* todas las IPs que comiencen por 192.168. Las opciones más relevantes son rw o ro y no_root_squash. Esta última anula una funcionalidad del NFS por la que los archivos del root del directorio compartido son vistos por el cliente como propiedad de nobody.
El servidor debe tener instalados y en marcha los demonios rpc.mountd y rpc.nfsd, o alternativamente usar el servidor integrado en el kernel. Sólo el administrador puede decidir lo que se comparte, pues debe expresarse en /etc/exports.

El equipo cliente, para poder emplear el directorio compartido, debe montarlo como cualquier otro sistema de archivos, en este caso de tipo nfs, según:

mount -t nfs servidor:directorio_exportado driectorio_local
Deducimos que el cliente debe ser administrador y que el tipo de sistema de ficheros nfs debe estar disponible en el kernel.

Como ejemplo, supongamos que tenemos dos equipos administrados por la misma persona y que en ambos están los mismos usuarios. Queremos aprovechar los dos discos de los ordenadores para los distintos usuarios. Para ello el equipo A exporta /home y el equipo B exporta /home2. Los usuarios se crean aleatoriamente en /home y /home2. El equipo B crea el /home vacío y monta el /home de A. El equipo A crea el /home2 vacío y monta el /home2 de B. De este modo un usuario accede al equipo que quiere y accede a sus archivos sin problemas, puede que en local o puede que en remoto, de forma transparente.

Cuestiones del tema ^

El escenario 3 del agente visto en teoría, puede realizarse mejor con scp. Piensa qué pasaría si el fichero tuviera espacios en blanco en el nombre y qué tendrías que hacer. Resp.
for s in 1 2 3 4 5 6 7 8 9; do
ssh -A servidor0 "scp fichero servidor$s;"
done
Si hay espacios en blanco el shell necesita que ponga comillas en el nombre:
ssh -A servidor0 "scp 'fichero' servidor$s;"
En el caso de hacerlo sin scp es más complejo:
ssh -A servidor0 "ssh servidor$s 'cat >\"fichero\"'" <"fichero"
Si estoy en la máquina MAQ1, ¿qué hace el siguiente comando?
ssh -fn MAQ2 "while true; do xwd -display :0 -name miVentanita | convert - gif:- \
		| ssh MAQ1 'cat >volcado.gif'; sleep 1m; done"
1. ¿Por qué -fn ? 2. ¿Por qué las comillas en el cat? 3. ¿Qué pasaría si no las pusiera? 4. ¿Y si pusiera ssh MAQ1 cat \>volcado.gif? 5. ¿Cuándo terminará el ssh principal? Resp.
Ejecuta un bucle en MAQ2. El bucle captura el contenido de cierta ventana, lo convierte a GIF y desde MAQ2 se envía a MAQ1 y se deja en el fichero volcado.gif, que se sobreescribe cada minuto. 1. Sirve para que ssh funcione en segundo plano. 2 Porque si no, volcado.gif se quedaría en MAQ2. 4 Pruébalo. 5. Cuando lo pare con un kill.
Tienes que transferir un archivo de 2 Gigabytes entre dos ordenadores administrados por tí. Dispones de una línea de 56Kbit/s. Explica una forma razonable de hacerlo. Resp.
Emplearía rsync en modo parcial y comprimido. Son 5 dias de transmisión del archivo íntegro, pero comprimido puede ser mucho menos. No puede usarse un método que no garantice la continuación al 100%. Otra opción es partirlo en trozos, pero sólo es faena extra, aunque clásicamnete se ha usado rar con compresión y particionado para la transmisión de archivos grandes. Pero si el archivo ya existe y ha sido ligeramente modificado, rsync es especialmente útil.
Estudia lo que hace este script:
		#!/bin/bash
		bs=10240
		if [ ! "$1" ]; then
		  echo "$0 host:orig destino"
		  exit 1
		fi
		d=${2:-.}
		h=${1%%:*}
		if [ "$1" = "$h" ]; then
		  echo host:fichero
		  exit 1
		fi
		f=${1#$h:}
		if [ -d "$d" ]; then
		  d="$d/${f##*/}"
		fi
		ta=$(ssh -n "$h" "find '$f' -printf '%s'")
		ta=$[ta]
		if [ $ta -eq 0 ]; then
		  echo fichero "$1" inexistente, inaccesible o vacío
		  exit 1
		fi
		if [ ! -f "$d" ]; then
		  dp="${d%/*}/.${d##*/}.$(date +%s)$$"
		  trap "mv '$dp' '$d'" exit
		  # aquí empieza lo importante
		  dd bs=1 seek=$ta count=0 if=/dev/null of="$dp" 2>/dev/null
		  n=$[ta/20/bs+1]
		  for ((i=0; i<ta/bs; i+=n)); do
		    ssh -n "$h" "dd if='$f' bs=$bs skip=$i count=$n 2>/dev/null" |
		    		dd conv=notrunc bs=$bs seek=$i of="$dp" 2>/dev/null  &
		    sleep 5;
		  done
		  wait
		  # hasta aquí
		  trap exit
		  mv "$dp" "$d"
		fi
		rsync -e ssh -a -p "$1" "$d"
	  
Responde:
  1. ¿qué hace cada ssh del bucle for?
  2. ¿por qué sleep 5?
  3. ¿cuántos ssh puede llegar a haber a la vez?
  4. ¿qué objetivo puede perseguir tantos ssh simultáneos?
  5. ¿para qué el rsync al final?
  6. si lo pruebas, este script no te funcionará sobre al.nisu.org. cambia sleep 5 por sleep 60 y prueba a ver.

El comando
rsync -e ssh -aP MAQ:archivo .
nos trae el archivo de la máquina remota. Explica qué hace el comando:
rsync -e "ssh MAQ" -aP "":archivo .
y por qué ¿Podrías forzar un strace de ambos rsync?

Razona lo que hace el comando

rsync -e "ssh -A MAQ_INT ssh" -aP MAQ:archivo .
y por qué es necesaria la opción -A. Lo mejor para entenderlo es que lo pruebes.
Tengo un archivo de 200Gigas en dos máquinas y en una de ellas el archivo ha crecido 20bytes, el resto sé que está igual. Quiero actualizarlo en la otra y dispongo de una línea de comunicaciones penosa ¿Es rsync una buena elección?
Ejecuto ssh al.nisu.org ls y me muestra el contenido de mi cuenta. ¿Por qué no me ha pedido password? Resp.
Estoy usando autentificación mediante un par de llaves y, o no tengo password en la llave privada, o he cargado la llave en ssh-agent.
Ejecuto rlogin nombredeordenador y "entro" directamente, pero no tengo fichero .rhosts. ¿Por qué me ha dejado entrar?. Resp.
Porque me ha autorizado /etc/hosts.equiv.
El ordenador B tiene una IP pública, accesible por Internet. El ordenador C está en una red interna con B, accesible desde él pero no desde Internet. En A, conectado a Internet, tengo acceso ssh a B con un par de llaves y la misma llave pública (id_rsa.pub) está en C. Dí como ejecutar un comando en C desde A via ssh, usando el par de llaves. Resp.
	  eval $(ssh-agent)
	  ssh-add
	  ssh -A B ssh C comando
	  
Si ssh es una mejora de rsh, ¿qué interes puede seguir teniendo el usar este último? Resp.
Es mucho más ligero. En sistemas donde se realizan de forma automática muchos shells remotos, es útil. Además en entornos de confianza es muy fácil configurarlo (hosts.equiv) para que todos los usuarios puedan emplearlo sin tener que hacer nada.
Tengo una cuenta en un ordenador y quiero que un amigo pueda listar mis ficheros remotamente y que otro amigo pueda ver el contenido de /tmp,pero no quiero darles acceso total a mi cuenta, sólo dejarles hacer eso. Indica una forma clara de hacerlo. Resp.
Vía ssh, puedo indicar en authorized_keys que ciertas llaves pueden acceder a mi cuenta pero sólo ejecutar un commando, poniendo algo como:
command="ls" ssh-rsa AAAAB............PPsKEZk= pepito@jame
Tienes un archivo de 700 Mbytes y quieres enviarlo a unos (digamos entre 20 y 50) ordenadores a los que tienes acceso shell y que están interconectados (entre ellos y contigo) via ADSL con IP fija. El caudal de entrada efectivo es de 20kbytes y el de salida de 10kbytes y tienes que conseguir difundir el archivo a todos los equipos en 25 horas, partiendo de la base de que el ADSL no va a tener cortes de ningun tipo. Explica cómo lo harás. Resp.
El caudal que me limita es el de salida. A 10Kby son 70.000 segundos, es decir casi 20 horas, luego sólo puedo transmitirlo desde mi ordenador a otro. Pero al mismo tiempo éste puede enviarlo a un tercero, y éste a un cuarto, etc. El retraso añadido es pequeño teniendo en cuenta que puedo trabajar en todos los ordenadores a la vez.
Si uso rsync, deberé usar un bucle en cada ordenador, pues los archivos no estarán enteros. Es realmente complejo, porque además, rsync usa nombres de archivo temporales imprevisibles. Podria ser algo como:
	  ord_ant=elmio
	  ln -s fichero temporal.$$
	  for ord in otro_ord otro_mas ... ; do
	    ssh -f $ord "
	      while true; do
		rsync -L -e ssh -a --partial $ord_ant:temporal.$$ fichero &
		sleep 1m
		[ -f .fichero.* ] || break
		rm -fs temporal.$$
		ln -s .fichero.* temporal.$$
		wait
	      done
	      rsync -e ssh -a --partial $ord_ant:fichero .
	    "
	    sleep 2m
	    ord_ant=$ord
	  done
El script no está probado, así que seguramente tendrá algún error. Parte de que tengo un acceso shell sin password, es decir usando un par de llaves. Aunque no lo he explicado en clase, debería usarse la nueva opción --inplace para evitar estar copiando el archivo continuamente y todo el lío de los links que probablemente acabe fallando.
Un método más fácil parece trocear el fichero en muchos trozos pequeños, y en cada ordenador poner un bucle que transmita todos los archivos pequeños usando rsync. Debe ser un bucle porque igual que antes, comenzaré a transmitir de un ordenador a otro cuando sólo haya un archivo. Puede ser igual de difícil que el otro de implementar y he de calcular cuidadosamente el tamaño del archivo por el retraso inicial inducido. Quizá el mejor método es este:
	  ord_ant=elmio
	  $tam=$(find fichero -printf %s)
	  for ord in otro_ord otro_mas ... ; do
	    ssh $ord "ssh $ord_ant 'tail -c +1 -F fichero | head -c $tam' > fichero" &
	  done
	  wait
	  for ord in otro_ord otro_mas ... ; do
	    ssh $ord "rsync -e ssh -a --partial --inplace $ord_ant:fichero ." &
	  done
	  wait
Éste método aprovecha las características del tail -f que espera incluso a que el fichero exista. El head asegura que el comando terminará. Estos comandos pueden usarse porque el enunciado dice que no hay cortes en la transmisión. El último rsync es sólo para asegurarnos de que ha ido bien.
Tienes en casa tres conexiones ADSL con un caudal de entrada efectivo de 20kbytes/segundo cada una. Tres amigos tuyos tienen (cada uno) online una copia de un video de 2horas que rodásteis en una fiesta y lo quieres ver en tiempo real dentro de 15 minutos. El archivo tiene 360000 Kbytes. Propón un método para poder hacerlo. No puedes usar emule, bittorrent o programas similares. Dispones de acceso ssh a los ordenadores de tus amigos. Resp.
Debo conseguir descargar 360000k en 7200 segundos, es decir a 50kbytes/segundo, lo que implica usar los 3 ADSL a la vez. Primero que nada establezco una ruta TCP/IP a cada amigo por un adsl distinto. Divido "mentalmente" el archivo en trozos de 1 Megabyte y del primero tomo los trozos 1,4,7,etc, del segundo los trozos 2,5,8,etc y del tercero los trozos 3,6,9, etc. Un método bastante malo de hacerlo es:
	  ini=0
	  for ord in am1 am2 am3 ; do
	    for ((i=$ini, i<360, i=i+3)); do
	      ssh $ord "dd bs=1024000 if=archivo skip=$i count=1" |
		dd seek=$i bs=1024000 of=archivo count=1 conv=notrunc
	    done &
	    ini=$[ini+1]
	  done
	  
El método es malo porque hago 120 ssh a cada ordenador. Puedo hacerlo con 1 ssh a cada uno:
	  ini=0
	  for ord in am1 am2 am3 ; do
	    ssh $ord "
	      for ((i=$ini, i<360, i=i+3)); do
		dd bs=1024000 if=archivo skip=\$i count=1
	      done" |
	    for ((i=$ini, i<360, i=i+3)); do
	      dd seek=$i bs=1024000 of=archivo count=1 conv=notrunc
	    done &
	    ini=$[ini+1]
	  done
	  
Esto no funciona, averiguar por qué. Una vez resuelto el problema, en cualquier caso me convendría, al final, hacer:
	  rsync -e ssh -aP am1:archivo .
	  
por si acaso.
Tengo un disco duro que contiene 70 archivos de tipo MP3 de 1 Gbyte cada uno. Tengo que transferirlos a otro ordenador vía Internet en menos de una semana y para ello dispongo sólo pero en exclusiva (es decir, sólo para eso) de una línea ADSL que me permite transferir a 128Kbps (Kbit por segundo). Propón un método razonable para hacerlo, que sea resistente a los cortes de la línea ADSL. Resp.
128 kbps me da para 16Kbytes por segundo, realmente ni 14. Pero 70G>70.000.000Kbytes, es decir que necesito como poco 70000000/16 segundos = 50 días. O sea, que no puedo hacer la transferencia en una semana de ninguna manera, use el programa o el método mejor del mundo.
Estoy de vacaciones una semana en un pueblo donde no tengo acceso a Internet en casa, pero hay acceso en la plaza del pueblo, lento pero seguro, la velocidad de descarga es de aprox 10kbytes por segundo. Tengo un portátil que no se apaga nunca y mis familiares suelen llevarlo a la plaza para navegar, dos veces al día durante media hora. Quiero descargarme un archivo que tengo en un servidor. El archivo tiene 150 Mbytes y quiero aprovechar las idas y venidas de la familia para hacer la descarga, sin que ellos tengan que hacer nada. ¿Qué puedo hacer? Si la conexión de la plaza, además de ser lenta, sufriera cortes muy frecuentes (cada 30 segundos más o menos), ¿qué podría hacer? Resp.
A 10k, necesito 150.000/10/3600 < 5 horas para hacer la descarga. Como la conexión es buena, aunque lenta, podrá seguir descargando donde se quedara gracias a rsync. Como rsync se cortará cada vez que el portátil vuelva a casa, debo hacer un bucle:
	  while ! rsync --bwlimit=8 -aP servidor:archivo . ; do sleep 1m; done
	  
Cada vez que se corta rsync, da un error, espera un minuto y reintenta. Cuando acabe con éxito saldrá del bucle. Basta con abrir un terminal en el portátil, poner el bucle y rogar a la familia que no se lo carguen. Si no limito el ancho de banda, se quejarán, a 8kbyt me da tiempo para la descarga.
Si la conexión sufre cortes frecuentes, la cosa está difícil. No puedo usar rsync con las opciones típicas, porque antes de empezar a transmitir datos transmite los md5 de los frangmentos para saber lo que le falta por transmitir, con lo que es posible que en 30 segundos no le de ni tiempo a sincronizar. Puedo forzar a que rsync use bloques para md5 de tamaños grandes, pero forzaré muchas restransmisiones de datos si en la media hora de Internet no se trnsmiten bloques completos. Otra alternativa es usar un bucle con rsync --append y al final, cuando haya descargado, hacer rsync normal con bloque grande por si acaso, ya que el --append da pocas garantías. Nota: para el bucle de rsync necesito autenticación automática, con par de llaves, por ejemplo vía ssh-agent.
Tienes acceso ssh como usuario no administrador a un ordenador A que está detrás de un cortafuegos que sólo permite acceso ssh desde B, que es donde tú estás trabajando. Necesitas abrir una sesión VNC desde B contra A. Explica una forma de hacerlo. Resp.
Método 1: Supongamos que el puerto 5901 está libre en mi ordenador y en A. Hago: ssh -L 5901:localhost:5901 miuruario@A
Una vez dentro de A hago vncverver para arrancar el servidor VNC. En mi ordenador ejecuto vncviewer localhost:1
Las peticiones al puerto 5901 de mi ordenador se enviarán a A a través de la sessión ssh, por tanto conectaré con el servidor VNC de A. Si el puerto 5901 de mi ordenador no está libre, pero sí lo está por ejemplo el 5905 y en A, al arrancar vncserver me ha asignado el display :2, el comando sería: ssh -L 5905:localhost:5902 miuruario@A y conectaría con vncviewer localhost:5

Método 2: En mi ordenador arranco el visor en modo espera, accedo por ssh a A y allí arranco el server pero que conecte con mi ordenador. Ésto sólo es posible si mi ordenador es accesible desde fuera.

Tienes un archivo con una lista de ficheros remotos de la forma: usuario@maquina:fichero, cada uno en una línea, no hay espacios en blanco. En cada una de las máquinas remotas, en su usuario correspondiente hay una llave pública que te da acceso ssh sin contraseña, es la misma para todos pero la llave privada correspondiente sólo está en uno de ellos. Te vas a casa de un amigo con ese archivo-lista y quieres descargarte todos los archivos de la lista. Explica la forma más rápida de hacerlo y razona la seguridad de la operación. Resp.
Arranco ssh-agent con eval $(ssh-agent) en el ordenador de mi amigo. Accedo con ssh -A a la máquina donde está la llave privada y hago ssh-add de la llave. Salgo de esta máquina y desde el ordenador de mi amigo ejecuto:
	  for f in $(<archivo-lista) ; do
	    rsync -aP $f .
	  done
Después mato el agente con kill $SSH_AGENT_PID
La única consideración de seguridad que debo tener es que mi amigo es totalmente de fiar y no ha hecho nada para copiar la llave privada. En lugar de usar el agente, podría copiar la llave en local y destruirla después, pero es menos elegante.
Cuando hago ssh mollar@nisu.org me dice: "Enter passphrase for key ...", y aunque introduzco mi contraseña de nisu.org, no consigo entrar. Explica claramente las circunstancias que me han llevado a esa situación. Resp.
Me está pidiendo la contraseña de una llave privada, no la de nisu.org. Esto se debe a que allí, el usuario mollar tiene, en authorized_keys, una llave pública que corresponde con la llave privada que tengo aquí, que está protegida con contraseña y me la pide. Normalmente, tras fallar unas veces me pedirá la contraseña de nisu.org.
En mi ordenador ejecuto dd if=/dev/null seek=102400 bs=102400 count=0 of=pepito. Explica la diferencia entre ejecutar después los tres comandos: rsync -e ssh -a opciones pepito nisu.org:, donde opciones sea una de las tres alternativas: -z , -S y -Sz. Al responder especifica si supones una conexión "lenta" tipo ADSL, o una red local rápida. Resp.
La opción -z comprime el fichero y lo transfiere rápidamente. Aquí el fichero ocupa cero bytes y en nisu 10 Gigas. La opción -S lo transfiere de modo que en destino ocupará cero bytes. Con -Sz se transfiere supuestamente más rápido y ocupa cero también en destino. Si la conexión es rápida es posible que -S corra más que -z, si el ordenador tarda más en comprimir que en transmitir. En una conexión lenta, será claramente al revés.
Un amigo tiene una cuenta en una máquina Un*x y en su HOME un fichero que actualiza periódicamente. Ponponle un método que te permita coger el archivo diariamente sin que él te dé acceso pleno a su cuenta. Resp.
Genero un par de llaves (o uso el que ya tenga generado) y le pido que coloque la pública en su fichero authorized_keys, pero que la limite con command a ejecutar cat elfichero. Lo único que tendré que hacer yo es ssh usuariodemiamigo@maquina > copialocaldelfichero
Desde el ordenador ejecuto A un ssh al ordenador B, donde me encuentro que no existe el directorio .ssh. Ejecuto desde B un ssh al ordenador C. Explica qué es lo que sucede. Si no me pide password para ir de B a C, ¿qué explicación hay?. Resp.
El comando ssh de B creará el directorio .ssh en B, con los permisos adecuados. Luego me avisará de que no conoce al ordenador C, me mostrará la huella de su llave pública, y tras aceptarlo me autenticará. La única explicación de que no me pida contraseña es (aparte de que C esté mal configurado) que desde A he ejecutado ssh -A B y entonces en B tengo acceso, vía el agente, a una llave que me está dando acceso a C.
Tienes que transferir un fichero muy grande a otro ordenador, tienes mucho ancho de banda pero tienes limitada la velocidad por conexión y el espacio en disco en el destino está muy ajustado. Dí una forma de resolverlo, con detalles completos de implementación. Partimos de que hay acceso ssh. Resp.
Basta con realizar un script similar al anterior:
	  f=$1; h=$2
	  bs=10240
	  ta=$[$(wc -c <$f)]
	  n=$[ta/20/bs+1] # 20 conexiones, pueden ser más
	  for ((i=0; i<ta/bs; i+=n)); do
	    dd if=$f bs=$bs skip=$i count=$n |
	         ssh -n $h "dd conv=notrunc bs=$bs seek=$i of='$f' 2>/dev/null" &
	  done
	  rsync -aP $f $h:
Si se quiere evitar la fragmentación del disco remoto, antes del for:
	  ssh -n $h "dd if=/dev/zero bs=$bs count=$[ta/bs+1] of='$f'"
Otra solución, si se dispone de conexión ssh a la inversa, es conectarse al otro ordenador y desde él, traer el fichero justo con el mencionado script.
Soluciones del tipo "lo parto en trozos con rar" no sirven porque no cabe en el destino.
Tengo en casa un router ADSL que hace SNAT, por lo que su IP en la red local es 192.168.0.1, es decir no es accesible desde Internet. El interfaz web de configuración del router sólo es accesible desde esa IP, por lo que no puedo acceder desde fuera de casa. No obstante el router también realiza DNAT sobre un ordenador de la red local de casa, de modo que si hago un ssh a la IP del router, es como si lo hiciera a ese ordenador (ver el ejemplo de los apéndices). Explica como podrás acceder desde Internet al interfaz web del router. Resp.
Basta con ejecutar ssh -L 8000:192.168.0.1:80 -fN IP_pública_del_router , de modo que si accedo con el navegador a http://localhost:8000 me aparecerá la interfaz web deseada.
Las copias de seguridad en este ordenador se hacen con la llamada:
/root/cpsec.sh aRaiz 30 /home /copias
ejecutada periódicamente, donde /root/cpsec.sh es este script:
	  #!/bin/bash -x
	
	  set=$1; shift
	  dias=$1; shift
	  bck=${!#}
	
	  LANG=es_ES@euro; export LANG
	
	  cd ${0%.sh}.d || exit 1
	
	  lishoy=$(rsync -aPxu $* --delete -n | sed -ne 's=^deleting ==p');
	
	  echo "$lishoy" >$set.$(date +%s)
	
	  rsync -axub --suffix=~~$(date +%s) $*

	  olis=$(find $set.* -mtime +$dias)
	  [ "$olis" ] || exit
	
	  ab=$(find $set.* -mtime -$dias)
		
	  (IFS=$'\n'
	  for f in $lishoy; do
	    for b in $ab; do
	      if ! grep -q '^'"$f"'$' $b ; then
	        continue 2
	      fi
	    done
	    rm "$bck/$f" 2>/dev/null
	    rmdir "$bck/$f" 2>/dev/null
	  done)
	
	  echo "olis" | xargs -r rm -f
	  
Responde:
  • Explica con palabras qué hace el script.
  • Explica cuantas copias viejas puede llegar a haber de un archivo.
  • Da un comando que liste las copias viejas.
  • Haz un script que haga prácticamente lo mismo con 2 líneas.
Resp.
  • Mantiene una copia idéntica de los directorios origen (en este caso /home) en el destino en este caso (/copias/home). Los archivos borrados o modificados no se borran, sino que se mantienen dirante 30 días, en el caso de los modificados con un nombre diferente, añadiendo al final la fecha en segundos según ~~$(date +%s). Cada vez que se ejecuta el script se guarda una lista de los archivos que deberían ser borrados en ese momento si no se quisieran guardar. Para decidir que un fichero debe ser borrado, se comprueba que está en todas las listas de los últimos 30 días y entonces se borra. La variable set (en el ejemplo aRaiz) se emplea para poder mantener en /root/cpsec.d las listas de diferentes ejecuciones de /root/cpsec.s.
  • Si el script se ejecuta n veces al día, se guardan hasta 30*n copias, cosa que sucedería si un mismo archivo se modifica siempre entre dos copias.
  • find /copias/ -regex '.*~~[0-9]+'
  • Al llamar a rsync con --delete puedo poner un filtro que evite que borre las copias viejas: -f "P *~~*". Aprovechando que el ctime cambia al renombrar un archivo, el comando find sólo borrará aquellos archivos renombrados hace más de 30 días y que cumplan el patrón establecido:
    	  #!/bin/bash -x
    	  dias=$1; shift
    	  bck=${!#}
    	  rsync -qaxb --delete --suffix="~~$(date +%s)" -f "P *~~*" $*
    	  find "$bck" -regex ".*~~[0-9]+" -ctime +$dias | xargs -d '\n' -r rm -v
    ¿Es idéntico el funcionamiento al del otro script? Suponiendo que el script se invoca cada hora, ¿cómo puedes saber, después de una invocación, qué archivos han sido copiados o renombrados?
Los ordenadores A, B y C tienen conexión a 1 Mbit/s simétrico (en total cada uno) y conectividad SSH entre ellos. Desde A quiero enviar un archivo de 1Gbyte a B y a C y tengo que hacerlo en menos de 3 horas. Explica una forma de hacerlo. Se requieren los comandos exactos que ejecutarás. Resp.
La transferencia del archivo de A a B son casi 3 horas, por lo que tengo tengo que transferirlo de B a C tal y como lo recibo. Una forma burda e inmediata de hacerlo es: Desde A: scp -p archivo B: y en B while true; do rsync -aP archivo C: ; done
El bucle de Rsync es necesario porque el archivo en B va creciendo. Es muy ineficiente, se mejora mucho con --append, para no recalcular la integridad del archivo cada vez, aún así es muy tosco, pero fácil de hacer. Esto responde correctamente a la pregunta.

No obstante, una forma más elegante es: Elijo un puerto en B y C, por ejemplo 4500 y primero ejecuto en C nc -l -p 4500 >archivo de modo que lo que entra por el puerto 4500 se guarda en el archivo. En B ejecuto nc -l -p 4500 | tee archivo | nc C 4500 de modo que lo que entra por el puerto 4500 se guarda en el archivo y se reenvía a C. En A simplemente nc B 4500 <archivo. Lo interesante de está opción es si no tengo acceso a ningún puerto que no se a el SSH, entonces tengo que tunelar: En A ejecuto ssh -fN -L4500:localhost:4500 B y en B ssh -fN -L4500:localhost:4500 C. Con ello ya tengo acceso y ejecuto los comandos anteriores, pero sobre localhost.

Deseo mantener en otro ordenador una copia idéntica de un árbol de directorios de mi ordenador, pero quiero que se guarden en el destino las versiones viejas de los archivos durante 5 días. Explica cómo lo haré ejecutando sólo comandos desde mi ordenador, buscando la posibilidad de automatizarlo. Tengo acceso ssh. Resp.
Basta con modificar ligeramente el script anterior:
	  rsync -qaxb --delete --suffix="~~$(date +%s)" \
	      -f "P *~~*" dir_local máquina_remota:dir_contenedor
	  ssh máquina_remota "find dir_contenedor/dir_local \
	      --regex '.*~~[0-9]+' -ctime +5 | xargs -d '\n' -r rm"

DNS, sistema de nombres de dominios ^

Para referirnos a un ordenador, según hemos visto en el promer tema, especificamos su IP. Pero las funciones que realiza un ordenador o la información que suministra, nada tienen que ver con su IP, por lo que es difícil recordar las IPs de los ordenadores a los que accedemos.

Para hacer más intuitiva la identificación de ordenadores, el Sistema de Nombres de Dominio provee la facilidad de asociar nombres a IPs, de modo que es más sencillo recordar, por ejemplo, www.uji.es que su IP, para referirnos al servidor Web de la UJI.

El sistema de nombres de dominios en Internet es un sistema distribuido, jerárquico, replicado y tolerante a fallos. Aunque parece muy difícil lograr todos esos objetivos, la solución no es tan compleja en realidad. El punto central se basa en un árbol que define la jerarquía entre los dominios y los sub-dominios. En un nombre de dominio, la jerarquía se lee de derecha a izquierda. Por ejemplo, en www.uji.es, el dominio más alto es .es. Para que exista una raíz del árbol, se puede ver como si existiera un punto al final del nombre: www.uji.es., y todos los dominios están bajo esa raíz.

Dominios ^

Los dominios se clasifican en función de su nivel o profundidad dentro del árbol de la jerarquía DNS. De este modo existen dominios de primer nivel, segundo nivel, etc. Dentro de Internet, los dominios de primer nivel están gestionados por organizaciones específicas bien definidas, privadas o de carácter gubernamental. Los dominios de segundo nivel, en general, están gestionados por entidades particulares (empresas, individuos, etc.).

No hay límite en la profundidad del dominio. A los dominios de primer nivel se los conoce como TLD (Top Level Domain). En Internet, existen dos tipos de TLD:

  • Dominios de Nivel Superior Globales (gTLD)
    Creados para ser usados por los usuarios de Internet en general. Tambien son conocidos como Dominios de Internet genéricos. Son usados (al menos en teoría) por una clase particular de organizaciones (por ejemplo, .com para organizaciones comerciales). Tiene tres o más letras de largo. La mayoría de los gTLDs están disponibles para el uso mundial, pero por razones históricas mil (militares) y gov (gubernamental) están restringidos para el uso por las respectivas autoridades estadounidenses. Los gTLDs están subclasificados dentro de los dominios de Internet patrocinados (sTLD), ej. aero, coop y museum, y los dominios de Internet no patrocinados (uTLD), ej. com, net, org. Algunos de los dominios gTLD que se manejan en la actualidad son:
    • No patrocinado: biz, com, edu, gov, info, int, mil, name, net, org
    • Patrocinado: aero, cat, mobi, coop, jobs, museum, pro, travel
    • Infraestructura: arpa, root
    • Fase de inicio: post, tel
    • Propuestos: asia, cym, geo, kid, kids, mail, sco, web, xxx
  • Dominios de Nivel Superior de Código de País
    En inglés ccTLD, country code Top-Level Domain. Son dominios reservados para un país o territorio. Existen unos 243 ccTLDs, tienen una longitud de dos letras, y la mayoría corresponden al estándar de códigos de países ISO 3166-1. Cada país designa gestores para su ccTLD y establece la reglas para conceder dominios. Algunos países permiten que cualquier persona o empresa del mundo adquiera un dominio dentro de sus ccTLDs, por ejemplo Austria (.at) y España (.es). Otros países y territorios dependientes sólo permiten a sus residentes adquirir un dominio de su ccTLD, por ejemplo Australia (.au), Andorra (.ad) y Canadá (.ca).
    Las laxas restricciones de registro para ciertos ccTLDs ha originado nombres de dominio como pagina.de, I.am ('yo soy' en inglés) y go.to ('ir a' en inglés). Otras variaciones en el uso de ccTLDs se han denominado domain hacks, usándose juntos el dominio de segundo nivel y el ccTLD para formar una palabra o título. Esto ha originado dominios como blo.gs de las Islas Georgias del Sur y Sandwich del Sur (.gs), del.icio.us de los Estados Unidos de América (.us) y cr.yp.to de Tonga (.to). (Con este fin también se han usado TLDs no nacionales, como inter.net que usa el TLD genérico .net, probablemente el primero de cuantos se han hecho.)
    Tambien es frecuente el uso de ccTLDs con cambio de significado. El caso más famoso es el de .tv que originalmente pertenecía a Tuvalu y fue vendido a VeriSign por US$45 millones y se utiliza para canales de televisión.
    El dominio .ws perteneciente a Samoa Occidental (West Samoa) se comercializa como web site. La Federación Micronesia vende su dominio para radios FM. Las Islas Cocos también vendieron su dominio, .cc, a Verisign. Se sugiere que los compradores le pueden dar cualquier significado, como por ejemplo, cámara de comercio, circuito cerrado, centro de conferencias, centro comunitario o country club. El dominio de Yibuti o Djibuti es .dj lo que ha sido utilizado en algunos casos para páginas de disc jockeys. El dominio de Turkmenistán, .tm, se usa conjuntamente para sitios web de dicho país y como abreviatura de trade mark, marca registrada.
La lista de ccTLDs a 2009 es ésta.
.ac
Isla Ascensión
.ad
Andorra
.ae
Emiratos Arabes
.af
Afghanistán
.ag
Antigua & Barbuda
.ai
Anguilla
.al
Albania
.am
Armenia
.an
Antillas Holandesas
.ao
Angola
.aq
Antártida
.ar
Argentina
.as
Samoa Americana
.at
Austria
.au
Australia
.aw
Aruba
.az
Azerbaijan
.ba
Bosnia y Herzegowina
.bb
Barbados
.bd
Bangladesh
.be
Bélgica
.bf
Burkina Faso
.bg
Bulgaria
.bh
Bahrein
.bi
Burundi
.bj
Benin
.bm
Bermuda
.bn
Brunei Darussalam
.bo
Bolivia
.br
Brasil
.bs
Bahamas
.bt
Bhutan
.bv
Islas Bouvet
.bw
Botswana
.by
Belarus (Bielorusia)
.bz
Bélice
.ca
Canadá
.cc
Islas Cocos (Keeling)
.cd
República del Congo
.cf
Repúb. Centro Africana
.cg
Republica de Congo
.ch
Suiza
.ci
Costa de Marfil
.ck
Islas Cook
.cl
Chile
.cm
Camerún
.cn
China
.co
Colombia
.cr
Costa Rica
.cs
Checoeslovaquia
.cu
Cuba
.cv
Cabo Verde
.cx
Islas Christmas
.cy
Chipre
.cz
República Checa
.de
Alemania
.dj
Djibouti
.dk
Dinamarca
.dm
Dominica
.do
República Dominicana
.dz
Argelia
.ec
Ecuador
.ee
Estonia
.eg
Egipto
.eh
Sahara Occidental
.er
Eritrea
.es
España
.et
Etiopía
.fi
Finlandia
.fj
Fiji
.fk
Islas Malvinas
.fm
Micronesia
.fo
Islas Faroe
.fr
Francia
.ga
Gabón
.gb
Reino Unido
.gd
Granada
.ge
Georgia
.gf
Guyana Francesa
.gg
Islas Guernsey y otras
.gh
Ghana
.gi
Gibraltar
.gl
Groenlandia
.gm
Gambia
.gn
Guinea
.gp
Guadelupe
.gq
Guinea Equatorial
.gr
Grecia
.gs
Islas Georgia del Sur
.gt
Guatemala
.gu
Guam
.gw
Guinea-Bissau
.gy
Guyana
.hk
Hong Kong
.hm
Islas Heard McDonald
.hn
Honduras
.hr
Croacia
.ht
Haití
.hu
Hungría
.id
Indonesia
.ie
Irlanda
.il
Israel
.im
Islas de Man
.in
India
.io
Territ Brit. Indico
.iq
Iraq
.ir
Irán
.is
Islandia
.it
Italia
.je
Islas Jersey
.jm
Jamaica
.jo
Jordania
.jp
Japón
.ke
Kenia
.kg
Kyrgystán
.kh
Camboya
.ki
Kiribati
.km
Islas Comoros
.kn
Saint Kitts and Nevis
.kp
Corea del Norte
.kr
Corea del Sur
.kw
Kuwait
.ky
Islas Cayman
.kz
Kazakhstán
.la
Laos
.lb
Líbano
.lc
Santa Lucía
.li
Liechtenstein
.lk
Sri Lanka
.lr
Liberia
.ls
Lesotho
.lt
Lituania
.lu
Luxemburgo
.lv
Latvia
.ly
Líbia Arabe Jamahiriya
.ma
Marruecos
.mc
Mónaco
.md
Moldavia
.mg
Madagascar
.mh
Islas Marshall
.mk
Macedonia
.ml
Malí
.mm
Myanmar
.mn
Mongolia
.mo
Macau
.mp
Islas Marianas del Norte
.mq
Martinica
.mr
Mauritania
.ms
Montserrat
.mt
Malta
.mu
Mauricio
.mv
Maldivas
.mw
Malawi
.mx
México
.my
Malasia
.mz
Mozambique
.na
Namibia
.nc
Nueva Caledonia
.ne
Niger
.nf
Islas Norfolk
.ng
Nigeria
.ni
Nicaragua
.nl
Paises Bajos
.no
Noruega
.np
Nepal
.nr
Nauru
.nu
Niue
.nz
Nueva Zelandia
.om
Oman
.pa
Panamá
.pe
Perú
.pf
Polinesia Francesa
.pg
Papua Nueva Guinea
.ph
Filipinas
.pk
Pakistán
.pl
Polonia
.pm
Saint Pierre Miquelon
.pn
Pitcairn
.pr
Puerto Rico
.ps
Palestina
.pt
Portugal
.pw
Palau
.py
Paraguay
.qa
Qatar
.re
Reunión
.ro
Rumania
.ru
Rusia
.rw
Ruanda
.sa
Arabia Saudita
.sb
Islas Solomon
.sc
Islas Seychelles
.sd
Sudán
.se
Suecia
.sg
Singapur
.sh
Santa Helena
.si
Eslovenia
.sj
Svalbard y Jan Mayen
.sk
Eslovaquia
.sl
Sierra Leona
.sm
San Marino
.sn
Senegal
.so
Somalía
.sr
Surinam
.st
Santo Tomé y Principe
.su
Unión Soviética
.sv
El Salvador
.sy
República Arabe Siria
.sz
Swazilandia
.tc
Islas Turks & Caicos
.td
Chad
.tf
Territ. Franceses del Sur
.tg
Togo
.th
Thailandia
.tj
Tajikistán
.tk
Tokelau
.tm
Turkmenistán
.tn
Tunez
.to
Tonga
.tp
Timor Oriental
.tr
Turquía
.tt
Trinidad y Tobago
.tv
Tuvalú
.tw
Taiwán
.tz
Tanzania
.ua
Ucrania
.ug
Uganda
.uk
Reino Unido
.um
Islas Menores USA
.us
Estados Unidos
.uy
Uruguay
.uz
Uzbekistán
.va
Vaticano
.vc
S. Vincente Grenadines
.ve
Venezuela
.vg
Islas Vírgenes UK
.vi
VIslas Vírgenes U.S.A.
.vn
Vietnam
.vu
Vanuatú
.wf
Islas Wallis y Futuna
.ws
Samoa
.ye
Yemen
.yt
Mayotte
.yu
Yugoslavia
.za
Sudáfrica
.zm
Zambia
.zr
Zaire (Congo)
.zw
Zimbabwe

Delegación de autoridad ^

Los dominios de primer nivel correspondientes a los países (ccTLDs) son gestionados por estos a su voluntad. Esto es posible porque estos dominios están delegados en administradores propios al país, de forma que son éstos los que los gestionan. Dicha delegación de autoridad sobre un dominio se puede realizar a cualquier nivel del espacio de nombres, de manera que si una empresa dispone un dominio de segundo nivel, podría crear dominios de niveles inferiores según la estructura organizativa de la empresa.

En concreto, la delegación de autoridad consiste en la cesión del control de una zona del espacio de nombres propiedad de un servidor DNS a otro servidor DNS. Una zona es una porción del espacio de nombres, de forma que se posee autoridad desde el nodo raíz de dicha zona dentro del árbol jerárquico, pudiendo crear o eliminar nuevos subdominios a partir del nivel en el que se encuentre dicho nodo raíz.

La base de datos de los DNS es distribuida: el servidor de DNS de nivel 1 delega autoridad en el servidor DNS de nivel 2 y este a su vez al servidor de nivel 3 y así sucesivamente. Para responder a las consultas, se sigue la cadena de delegación. Normalmente los servidores de DNS tienen un archivo con una lista de los servidores de nivel 1 para poder comenzar a buscar. Esta lista se actualiza periódicamente (una vez al año más o menos).

La diferencia entre dominio y zona suele ser confusa en un principio. Se trata de dos conceptos relacionados en diferentes capas: dominio es un concepto del espacio de nombres, mientras que zona es la forma en la que se distribuye la autoridad.

Así pues, un dominio contiene todas las máquinas que están dentro de dicho dominio, incluidos subdominios, mientras que una zona incluye solo las máquinas del dominio que cuelgan del subdominio sobre el que se posee la autoridad. Podría decirse que las zonas son la forma en la que se distribuye el control sobre el espacio de nombres, y, por lo tanto, que son una causa directa de la delegación de autoridad sobre el espacio de nombre.

La figura muestra una posible división en zonas de nom_dominio.com. La zona 1 se compone del propio dominio y de los dominios cs y ali y sus subdominios. En cambio la autoridad sobre el dominio val que está al mismo nivel que cs y ali, ha sido cedida a otro NS, con lo que él y sus subdominios pertenecen a otra zona.

Resolución directa y resolución inversa ^

Hemos hablado de traducir nombres a IPs. Esto se denomina resolución directa, y es la más frecuente. La resolución inversa, consiste en, dada una IP de Internet, proporcionar el nombre que se le asocia. La resolución inversa se realiza con tablas diferentes a la resolución directa (no consiste en acceder a la misma tabla indexada por una columna diferente), De hecho, si la resolución del nombre nA a la IP I1 la realiza una tabla del servidor ns1, la resolución de la IP I1 puede que la realice otro servidor, con su tabla y el nombre resultante puede no ser nA. Es decir. Además, como vimos enla primera práctica, la relación nombre-IP es de muchos a muchos, produciéndose muchas inconsistencias, aunque a veces son aparentes (ver las cuestiones del tema).

Relación entre servidores ^

El proceso de propagación en el DNS consiste en la difusión de los cambios producidos en dominios de los que se tiene autoridad. Este proceso suele tardar entre 24 y 72 horas (tiempo de latencia), aunque en teoría los cambios deberían ser visibles inmediatamente después de haberlos realizado. Este retraso se debe en la mayor parte a las caché que suelen usar los DNS.

Existen dos tipos de configuraciones para los servidores DNS: recursivos y no recursivos. Será recursivo si el servidor intenta devolver el resultado exacto de la petición recibida, y será no recursivo en caso contrario (cuando no intenta devolver el resultado exacto). Cuando un servidor no es recursivo, lo que hace es devolvernos la dirección del servidor DNS que posee autoridad sobre el siguiente dominio de la petición que le hemos realizado, de forma que cada vez estamos más próximos al servidor autoritativo. Por tanto, el proceso de resolución de nombres con servidores no recursivos es un proceso iterativo y en el que el cliente participa activamente. Por contra, en el caso de usar servidores recursivos el proceso, desde el punto de vista del cliente, es lineal y con una actuación pasiva. Normalmente no suelen configurarse servidores exclusivamente no recursivos (a excepción de los servidores raíz y de muy alto nivel en el espacio de nombres), sino que suelen actuar como recursivos para un determinado conjunto de nodos y como no recursivos para el resto.

Normalmente los servidores recursivos incorporan una tabla caché, de forma que si se les vuelve a preguntar por un dominio del cual han averiguado su IP y el TTL o Tiempo de Vida de la respuesta no ha vencido, no vuelven a realizar la búsqueda, sino que devuelven el resultado anterior. Cuando la resolución se lleva a cabo de esta forma, el servidor DNS que la realiza indica en la respuesta que 'no es autoritativa'. Una respuesta se considera que es autoritativa cuando proviene del servidor que posee autoridad sobre el dominio en cuestión, siendo no autoritativa para el resto de casos. El tiempo TTL de una respuesta viene teóricamente suministrado por el NS que tiene la autoridad.

Así pues, el problema de que la propagación entre servidores DNS tenga una latencia tan grande se debe a que debemos esperar a que el tiempo de vida de la entrada en caché del dominio venza en todos los servidores, de forma que llegará un momento en que será necesario volver a realizar la consulta al servidor que posee autoridad, de forma que éste nos responderá con la respuesta correcta, la cual, de nuevo será introducida en la tabla caché de los distintos servidores. El tiempo de expiración de la caché depende de las implementaciones del software DNS y de su configuración, aunque por lo normal se suele respetar el tiempo de vida indicado por la respuesta DNS del servidor.

BIND ^

El software Berkeley Internet Name Domain o BIND es el software de DNS que goza de mayor difusión en Internet, especialmente en sistemas Linux/Unix, en los cuales es un estándar de facto. BIND se compone de un programa servidor de nombres, llamado named y de una serie de herramientas de consulta.

Para configurar un servidor de nombres es necesario crear un fichero de configuración (habitualmente /etc/named.conf) en el que se especifican las opciones del dominio (ubicación de ficheros, recursividad, etc.) y las zonas definidas en el dominio, así como la ubicación del fichero de configuración de cada zona. La información más importante del fichero named.conf se refiere a las declaraciones de zonasi sobre las que el servidor posee autoridad. Para una zona, el servidor puede ser primario o secundario (maestro master o esclavo slave). Un servidor maestro es el que contiene la fuente principal de datos de una zona, que se guarda en un archivo al que denominamos fichero de zona. Un servidor secundario (para una zona) es aquel que, teniendo autoridad, toma los datos del maestro periódicamente, de modo que si el maestro falla, el esclavo está disponible. El esclavo suele guardar los datos en un fichero de respaldo que él mismo construye.
Desde fuera, un maestro y un esclavo son percibidos como servidores con autoridad sobre la zona, es decir no puede saberse cuál es maestro y cuál esclavo, pues un concepto de BIND.
Veamos cómo es un fichero named.conf a través de un ejemplo:

options {
  directory "/var/lib/named";
  notify yes;
  allow-recursion {
    213.171.249.250/32;
    192.168.0.0/16;
    127.0.0.0/8; };
  allow-transfer {
    213.171.249.250/32;
    80.35.84.125/32;
    127.0.0.0/8; };
  forwarders {
    213.201.48.198;
    150.128.81.251; };
};
La sección options establece las opciones de funcionamiento de named. La directiva directory indica donde están los archivos de zona. La directiva allow-recursion lista de grupos de IPs (usando máscaras) para las que éste servidor es recursivo. Para el resto de IPs no será recursivo. La directiva allow-transfer lista de grupos de IPs autorizadas a obtener volcados de las zonas. Suelen ser los servidores secundarios, o aquellos equipos desde los que admitiremos un comando host -l que vimos en la primera práctica. La directiva forwarders, cuando el servidor actúe como recursivo, antes de intentar una resolución por sus propios medios, lista los servidores a los que éste preguntará (obviamente deben ser también recursivos).
logging {
  category lame-servers {
    null; };
};
La sección logging establece la cantidad de logs que named registra. En el ejemplo, se establece que no registre nada sobre servidores erróneos encontrados.
zone "." {
  type hint;
  file "root.hint";
};
La sección zone declara una zona, su nombre va entre comillas y no necesita el punto final, se presupone. La zona "." es de un tipo (type) especial denominado hint y establece que el archivo especificado con la directiva file contiene la lista de los servidores raíz, necesaria cuando el servidor debe actuar como recursivo (forwarders aparte).
zone "mobelt.com" {
  type master;
  file "master/mobelt.com";
};
zone "asgn.com" { type slave; file "slave/asgn.com"; masters { 213.98.42.173; };
};
Para resto de zonas el tipo es master o slave. Para las zonas que se declara maestro, es necesario dar el fichero donde se encuentra la definición de la zona. Para las zonas que se declara esclavo, es necesario dar unalista de IPs de los maestros y, opcionalmente, un fichero de respaldo.
zone "168.192.in-addr.arpa" {
  type master;
  file "master/168.192.in-addr.arpa";
};
Este extraño nombre de zona define una zona de resolución inversa. Para ello se usa el sufijo reservado .in-addr.arpa. Los números especificados determinan el rango de IPs para el que estamos definiendo la resolución inversa, en orden contrario. En el ejemplo, 168.192 indica que se va a definir autoridad sobre las IPs 192.168.0.0/16. Obsérvese la escasa flexibilidad para definir la resolución inversa, no pueden especificarse rangos de IPs más detallados. Para resolver el problema, dada la escasez de IPs (IPv4) en la actualidad, se pueden incluir máscaras para refinar la delegación como explica el RFC2317.
key dyn.mia {
  algorithm HMAC-MD5;
  secret "gvcn43v518=";
};
zone "dyn.nisu.org" { type master; file "dyn/dyn.nisu.org"; allow-update { key dyn.mia;
};
};
Ésta es la forma de definir una zona de actualización dinámica. Primero se especifica la llave que permitirá la actualización y en la definición de la zona, se establece que puede ser actualizada dinámicamente y con qué llave. Las zonas de actualización dinámica permiten que su contenido sea modificado sobre la marcha, sin necesidad de recargar el servidor de nombres.
La sintaxis del archivo es sencilla pero estricta. Obsérvese la necesidad de los ";" después de los corchetes "}".
Ficheros de zona ^
Cada fichero de zona contiene registros de recursos que definen los parámetros de la zona asignando los nombres e ip's en el espacio de nombre de la zona. A diferencia de named.conf, la sintaxis es orientada a líneas. Se pueden escribir comentarios en los ficheros de zona después de los puntos y comas (";").

Todos los nombres que se usan en los registros de recursos y que no acaban por un punto (.) se añaden al nombre de dominio.

Los registros de recursos de ficheros de zona contienen columnas de datos, separadas por espacios o tabuladores, que definen estos registros. Si la primera columna está vacía, se asume que es la misma de la línea anterior. Si es @ es sinónimo del nombre de la zona que se está definiendo. Como antes, expliquemos la sintaxis con un ejemplo para la zona mobelt.com:

$TTL 300
En la versión 9 de BIND es obligatorio especitifar el TTL de los nombres de la zona mediate una línea de esta forma.
@         IN SOA mobelt.com.
root.mobelt.com. ( 158 ; serial number 10800 ; time to refresh 3600 ; time to retry 604800 ; expire 86400 ; mínimum TTL )
Definimos para el propio dominio (@) el registro SOA (Start Of Authority), indicando el nombre del dominio y la dirección de mail de contacto. A continuación siguen 5 valores entre paréntesis, todos ellos en segundos si no se especifica lo contrario. El valor serial number debe incrementarse cada vez que cambia el fichero de zona con el fin de que se propagen los cambios a los esclavos. El valor time to refresh dice a todos los servidores esclavos cuánto tiempo tienen que esperar antes de preguntar al maestro por cambios de zona, usando entonces el serial number para saber si hay cambios.
La opción time to retry informa al servidor de nombres esclavo sobre el intervalo de tiempo que tiene que esperar antes de emitir una petición de actualización de datos en caso de que el servidor de nombres maestro no le responda. Si el servidor maestro no ha respondido a una petición de actualización de datos antes que se acabe el intervalo de tiempo time to expire responde el servidor esclavo presentándose como servidor con la autoridad en este espacio de nombres.
La opción minimum TTL pide a cualquier servidores de nombres que guarde en caché la información de esa zona durante al menos ese periodo.
Las unidades de tiempo son segundos pero pueden usarse múltiplos, como m, h, d y w con significados obvios
          IN NS    dns.mobelt.com.
IN NS dns2.mobelt.com.
Al comenzar por espacio los registros hacen referencia al mismo que la línea anterior (@) y establecen los NS que sirven a este dominio. Obsérvese el punto al final, teóricamente debe ser un FQDN (full qualified domain name), aunque en la práctica podría usarse un nombre relativo.
          IN A     89.128.67.11
El registro de tipo A asigna una IP, en este caso al propio dominio.
          IN MX 10 mail
IN MX 20 mail2
Indica que el correo de este dominio es manejado por mail.mobelt.com con prioridad 10, su significado lo veremos en el tema del correo.
dns       IN A     150.128.97.91
dns2 IN A 213.98.42.173
mail IN A 89.128.67.11
mail2 IN A 213.98.42.173
Totalmente necesario asignarles una IP, puesto que se están usando en la definición de propiedades del dominio.
www       IN A     89.128.67.11
pelis IN A 89.128.67.11
Definimos cuantos nombres queramos, en este caso www.mobelt.com y pelis.mobelt.com
litus     IN A     89.128.67.11
www.litus IN A 89.128.67.11
Definimos si queremos dominio de cuarto nivel en esta misma zona. Además estamos usando la misma IP para todos, no es problema.
pepe      IN NS    ns.soypepe.com.
Perdemos autoridad sobre pepe.mobelt.com, delegándola al servidor especificado.
otro      IN NS    ns.otro
ns.otro IN A 94.23.10.112
Igual que antes, pero esta vez la delego a un servidor que está dentro de la misma zona delegada, ns.otro.mobelt.com, por lo que debo definir aquí su IP.
pop       IN A     150.128.97.91
IN A 150.128.97.92
El servidor POP está muy cargado, definimos dos IPs para él. Nuestro NS las devolverá en orden aleatorio y los clientes normalmente se quedan con la primera de ellas. Así se obtiene un sencillo balanceo de carga.
*         IN A     89.128.67.11
Con esto definimos que cualquier nobre no definido previamente en mobelt.com tiene esa IP.
Resolución inversa ^
Los ficheros de resolución inversa tiene igualmente registro SOA y registros NS. Para definir una IP, basta con especificar por ejemplo, para el archivo 168.192.in-addr.arpa, que hemos especificado anteriormente en nuesto named.conf de ejemplo, un registro PTR que indica el nombre asociado a la IP (debe ser un FQDN).
3.30      IN PTR   portatil-eth.casa.
Acabamos de definir que la IP 192.168.30.3 resuleve al nombre portatil-eth.casa.
IPV6 y named ^
En el acso de IPV6, se utiliza AAAA para definir direcciones y para la resolución inversa, el nombre de la zona se da con el sufijo .ip6.int, por ejemplo:
zone "1.0.8.0.e.f.f.3.ip6.int" {
type master;
file "3ffe:0801";
};
Ejemplos aquí.

La resolución de nombres en un ordenador ^

Cuando abrimos el navegador y accedemos a una página de un servidor usando su nombre, ¿cómo invoca el navegador al NS?. El navegador usa una librería para la conversión del nombre a IP, libresolv, que opera del siguiente modo. En primer lugar consulta el fichero /etc/nsswitch.conf, que normalmente le indica que en las consultas del DNS debe consultar primero ficheros locales y después el DNS. El fichero local consultado es /etc/hosts, un fichero que contiene una tabla de IPs y nombres (relación uno a muchos). Si éste fichero no resuleve la consulta, accede a /etc/resolv.conf que tiene este aspecto:
nameserver 1.2.3.4
nameserver 6.7.8.9
search patata.com
La directiva nameserver indica qué servidores de nombres debe usar, en el orden especificado (consulta al siguiente sólo si uno falla o no da la respuesta). La directiva search indica el sufijo por omisión, es decir, ese sufijo es añadido al dominio buscado.

Cuestiones del tema ^

Explica en términos generales pero con precisión como realiza un ordenador una consulta al DNS. Resp.
El ordenador primero determina qué servidor debe utilizar en base a la configuración del sistema (en Un*x mira /etc/resolv.conf) y conecta con él vía UDP por el puerto 53. Envía un registro de petición con la interrogación que desea hacer. El servidor normalmente es recursivo y tratará de darle la respuesta final.
Explica la diferencia entre el comportamiento de un servidor de nombres recursivo y uno no-recursivo. Resp.
El recursivo, al ser preguntado, da la respuesta final. El no-recursivo, nos dice a qué otros servidores hay que preguntar.
El nombre www.uji.es, ¿corresponde a un dominio o a un ordenador?. Explícalo bien. Resp.
A ambos. El nombre www.uji.es es un dominio que resuelve entre otras cosas un número de IP, que está asignada a un determinado ordenador, por lo que las aplicaciones que consultan el DNS (casi todas) al acceder awww.uji.es, accederán a ese ordenador.
Dado un nombre de dominio, pregunto al DNS qué IP le corresponde. Ante la respuesta, le pregunto qué nombre corresponde a esa IP y la respuesta no coincide con el dominio inicial. ¿Es normal?. Razona la respuesta. Resp.
Normal del todo. Ejemplo 1: Un ISP da servicio a muchos dominios con una sola IP. Al preguntar la resolución inversa de la IP nos dará normalmente uno sólo, que puede que incluso no sea ninguno de los del ISP sino del propietario de la línea (consultar mobelt.com). Ejemplo 2: Tienes un ADSL en casa, compras un dominio y le asignas la IP de tu ADSL, la resolución directa es tuya, la inversa es un nombre del pool de Telefónica (consultar www.vbreva.com).
Monto un DNS en mi ordenador (tengo una IP fija de Internet) y establezco que tiene autoridad sobre el dominio ejemplito.com, al que asigno una IP. Intento acceder desde mi ordenador al dominio y funciona, pero no funciona cuando mis amigos intentan acceder con sus ordenadores. Explica por qué con precisión (hay diversas causas aunque una muy obvia). Resp.
No tengo autoridad sobre ese dominio, no he acudido a un registrador para solicitarla.
Las normas de Internet para dominios .com establecen la necesidad de usar dos servidores de nombres por dominio. ¿Podemos usar un master (primario) y un slave (secundario)? En caso afirmativo, cuando se pretenda resolver un dominio .com, ¿cuál se consultará primero?, es decir, ¿cuál tiene preferencia? Resp.
No sólo podemos, sino debemos usar un esquema master-slave como el que suministra el programa named. Desde fuera, los dos servidores se ven igual (el concepto master-slave no es del sistema de nombres, sino de named), de modo que en principio (si no hay otra causa), se consultarán ambos indistintamente.
Tengo autoridad sobre el dominio patata.com y he montado los dos DNS necesarios, uno master y otro slave y están funcionando perfectamente. Un día cambio la IP asociada a www.patata.com y me pasa que al cabo de unas horas otros servidores de nombres, dan la información correcta de esa IP, pero al cabo de más horas vuelven a dar la IP antigua. ¿Qué puede estar pasando?. Resp.
El servidor slave no se ha actualizado correctamente. Cuando caduca el TTL, esos otros servidores DNS vuelven a preguntar la IP, unas veces al slave y otras al master obteniendo resultados diferentes. El fallo puede estar en no haber actualizado el número de serie de mi zona cuando cambié la IP o a algún fallo en la configuración necesaria para que el slave se actualice correctamente.
En casa, en mi ordenador, tengo un servidor de nombres montado para tomate.com y funciona perfectamente, con la debida autoridad,i pero cuando desconecto de internet el ordenador no es capaz de resolver los nombres de tomate.com, pese a que el DNS está en mi propio ordenador. ¿Por qué puede ser?. Resp.
Que tenga un DNS en mi ordenador no quiere decir que mi ordenador utilice ese DNS. Debo indicar en /etc/resolv.conf que use a mi DNS.
En un fichero de configuración de DNS encuentro la línea:
	  pepe	IN	NS 1.2.3.4
Es correcta? Resp.
No, un servidor de nombres en un campo NS siempre debe ser un nombre, no vale una IP, es decir sería algo como:
	  pepe		IN	NS	dns.pep
	  dns.pepe	IN	A	1.2.3.4
Tengo en el ordenador personal de mi casa un DNS correctamente configurado, que declara ser propietario (master) de uji.es.. Este DNS responde en internet y es el legítimo DNS principal de dominios como faciles.org.. Explica la repercusión que puede tener el falsear la propiedad de la zona uji.es.. Resp.
Dependerá de quien use ese DNS en su resolver, es decir de quien lo use para resolver los nombres. Puedo ser yo mismo (o no), pueden ser otros ordenadores de la red local, por ejemplo. Los que lo usan se verán afectados, los que no lo usan, aunque lo consulten para otros dominios legítimos, como faciles.org., no se verán afectados.
Explica con claridad la diferencia entre los conceptos del DNS: dominio y zona. Usa ejemplos si lo crees necesario. Resp.
El concepto de dominio es un tema de nomenclatura y la zona es un tema de autoridad sobre nombres. Los dominios son la forma jerarquizada que tenemos de nombrar lo que existe en Internet, y se componen de palabras separadas por puntos. Cada dominio se traduce vía los servidores de nombres en información, como por ejemplo una IP. Una zona es un concepto del servidor de nombres, no de los nombres en sí (a diferencia del dominio). Inicialmente la zona agrupa a todos los (sub)dominios que están debajo de un dominio dado, pero puede contener (sub)dominos de varios niveles de jerarquia por debajo del inicial, y por otra parte no contener ciertos subdominos de los que delega autoridad a otro servidor de nombres.
Por ejemplo, el servidor dns.mobelt.com. tiene autoridad sobre todo el dominio nisu.org, pero mirando este fichero de zona, vemos que contine subdominios de 4 nivel, como *.al, y al mismo tiempo delega autoridad de la zona dyn a otro servidor de nombres, (en este caso coincide ser el mismo), pero en una zona diferente, de actualización dinámica, que es la usada en la práctica del DNS, como puede verse también en el fichero de configuración.
Cuando ejecuto host patata.com unas veces me sale una (sola) IP y otras veces otra. ¿A qué puede deberse? Justifica bien la repuesta. Resp.
Probablemente el dominio patata.com tiene dos servidores de nombres que están desincronizados y cada uno da una respuesta diferente. Como los servidores de nombres de un dominio no tienen prioridad unos sobre otros, unas veces se está consultando uno y otras veces otro.
En el fichero de zona del DNS con autoridad sobre xyz.com encuentro, entre otras cosas, esta línea:
	  domi. IN NS 150.123.45.67
Di todos los errores que hay. Resp.
No puedo definir domi. , debería evitar el punto al final, pues domi. es un dominio de primer nivel en Internet fuera de la zona. Además no puedo poner como NS una IP, debe ser un nombre.
Averigua el comportamiento del sufijo especificado en /etc/resolv.conf con la directiva search. Es decir, si preguntas por un dominio, ¿consulta los DNS primero y si falla añade el sufijo y vuelve a consultar? ¿o lo hace al revés?.
Partiendo del ejemplo visto para la zona mobelt.com, supón que en en el servidor ns.otro.mobelt.com definimos la IP del mismo diferente a la que hemos definido en nuestro servidor. ¿Qué sucederá? Si has realizado los ejercicios complementarios de la práctica puedes experimentarlo con la zona amigo.alxxxxxx.dyn.nisu.org.
Me instalo un DNS y me doy autoridad sobre microsoft.com y digo que el dominio www.microsoft.com tiene la IP de mi ordenador. Pero cuando accedo a www.microsoft.com con el navegador, me sale la página de Microsoft, no la de mi ordenador que es la que yo esperaba. ¿Qué está pasando? Resp.
Para que la autoridad tenga algún valor es necesario que alguien la consulte. En este caso, como no es autoridad legítima sólo valdrá si me configuro en /etc/resolv.conf el nameserver apuntando a la IP de mi ordenador. Es decir, que lo que me pasa es que mi ordenador no usa mi propio DNS.
La empresa X registra el dominio patata666.com (correctamente, es decir, pagando) y especifica que los servidores de nombres de ese domino son dns1.patata666.com y dns2.patata666.com, cuyas IPs son 1.2.3.4 y 1.2.3.5 . Explica cómo se configura el servidor de nombres de .com para hacer esta delegación. Un tiempo después la empresa registra el dominio jamon666.com y usa esos mismos servidores de nombres, pero al cabo de unos meses el domino patata666.com caduca, no pagan y se borra el dominio. ¿Qué pasará con jamon666.com? Son varias las respuestas posibles, explica todas las posibilidades, bien razonadas y descarta las que no sean razonables. Resp.
El propietario del DNS de .com pondrá en su zona:
patata666 IN NS dns1.patata666.com
patata666 IN NS dns2.patata666.com
dns1 IN A 1.2.3.4
dns2 IN A 1.2.3.5
Al borrar patata666.com hay dos posibilidades:
  • Al borrar patata666.com se borran también dns1.patata666.com y dns2.patata666.com, con lo que jamon666.com queda sin resolución de nombres hasta que le asignemos un nuevo DNS.
  • Como jamon666.com depende de dns1.patata666.com y dns2.patata666.com, al borrar patata666.com no se borran los dns. Así jamon666.com sigue funcionando. Esto es absurdo, pues si alquien registra de nuevo patata666.com se creará una contradicción. Nota: esta situación absurda se producjo en el ES-NIC a finales de los 90 con el dominio infc.es, increíble :-)
Una zona es servida por dos DNS que tienen autoridad sobre ella, ambos con BIND, uno es master y el otro slave y todo está correctamente configurado. En un momento dado, se apaga el master y al cabo de unas horas, expirados los TTL, con el master apagado, se reinicia el slave. Explica cómo afectará ello a la resolución de nombres de esa zona en función de la configuración (dos opciones). Resp.
Depende de si el slave emplea un fichero de backup o no. Si no lo emplea, al reiniciar, no tiene información, la solicita al master, pero éste no responde por lo que la resolución de nombres no funciona para esa zona. Si el slave emplea un fichero de backup, como antes del apagado se supone bien configurado, el fichero contiene la zona intacta, por ello, al reiniciar el slave, la resolución de nombres de la zona vuelve a funcionar bien.

El correo electrónico ^

El correo electrónico es una de las palicaciones más antiguas de Internet y de las más interesantes, pues a diferencia de la mayoría, el usuario trabaja sin conexión, es decir, que las personas que se comunican no tienen por qué estar simultáneamente conectadas.
El correo electrónico se asemeja notablemente al correo postal tradicional. Cuando queremos mandar una carta escrita en papel a alguien, la redactamos tranquilamente en casa, la metemos en un sobre timbrado, escribimos cuidadosamente la dirección del destinatario y la llevamos a una oficina postal para que llegue a su destino. A partir de ahí, los servicos de correo se encargarán de que llegue a su destino. El cartero intentará llegar al destinatario repetidas veces. Si no lo encuentra, la carta volverá al remitente y, si lo encuentra, se pondrá en su buzón. El destinatario la leerá cuando quiera.

Las direcciones de correo

Evidentemente necesitamos especificar de alguna forma quién es el destinatario de nuestros envíos. Debemos considerar que puede ser cualquier persona con el adecuado acceso a Internet. Las direcciones de correo tienen la forma nombre@dominio. Por nombre entendemos normalmente la identificación de una persona, pero puede representar otras figuras (p.e. un programa). Este nombre pertenece a un dominio, que puede ser cualquier domnio válido. Hablamos de dominio en el sentido general, es decir un dominio propiamente dicho o una máquina determinada.

Las direcciones se pueden expresar, para mayor intuitividad, en la forma: descripción <nombre@dominio>. La descripción es ignorada por los servicios postales, pero permite mayor claridad para el usuario. Realmente la dirección que va entre < y > puede ser más complicada, algo de la forma <@dominio1,@dominio2:nombre@dominio>. Aquí se especifica la ruta (relays)por la que ha de pasar un correo, es decir que en lugar de intentar ir al destino final directamente, deberá pasar por los manejadores de correo de los dominios previamente especificados. Para comprender correctamente estas ideas es necesario conocer el funcionamiento real del correo.

Funcionamiento ^

Cuando queremos enviar un correo a alguna dirección redactamos el mensaje mediante el programa adecuado, denominado agente de usuario de correo (MUA), escribimos la dirección del remitente y le pedimos al programa que lo envíe. El MUA conecta entonces con un agente de transporte (MTA), siguiendo el modelo cliente-servidor. Se establece un diálogo SMTP, que es el protocolo usado para el envío del correo, por el que el MUA le indica al MTA el remitente y el destinatario, que constituyen el envoltorio.

El MTA, que suele estar en un ordenador diferente del de usuario, intenta enviarlo al destinatario, que es otro MTA, emplendo SMTP. Si no puede conectar con el MTA destino, no es problema. EL MTA mantiene una cola de mensajes salientes donde se encuentran los mensjaes que no se han podido enviar. Periódicamente procesa la cola e intenta enviar los mensajes. Si pasan varias horas sin conseguir enviar un mensaje, se manda un aviso al remitente (si así está configurado). El MTA intenta enviar el mensaje durante varios días y si no lo consigue, envía un error al remitente y deja de intentarlo. Lo habitual en la práctica es que mensajes pequeños llegan en pocos minutos.

Para el agente de transporte es importante saber a qué ordenador debe entregar el mensaje. Esta información la obtiene del DNS. Toma el dominio de la dirección destino y si el DNS:

  • sólo le indica una IP, conecta con esa IP.
  • le indica un registro de mail (MX), ignora la IP y conecta con el ordenador indicado en el registro MX.
  • le indica varios registros MX, intenta con el de mayor prioridad (valor más bajo). Si no puede conectar, intenta el siguiente y así sucesivamente.
Una vez el mensaje ha llegado al ordenador destino, allí el MTA invoca a un agente de reparto que deposita el mensaje en el buzón del destinatario, eliminando el envoltorio. Un buzón es normalmente un fichero (o conjunto de ficheros en el esquema Maildir) donde se van depositando los mensajes. No obstante no es extraño que el buzón no exista físicamente sino que sea un programa que puede procesar el correo en el momento de recibirlo.

Depositado el mensaje en el buzón, el usuario destinatario, para leerlo, debe acceder al buzón. Puede que tenga acceso directo sobre el sistema de archivos, pero eso no es lo habitual. Lo normal es que el destinatario emplea un ordenador propio para leer el correo y conecta con el ordenador que "tiene" los buzones con algún protocolo específico, como son POP3 e IMAP.

SMTP básico ^

El transporte básico de mensajes SMTP (Simple Mail Transfer Protocol) es el estándar para el intercambio de mensajes utilizando el protocolo TCP/IP y esta definido en el RFC 2821. En temas de seguridad, la autenticidad es escasa y la confidencialidad nula; en cambio la disponibilidad (puedo mandar un correo independientemente de que destinatario esté conectado o no) y la integridad (los cortes de red no le afectan) son mayores que en los demás servicios.

Actualmente está definido el ESMTP (SMTP extendido), mucho más complejo, pero podemos ver las bases de SMTP con un ejemplo:

telnet mail.mobelt.com 25
Conectamos con un MTA, puerto 25. El prgrama telnet nos permite realizar una sesión SMTP a mano.
220 ESMTP mobelt
El MTA responde con un código numérico y un mensaje. Esta numeración sigue un estándar que está presente en otros protocolos:
  • 2XX: funciona correctamente
  • 3XX: hay un error pero se puede recuperar de forma automática
  • 4XX: error que requiere una intervención (ej. se requiere autenticación)
  • 5XX: error sin solución (el buzón no existe, el buzón ha agotado el espacio disponible)
helo mobelt.com
250 mobelt.com
Saludamos. Si el saludo es con el comando ehlo indicamos que solicitamos ESMTP.
mail from: prueba1@nisu.org
250 2.1.0 Ok
Especificamos el envoltorio, la direción del remitente. Muchos MTA realizan muy diversas medidas anti-spam, por ejemplo, comprueban si existe el dominio del remitente.
rcpt to: prueba2@mobelt.com
250 2.1.5 Ok
Dirección de destino. Ahora se aplican reglas de relaying.
data
354 End data with <CR><LF>.<CR><LF>
Indicamos que vamos a introducir el mensaje, el MTA nos dice que debemos terminarlo con una línea conteniendo sólo un punto.
Subject:ejemplo smtp

Hola
.
El mensaje.
250 2.0.0 Ok: queued as A74C14D5BF
El MTA ha aceptado el mensaje para reparto local (en este caso) o para reenvío. Lo encola, y normalmente lo procesa inmediatamente.
quit
221 2.0.0 Bye
Con este comando terminamos la sesión y el servidor nos desconecta.

Relays, spam ^

Hemos comentado que el correo electrónico imita el correo tradicional en papel. Pero hay una diferencia clara: para enviar un mensaje no es necesario pagar, a diferencia del correo en papel, que cada carta lleva su timbre con un coste.

Esta pequeña diferencia, que supuso una gran ventaja económica en los primeros años de Internet, justamente ha resultado en cierto nivel de caos en el correo electrónico, pues muchas empresas envían correo no deseado a millones de destinatarios, es el denominado spam. Igualmente, virus y troyanos envían masivamente correo, de modo que entre virus y spam suponen más del 50% del correo que circula.

En la línea de imitar el correo tradicional, históricamente, los MTA de Internet estaban abiertos para dar servicio a cualquiera, a usuarios y a otros MTAs, pero esto era el paraíso para los spammers, que usaban los MTA para disponer de colas gratuitas para los reintentos. El spam ha hecho que estos relays abiertos hayan desaparecido y actualmente los MTA utilizan unas reglas para decidir a quien dan servicio, es decir para quién actuan como relay. El algoritmo correcto es el siguiente:

Si el receptor es local (es uno de los dominios para los que tengo buzones)
Aceptar
Si no
Si la IP del cliente está autorizada
Aceptar
Si no
Si el cliente se autentica
Aceptar
Si no
Rechazar
Con éste método sólo se deja enviar correo a ciertos ordenadores (por IP) y a los que usuarios que se autentican. Por supuesto el correo propio debe de admitirse.

Además de este control imprescindible, los MTA toman medidas antispam, entre las que cabe mencionar:

  • Consultar la IP del cliente en listas de spammer (como spamcop).
  • Rechazar las tripletas (IP cliente,dirección origen, dirección destino) desconocidas con un error 4XX, forzando que el cliente reintente. Si es un MTA legítimo, reintentará, y entonces la tripleta se almacena en una base de datos de modo que no vuelve a rechazarse a no ser que no se produzca la tripleta en bastante tiempo, por ejemplo 3 días. Esta técnica se denomina greylisting.
  • Analizar el contenido de los mensajes para detectar spam. Esto es bastante delicado, pues se dan falsos positivos. Las técnicas más usadas son la búsqueda de indicios (ciertas palabras, estructura del mesnaje, etc.) y el análisis estadístico (bayesiano).
  • Uso de marcas de autenticidad de los servidores. La más sencilla es el SPF, que es un campo de texto (IN TXT) que se coloca en el DNS e indica, explicado muy simplemente, qué servidores están autorizados para mandar correo con un determinado dominio remitente (ejecuta host -t txt nisu.org para ver un ejemplo). Otro caso de marca de autenticidad es el que emplea gmail, denominado DKIM-Signature, que es una verdadera firma digital realizada por el servidor de correo saliente y que se incluye como un campo en la cabecera del correo (para ver un ejemplo, basta con ver el "código fuente" de un correo que nos envien desde gmail).

POP3, IMAP, Webmail ^

Cuando el propietario de un buzón desea leer el correo que hay en él, necesita acceder al buzón de alguna manera. Los protocolos POP3 e IMAP dan este servicio. POP3 es un protocolo adecuado para que podamos bajar todo el correo de golpe, aunque puede bajar los mensajes uno a uno. Se emplea principalmente en conexiones con módem en las que el tiempo de conexión cuesta dinero. De las posibilidades que el POP permite, los agentes suelen ofrecer:
  • Bajar todos los mensajes y borrarlos del servidor.
  • Bajar sólo los no leídos y no borrar ninguno del servidor. Podrá borrarlos selectivamente después.
El inconveniente principal es que debe leerse el correo principalmente desde un mismo ordenador, pues el correo se "descarga" del servidor POP al ordenador del cliente. Otro inconveniente habitual es que, si se ha recibido un mensaje largo, habrá que esperar a que el agente lo traiga desde el buzón para poder ver siquiera de qué tratan los mensajes posteriores. Esto es un problema de cómo los agentes usan el POP, no del protocolo en sí mismo, hay agentes que descargan por orden de tamaño del mensaje.
Para observar las limitaciones del protocolo, veamos cómo es una sesión básica POP:

telnet anubis.uji.es pop3
Conectamos a un servidor POP3 mediante telnet.
user mollar
pass torpedo
Proceso de autenticación. La contraseña se envía en claro.
list
+OK 3 visible messages (163026 octets)
1 34325
2 3631
3 21426
Solicitamos la lista de mensajes. Nos devuelve los mensajes numerados, normalmente en el orden en que están en el buzón, indicando el tamaño de cada uno. Obsérvese que no conocemos ni remitent, ni asunto, etc.
retr 3
dele 3
Obtenemos el mensaje número 3 y lo borramos.
quit
Desconexión.

IMAP es más potente y eficaz, pero su uso es sólo conveniente cuando el coste de la conexión no va en función del tiempo y podemos estar leyendo los mensajes mientras estamos conectados. La gran ventaja del IMAP es que los mensajes están siempre en el servidor. Cuando el agente se conecta, obtiene la lista de las cabeceras de los mensajes y las muestra al usuario. Éste puede entonces ver asunto y remitente y ello le permitirá leer selectivamente los mensajes y no tener que esperar a traer mensajes largos. Incluso si un mensaje lleva distintos objetos MIME (adjuntos), IMAP bajará (descargará del servidor) sólo la lista de objetos, pudiendo el usuario seleccionar cuáles quiere ver. Otra facilidad importante de IMAP es que permite manejar múltiples buzones auxiliares en el mismo servidor. Estos buzones los define (los crea) el usuario y los utiliza para clasificar los mensajes que quiere guardar. IMAP permite mover un mensaje de un buzón a otro, de modo que al leer el buzón principal (denominado usualmente buzón de entrada, Inbox en inglés), el usuario va enviando los mensajes a los distintos buzones. De hecho, los agentes potentes permiten clasificar automáticamente los mensajes recibidos simplemente al acceder al buzón de entrada. Para ello se especifican unos criterios (reglas) que en base a los campos de la cabecera determinan a qué buzón auxiliar han de enviar los mensajes.
Una descripción detallada del protocolo excede los limites de este documento.

Lo que acabamos de describir es familiar para los usuarios habituales de Wbmail (gamil, hormail, yahoo, etc.). Realmente lo que sucede es que un Webmail no es más que un cliente SMTP e IMAP que en lugar de estar instalado en nuestro servidor, corre en un servidor Web. EL usuario se conecta con su navegador a ese servidor Web, que corre una aplicación web que es cliente de algún servidor SMTP y de algún servidor IMAP.

Agentes de transporte ^

En el mundo Un*x, el primer MTA que fue ampliamente utilizado fue Sendmail. Su presencia llegó a ser universal, pero tenía graves problemas de seguridad por estar programado con escaso cuidado, aparte de utilizar internamente un esquema suid en lugar de un esquema cliente-servidor. Actualmente otros MTAs como Postfix, Exim, o Qmail presentan mayor estabilidad aun sin alcanzar la versatibilidad de la configuración de Sendmail.
Todos estos MTAs, aparte de realizar las funciones requeridas que hemos explicado al describir los fundamentos del correo, aportan otras funcionalidades requeridas por los complejos sistemas de correo:
  • Permiten especificar filtros aplicables al correo y basados en diversos criterios
  • Disponen de complejos esquemas de tablas que permiten especificar operaciones específicas para correos específicos. Por ejemplo, una tabla de transporte que en función por ejemplo del dominio destino, podrá elegir un relay distinto. Estas tablas pueden ser almacenadas de distintos modos, incluso contra motores de base de datos como MySQL.
La influencia de Sendmail fue tal que los demás programas mantienen compatibilidad en opciones y formatos. Concretamente Sendmail, además de actual como MTA, podía actuar como programa en línea de comandos para enviar correo, usándose a sí mismo como MTA. Muchos programas de entornos Un*x, no necesariamente programas de correo, invocan al programa sendmail para enviar correo, de modo que los desarrolladores de otros programas, como Postfix han desarrollado un programa sendmail para garantizar la compatibilidad. El programa sendmail (en cualquiera de sus diferentes implementaciones) como cliente es muy interesante, pues permite el envío de correo "a bajo nivel", en el sentido de que apenas interfiere en el formato del mensaje, sólo se preocupa en enviarlo. Algo como:
echo test | sendmail alguien@dominio.com
enviará un correo conteniendo sólo la palabra test a esa dirección de correo. Como veremos en breve, todo correo debe tener una cabecera. El programa sendmail añadirá una cabecera mínima a ese correo, donde sólo figurará el remitente que obtendrá de los datos del usuario que ejecuta el comando y del nombre de la máquina donde lo ejecuta. La ejecución de:
echo $'Subject: prueba\n\nHola' | sendmail -f yo@midominio.com alguien@dominio.com
enviará un correo con "asunto" y con remitente cambiado a yo@midominio.com. En ambos ejemplos es interesante observar que el destinatario no se incluye en la cabecera, lo que viola el RFC822, pero permite enviar el mismo correo a varios destinatarios de un golpe.

Formato del mensaje ^

Un mensaje se compone, como hemos indicado, de un envoltorio, que controlan los agentes de transporte, más un contenido que se divide en una cabecera y un cuerpo que viajan juntos y están relacionados.i
Cabeceras
La cabecera es una parte con fines de control. Se compone de una serie de líneas y se separa del cuerpo por una línea en blanco. Cada una de sus líneas tiene la estructura: campo: valor. Si una línea comineza en blanco se entiende continuación de la anterior. Los campos más relevantes de una cabecera son:
  • To: Indica el destinatario del mensaje. Obligatorio, aunque si no se especifica los MTA lo admiten.
  • Cc: Lista de las direcciones de correo que recibirán una "copia de carbón del mensaje" (Copia Identica). Opcional.
  • Subject: Describe el contenido del mensaje (asunto).
  • Date: Indica fecha y hora en que envió el mensaje (según el emnisor).
  • Reply-To: Especifica la dirección a la que el remitente desea que se le conteste. Este campo es opcional.
  • Return-path: Dirección de retorno en caso de que el envío falle.
  • From: Dirección del correo del remitente y posiblemente su nombre (en la forma descrita antes).
En la práctica la diferencia entre To y Cc es cosmética. Además no necesitan estar presentes para que el correo llegue a su destino, pues el destinatario, donde debe especificarse siempre es, como hemos visto, en el envoltorio.
El campo Bcc es un campo de los clientes de correo, no del protocolo. Insta al cliente a añadir direcciones destino en el envoltorio sin incluirlas en la cabecera.
Podemos inventarnos campos en la cabecera, respetando el estándar, simplemente precediendo su nombre por X-, por ejemplo X-Loop: si.
MIME ^
El cuerpo del mensaje es el contenido en sí. No obstante el estándar de correo permite a los MTA cambiar el contenido según su conveniencia sin alterar el significado, de modo que sólo pueden emplearse caracteres ASCII de 7 bit y sólo a partir del código 32 (el espacio), aunque actualmente la mayor parte de agentes admiten 8 bit (otros 128 caracteres). Es decir el mensaje debe ser sólo texto sencillo. Además las líneas del mensaje no deben sobrepasar 1kbyte, se recomienda usar líneas de 72 caracteres. Si no se respetan estas reglas (que también se aplican a la cabecera), el MTA puede, literalmente, destrozar el cuerpo del mensaje.

Estas restricciones impiden enviar objetos no-texto a través del correo, pues inicialmente se concibió para texto simple. A medida que se detectó la necesidad de enviar otros objetos, como imágenes, en lugar de alterar el comportamiento de los MTA que hubiera sido un caos, se optó por buscar métodos de codificación para convertir objetos binarios a texto. Un método clásico en Un*x fue uuencode. Algunos clientes como Eudora optaron por sus propios formatos, en este caso muy ineficientes, pues la conversión de binario a texto implica un aumento de tamaño que debe ser lo menor posible.

La solución definitiva es el estándar MIME. Su uso permite que se puedan intercambiar a través del correo todo tipo de contenidos. Además, una parte importante del MIME está dedicada a mejorar las posibilidades de transferencia de texto en distintos idiomas y alfabetos. MIME va a implementar el concepto ofimático de adjunto (que no es un componente del correo), de modo que un texto puede ir acompañado de una imagen y además el receptor será informado de que es una imagen y de como ha sido codificada para poder decodificarla y tratarla (por ejemplo mostrarla) debidamente.

En primer lugar, un mensaje MIME se identifica por la presencia en la cabecera del mensaje del campo: MIME-Version: 1.0. El único campo que es obligatorio es el que indica el tipo de contenido del mensaje: Content-Type: tipo/subtipo. Los tipos MIME están estandarizados (aunque mediante x- pueden añadirse nuevos). A modo de ejemplo citemos:

  • text/plain: texto común, sin formato. En los tipos texto suele indicarse el juego de caracteres empleado.
  • text/html: texto HTML
  • application/pdf: un archivo PDF. El tipo es application porque los PDF son propios de ciertas aplicaciones.
  • application/octet-stream: tipo genérico que indica binario desconocido, es decir una serie de bytes generados por alguna aplicación.
  • multipart/mixed: un mensaje que se compone de varias partes MIME, como explicamos a continuación.
  • message/rfc822: el contenido es otro mensaje de correo, con sus propias cabeceras y cuerpo. Se emplea para correos literalmente reenviados.
A priori se sobreentiende que el mensaje está sin codificar, es decir en 7 bit (u 8bit, es lo mismo). Pero como esto no es adecuado para ciertos objetos, como imágenes, el campo Content-transfer-encoding indica cómo se ha codificado. Los formatos existentes son:
  • 7bit: tal cual, sin codificación.
  • quoted-printable: sólo se codifican los caracteres no compatibles con 7bit, cada uno se codifica con un signo = seguido de dos dígitos hexadecimales del caracter a codificar. Debe emplearse cuando hay pocos caracteres a codificar, pues por cada caracter codificado tripica el espacio usado.
  • base64: como un binario es base 256, se realiza un cambio de base a 64, empleando un conjunto de 64 carcateres que se imprimen perfectamente. Como 2^8=256 y 2^6=64, incrementa en 8/6=4/3 el tamaño de un objeto, es decir un 33%. Debe emplearse en objetos calramente binarios, como imágenes, videos, etc.
Según esto, el comando:
/usr/sbin/sendmail <<-EOF tudireccion@tudominio
	  Subject: prueba
	  MIME-Version: 1.0
	  Content-Type: text/plain; charset=iso-8859-1
	  Content-transfer-encoding: base64

	  aG9sYQo=
	  EOF
te enviará el saludo hola. Tu lector de correo sabrá que es texto sencillo y lo mostrará tras decodificar el base64.

Cuando el tipo MIME es multipart, el cuerpo del mensaje se compone de varias partes, delimitadas por un separador. Cada una de las partes es como un pequeño mensaje, debe tener su cabecera con su tipo MIME y su cuerpo. El tipo de cualquiera de las partes puede ser otro multipart, con lo que se crea una estructura recursiva en forma de árbol de profundidad arbitraria. Normalmente los lectores de correo realizan un recorrido infijo del arbol a la hora de mostrarlo al usuario.
El multipart más corriente es el multipart/mixed, que representa una serie de partes formalmente inconexas. Este tipo es el que se emplea para implementar el concepto ofimático de adjunto: cuando mandamos un mensaje con un programa de correo y adjuntamos una foto, realmente se crea un multipart/mixed con dos partes, un texto y una imagen. Realmente el concepto de adjunto no existe a nivel MIME. El formato del mensaje lo podemos ver con un ejemplo:

	  MIME-Version: 1.0
	  Content-Type: multipart/mixed; boundary=unafraseunica

		***Lo que va aquí debe ser ignorado por el lector de correo.***

	  --unafraseunica
	  Content-Type: text/plain; charset=iso-8859-1
	  Content-Transfer-Encoding: quoted-printable

	  Este mail lleva una peque=F1a imagen
	  --unafraseunica
	  Content-Type: image/gif; name="sound2.gif"
	  Content-Transfer-Encoding: base64
	  Content-Disposition: inline

	  R0lGODlhFAAWAMIAAP///8z//8zMzJmZmWZmZjMzMwAAAAAAACH+TlRoaXMgYXJ0IGlzIGlu
	  IHRoZSBwdWJsaWMgZG9tYWluLiBLZXZpbiBIdWdoZXMsIGtldmluaEBlaXQuY29tLCBTZXB0
	  ZW1iZXIgMTk5NQAh+QQBAAABACwAAAAAFAAWAAADUBi63P7OSPikLXRZQySmGyF6UCgKV8md
	  m/FFHHqRVVvcNOzdSt7sr4CPMRS6VC8bsmcADIrMT/M5VBo3QYkzh81ufTce0Zph7sqMcBDN
	  XiQAADs=
	  --unafraseunica--
Como se aprecia el separador se precede por dos guiones -- y el último además termina con dos guiones. Es importante observar el espaciado: el cambio de línea antes del separador se ignora, es decir, forman parte de la parte MIME anterior todos los cambios de línea que hay antes del separador menos el último. En el ejemplo, la parte text/plain no tiene ningún salto de línea al final.

Algunos agentes, al componer un texto que se desea enviar, pueden emplear facilidades propias de las páginas web, es decir, que componen el mensaje exactamente como una página web, utilizando para ello el lenguaje HTML. Pero puede que este mensaje no lo pueda leer cualquier otro agente, con lo que optan por enviar tanto una versión HTML como una versión texto, y que el receptor elija la que más le convenga. Esto se consigue especificando el tipo multipart/alternative, que se estructura exactamente como el multipart/mixed. Es decir, las partes que contiene un multipart/alternative llevan todas la misma información, el MUA elije una u otra en función de sus habilidades.

Otra costumbre habitual es enviar verdaderas páginas web que contienen imágenes, que también van incluidas en el correo y no deben mostrarse como adjuntos, sino incrustadas en el mensaje. Este efecto se consigue con el tipo multipart/related, que indica que sus distintas partes están relacionadas y deben interpretarse como un todo. Para relacionar las partes, éstas llevan un campo Content-ID:<identificador> y que se referencia especificando la URL cid:identificador. Por ejemplo en el caso de una página web con dos imágenes, el mensaje multipart/related tendrá tres partes, una de ellas text/html que será la página web, que referenciará a las imágenes con <img src="cid:un_dentificador">. Las otras dos partes MIME serán las imágenes, cada una con su identificador. Puede verse un ejemplo en los apéndices.

Por último mencionar el multipart/signed, empleado para realizar firma electrónica (S-MIME) y cifrado de datos. El objeto de los mensajes cifrados es que sólo el receptor autorizado pueda leer el contenido del mensaje, tan sólo quedaría en claro el Subject del mismo. Se implementa mediante un objeto PKCS7, cuya estructura excede el ámbito de este documento, y su tipo MIME es application/x-pkcs7-mime (ver apéndices.).
El objeto de los mensajes firmados es garantizar el origen del mensaje, mediante la firma electrónica del emisor. La implementación puede realizarse simplemente mediante un objeto PKCS7, pero el resultado sólo podría leerlo alguien que dispusiera de un lector con capacidad criptográfica. Por ello, usualmente un mensaje firmado es un multipart/signed que se compone de dos partes, la primera es el mensaje y la segunda la firma electrónica de la primera parte, es decir del mensaje que queremos firmar. Pueden verse los detalles en el apéndice.

Cuestiones del tema ^

El fichero de zona del dominio pepito.com, aparte del SOA, el NS y el TTL, sólo tiene estas dos líneas:
	  @	IN MX 10 mail.pepito.com
	  mail	IN A 192.192.192.192
Si mandamos un correo a jate@pepito.com, ¿a dónde irá a parar?. Resp.
A ningún sitio, porque el host mail.pepito.com.pepito.com. no está definido.
Explica que realiza el siguiente comando (netcat es similar a telnet):
echo "user lukas
	  pass pelucas
	  dele 1
	  quit" | netcat localhost 110
Resp.
Se envían una serie de comandos al puerto 110 del ordenador donde se ejecuta la orden. Estos comandos pretenden realizar una sesión POP3, autenticando al user lukas, borrando un supuesto primer mensaje y finalizando la sesión. Pero un protocolo es un diálogo y "nuestro cliente" no atiende las respuestas, como que el usuario puede no existir o no hay mensajes. El único error que podríamos controlar es conexión rechazada. Realmente netcat no es muy explicito en un rechazo de conexión. En caso de conectar los errores los mostraría en el propio terminal. Suponiendo que no haya errores, es decir que lukas autentique correctamente y que haya un primer mensaje que borrar, probablemente no funcione en la mayoria de servidores POP por no esperar la respuesta de la ejecución de un comando antes de mandar el siguiente.
Explica cómo sabe un agente de correo (SMTP) a qué ordenador debe entregar el correo que va dirigido a un determinado dominio. Resp.
Consulta los registros MX de ese dominio y elige el de mayor prioridad. Realmente si no hay registros MX se consulta a ver si el dominio tiene una IP.
Envío un correo usando como agente SMTP mi propio ordenador. Observo la cola de correo y en pocos segundos veo que el mensaje ya no está. El registro del sistema me dice que ha sido enviado. Pero el receptor del correo me asegura que en su servidor no ha entrado, ni hay rastro de un intento de entrar. Explica donde puede estar el mensaje. Resp.
Si el registro de salida me dice que se ha enviado y el receptor del correo me asegura que no ha entrado en el servidor destino, debo mirar atentamente el registro de salida para observar que por algún motivo se ha enviado a un relay intermedio y no al destinatario.
¿Por qué no puedo enviar una imagen jpeg por correo codificada en 8 bit? Resp.
Probablemente en una imagen (interpretada byte a byte), aparezcan muchos caracteres del código ascii que no soni admitidos por los agentes de transporte y que serían eliminados o convertidos, suponiendo la destrucción parcial o completa del objeto jpeg.
¿Qué interés puede tener colocar un antivirus que detecte virus de Windoze en un servidor de correo Un*x?. Resp.
Los clientes de esos servidores suelen usar el Windoze cuando leen el correo, así que es un servicio adicional recibir los correos libres de virus en la medida de lo posible.
Explica claramente la diferencia entre una dirección de correo y un buzón de correo. Resp.
La dirección de correo es donde se entregan los correos y el buzón donde los recoge el destinatario. Suele haber una asociación uno a uno , de modo que habitualmente el correo dirigido a una dirección se deposita en un buzón. Pero también puede ser reenviado a otra o atendido por un programa, y en ambos casos no existiría el buzón asociado a esa dirección. A la inversa, podemos crear buzones de correo que no correspondan con ninguna dirección de correo y que se rellenan mediante filtros del cliente de correo a partir de un buzón de correo principal.
¿Qué precauciones habrá que tomar al montar un sistema de autorespuesta (tipo 'estoy de vacaciones') para el correo? Resp.
Principalmente deberé comprobar que el mensaje que quiero autoresponder no me lo envía un demonio (MAILER-DAEMON), que no hay un campo en la cabecera que indique que el mensaje es a su vez autorespuesta (X-Loop) y al enviarlo insertaré yo el campo X-Loop en la cabecera, con la confianza que otroas mecanismos de autorespuesta harán lo mismo que yo.
Tienes que enviar un archivo de 200 Mbytes por correo. Explica como lo harás. Resp.
A fecha de hoy no es muy razonable mandar un mail de 260 megas. Lo más inmediato es dividir el archivo usando rar o zip y enviar los trozos por separado con un mismo subject o con un campo en la cabecera. El receptor los podrá unir y aprovechar que rar y zip pueden volverlos a unir y detectar cualquier error en el conjunto.
	  rar .... opciones de rar para que fragmente .... fichero
	  for f in ficheros_fragmento; do
	    (formail -I 'X-mio: envio'; uuencode $f) | sendmail dirección
	  done
El receptor puede acumularlos en un buzón filtrando con procmail:
	  :0
	  *^X-mio: envio
	  estebuzon
y después:
	  formail -s uudecode <estebuzon
	  unrar ....
Otra forma de hacerlo es usar el tipo MIME message/partial, soportado por ejemplo por Outlook express. Mediante un programa como el mismo Outlook o el clásico splitmail, el mail inicial de mas de 260 megas se cortará en trozos que serán automáticamente recompuestos en el cliente cuando estén todos. No obstante convendría comprimir el archivo antes de mandarlo, con la intención no sólo de reducir espacio, sino sobre todo de dar un mecanismo de verificación de la integridad del material recibido.
Personalmente prefiero el primer método, aunque sea algo más engorroso, porque si alguno de los archivos rar se corrompiera o se perdiera, puedo construir archivos pequeños de paridad y mandárselos para que pueda reconstruir el original. Las versiones recientes de rar permiten construir archivos de paridad o puedo emplear el programa par2 (freeware). Además, muchos antivirus rechazan el tipo message/partial por no poder scanear el archivo.
Quiero que el correo de internet enviado a @midominio.com vaya a mi ordenador, que tiene como IP la 192.168.1.2 porque está en una red interna. Cuento con que el ordenador (de ésta red) con IP 192.168.1.1 tiene otra IP que es pública de internet, tiene un nombre válido en internet, un servidor de correo y el administrador es amigo mío. Propón al menos un método para que el correo llegue a mi ordenador. Resp.
Dos métodos:
  • Método malo: a midominio.com le pongo como primer MX mail.midominio.com que el DNS resuelve a la IP 192.168.1.2. Y pongo como segundo MX el ordenador de mi amigo, el nombre que resuelva a la IP pública, no a la privada. Le pido a mi amigo que haga relay de midominio.com. Cuando alguien me mande mail, no podrá conectar con 192.168.1.2, lo mandará al segundo MX que me lo reenviará a 192.168.1.2. El método no es muy bueno porque se producirán timeouts, pero es muy fácil de configurar y cualquier servidor de correo lo permite.
  • Método correcto: el servidor de correo de mi amigo permite configurar un mecanismo de transporte para que el correo que recibe a midominio.com lo reenvie a mi ordenador. Entonces pongo para midominio.com un único MX apuntando a la IP pública del ordenador de mi amigo, y él comfigura su ordenador para dicho reenvío, aparte de activar el relay.
El correo del domino patata.com debe tener como estafeta destino el ordenador A que sólo dispone de IP privada, es decir, no es accesible desde Internet. En su misma red hay un ordenador B que tiene una IP válida de Internet (bien conectado) con un servidor de correo configurado para hacer relay de patata.com. Propón una forma para que el correo desde cualquier punto de Internet llegue al ordenador A. Resp.
Es la misma pregunta de antes, sólo que con otra redacción. El servidor de correo de B se configura para hacer relay de patata.com y en el DNS se pone como primer MX A con su ip privada y como segundo B con su IP pública. Cualquier servidor de Internet, al no poder conectar con A, lo enviará a B, que por definición lo enviará a A, pues sí puede conectar.
Explica como mandarias un correo de 1k a todos los alumnos de la UJI (tienes la lista), sin sobrecargar ningún servidor de correo, ni los discos del servidor de correo de la UJI, y en un tiempo razonable. Resp.
Enviaré los mails en grupos de 100 destinatarios (por ejemplo) de modo que sólo se envía un mail para esos 100. En la cabecera del maili no incluiré los destinatarios para no incrementar el tamaño del mensaje. Entre mail y mail dejaré transcurrir un minuto para asegurarme de no incrementar la carga de los sistemas. Si tengo el correo en el fichero mail.txt (un correo siempre es texto una vez compuesto) y tengo la lista de destinatarios en destinatarios, podría ser un script como:
	  if [ "$1"]; then
	    sendmail -f yo@miemail.com -F "Mi nombre" $* <mail.txt
	    sleep 1m
	  else
	    cat destinatarios | xargs -r -n 100 $0
	  fi
	  
Comenta y explica la siguiente afirmación: "Los e-mails que viajan por Internet (cabecerá + cuerpo) deberían ser texto de 7bit". ¿Significa ello, por ejemplo, que no deberíamos mandar imágenes en los mails? Resp.
La frase significa que debría usarse para las diferentes partes MIME de los mensajes codificación de tipo base64 si son "binarios" o quoted-printable si son textos, de modo que el resultado del correo una vez formateado es ascii 7bit. Podré mandar por e-mail lo que quiera.
Configuro el DNS y el correo del dominio pera.com y pongo como el primer MX a mi ordenador, que tiene IP fija. Como a veces desconecto de internet, se me ocurre poner como segundo MX al servidor de correo de la UJI. ¿Qué pasará y por qué?. Resp.
La UJI no es relay de pera.com. Por ello, cuando desconecte mi ordenador de internet, los correos a pera.com irán al servidor de la UJI, que los devolverá con error al remitente.
Administras una red local, de modo que los ordenadores de dicha red usan el tuyo como DNS y para mandar correo. Quieres que todos los correos dirigidos al dominio patata.com, que nada tiene que ver con vosotros, desde los ordenadores de tu red, no llegen a su destino. Explica una forma práctica de hacerlo. Resp.
Modifico el DNS e incluyo el dominio patata.com como mío y digo que su MX es mi propio ordenador. Cuando envíen a @patata.com irá a mi ordenador y éste les devolverá un error, pues patata.com no es un dominio gestionado por mi smtp server. Alternativamente pudo declarar en el MTA que sí es undominio mío y dirigir todo su correo a un buzón o a /dev/null.
Estoy probando en mi ordenador (Linux) un programa (compilado) de gestión de alumnos que envía en ciertas ocasiones correo a los alumnos. Todos los destinatarios están en el dominio anubis.uji.es. Durante las pruebas, no quiero molestar a nadie con los mails. El programa envía correo llamando al sendmail que corre en mi ordenador. ¿Cómo puedo hacer para que los correos no lleguen a su destino?. Resp.
Le diré a mi sendmail que anubis.uji.es es uno de mis dominios y que envíe a mi buzón todo el correo que va a ese dominio. Así los correos me llegarán a mi.
¿En el correo, cuándo debo usar quoted-printable y cuándo base64?. Justifica la respuesta. Resp.
Emplearé quoted-printable para textos y base64 para binarios. El quoted-printable introduce varios caracteres cada vez que tiene que codificar algo que no es ASCII puro, cosa que ocurrirá pocas veces en un texto, de modo que se incrementará muy poco el tamaño del mensaje. En cambio si uso base64 para un texto se incrementará en un 33% fijo. Lo contrario para los binarios: base64 sólo incrementa el 33%, quoted-printable puede ser hasta un 300%.
Explica con precisión:
  • Por qué las imágenes en el correo se codifican en base64 y no en quoted/printable.
  • Por qué las imágenes en el correo se codifican en base64 y no se mandan sin codificar.
Resp.
  • En base64 el tamaño se multiplica por 1.3, en quoted puede ser hasta por 3.
  • Los servidores de correo pueden cambiar los caracteres de control, con lo que la imagen quedaría destrozada, además no todos soportan líneas de longitud indefinida.
Entre los registros que definen un cierto domino en el correspondiente fichero de zona, nos interesan los siguientes:
	  	IN A 1.2.3.4
		IN MX 10 mail1
		IN MX 10 mail2
	  mail1 IN A 1.2.3.4
	  mail2 IN A 1.2.3.5
Si enviamos un correo a una dirección de ese dominio, ¿qué servidor de correo la acabará recogiendo? Explica las consideraciones importantes que afectan a los buzones de este sistema de correo. Resp.
La recogerá cualquiera de los dos, pues tiene la misma prioridad en el registro MX. Para que los correos, entren por donde entren, vayan a los mismos buzones, los dos servidores podrían compartir los buzones, por ejemplo vía NFS.
Quiero enviar un mail escasamente legítimo a todas los alumnos de la UJI. Por ello no puedo emplear las direcciones oficiales que permiten hacerlo, como alumnes@uji.es, etc. Además no tengo la lista de alxxxxxx, pues el fichero /etc/passwd de lynx ya no las contiene. ¿Qué puedo hacer? Si estoy en mi casa, ¿qué haré para minimizar el tráfico de salida? Responde con la mayor precisión que puedas. Ojo, no vale conectarse a lynx por ssh y mandarlo, se trata de hacerlo desde casa. Resp.
Ya hemos visto esta pregunta antes ... Puedo intentar todos los xxxxxx de 000000 hasta, por ejemplo, 300000, con un script. Por ejemplo:
	  for ((i=0; i<30000; i++)); do
	    al=al$(printf "%06d" $i)
	    sendmail $al@anubis.uji.es < fichero_con_el_mail
	  done
El problema es que mando 30000 mail, lo que me agota el caudal de salida y además el servidor de correo pasará el antivirus y antispam, etc. 30000 veces. Puedo mejorarlo bastante enviándolos de 100 en 100, por ejemplo:
	  ma=''; c=0
	  for ((i=0; i<30000; i++)); do
	    ma=$ma" "al$(printf "%06d" $i)@anubis.uji.es
	    c=$[c+1]
	    if [ $c = 100 ]; then
	      sendmail < fichero_con_el_mail $ma
	      c=0; ma=''
	    fi
	  done
Como recibiré muchos correos de error, puedo incluir un campo X-tarari en la cabecera que pongo en fichero_con_el_mail y cuando me devuelva los errores, filtrarlos; o poner un Return-path que sea una dirección con buzón /dev/null.
Te quieres ir de vacaciones el 1 de Agosto, y activas un mensaje de autorespuesta en el correo, de modo que si recibes un mail, se responde al enviante un mensajito. Justo después de poner el autoresponder, le envías un correo a un amigo y te vas. Pero el amigo también tiene un autoresponder. Explica que puede pasar y cómo suele tratar de evitarse, y si se puede evitar en el 100% de los casos, y en este caso di cómo. Resp.
Si no se han tomado las debidas precauciones, se entrará en un bucle absurdo de envíos, realmente pernicioso. Para evitarlo, en el mensaje de autorespuesta incluiré un campo X-loop y espero que mi amigo compruebe que mi correo lleva ese campo antes de respondermei; es la forma usual. Una forma de no depender de mis amigos sería guardando automáticamente las direcciones de correo de las que recibo mail, y dando la autorespuesta a las que no he respondido ya.
Un servidor smtp hace de relay al dominio patata.com, es decir que es MX de ese dominio, pero no el de mayor prioridad. El administrador de ese servidor quiere evitar que se envíen correos a ptt@patata.com a través de ese servidor. Explica por qué no puede hacerse usando solamente sieve o procmail. Resp.
Los programas sieve y procmail son filtros para los mensajes que se depositan en buzones locales y por tanto no afectan a los mensajes que simplemente "pasan" por el servidor.
El correo del dominio pera.com lo gestiona (es el único MX) el ordenador mail.pera.com. Este ordenador esta conectado a internet con un proveedor que le cambia la IP con cierta periodicidad (es decir desconecta y al volver a conectar a internet tiene otra IP). El ordenador chequea cada minuto si le han cambiado la IP, y cuando lo detecta, actualiza el servidor de nombres (que obviamente está en otro ordenador con IP fija). Explica que problemas puede acarrear el cambio frecuente de IP en lo relativo al correo de pera.com. Resp.
Supongamos que cambian la IP e inmediatamente la antigua se asigna a un ordenador que tiene tb un servidor smtp. La actualización del servidor de nombres tardará un tiempo, pues la detección del cambio puede retrasarse hasta un minuto, y además tiene un TTL que puede ser pequeño pero no ser necesariamente obedecido por todos los DNS. Si en el perido de tiempo en que la IP de mail.pera.com es la antigua, pero esta IP corresponde a otro ordenador, se envía un correo a pera.com., éste será rechazado por el servidor smtp del ordenador extraño, por sus reglas anti-relay.
Explica qué es el spam y si puede evitarse y cómo. Resp.
Es el correo no deseado, es decir el que recibimos sin haberlo solicitado, debido a que nuestra dirección de correo es conocida por los creadores de spam. Puede tratar de evitarse mediante filtros de contenido, que con cierta inteligencia, sean capaces de separar el spam del correo lícito, pero pueden y suelen dar falsos positivos. También existen mecanismos a nivel de servidor como listas negras y grises, y cada día aparecen nuevos mecanismos de defensa. No puede evitarse al 100%, siempre nos llegará algo de spam, aunque encadenando los diversos mecanismos puede reducirse mucho. La única forma de evitarlo, un tanto teórica, sería que nuestra dirección sólo la conociera quien debe, pero esto no está al 100% bajo nuestro control.
Explica por qué al codificar cualquier información en base64 ocupa más que la original. Considerando que el resultado suele contener un cambio de linea de 1 caracter cada 72 caracteres codificados, calcula una fórmula muy aproximada para el incremento de tamaño. Resp.
base64 sólo usa 64 de los 256 caracteres posibles, es decir 6 bit frente a 8. Por ello el resultado ocupa 8/6 = 4/3 del original. Si consideramos los saltos de línea introducidos cada 72 caracteres, el resultado final será aproximadamente 4/3*n*(1+1/72).
Tienes que enviar por correo electrónico 10000 archivos de un tamaño medio de 10000 bytes (por archivo), todos ellos al mismo destinatario. Di como lo harás de forma razonable y práctica. Explica todas las consideraciones previas a tener en cuenta. Resp.
El tamaño total será aprox de 100 megabytes. Empaquetaré los archivos y el resultado lo partiré en trozos de 1 Mbyte, enviando así 100 mails. Por ejemplo:
	  export SPLITSIZE=1000000
	  tar zcvf - archivos | mail destino
Aunque lo más intuitivo es usar un compresor que parte archivos como por ejemplo rar:
	  rar a -vn -v1000 -ep trozos.rar archivos
	  for f in trozos.r*; do mutt -a $f destino; done
	  
Las consideraciones previas son: una que el tamaño máximo por correo es al menos de 1.3 megas y la otra que en el buzón del usuario caben los 100 megas a no ser que aplique un filtro que vaya guardando los ficheros aparte, con lo cual lo que necesitará es una quota de disco suficiente.
La página xxxx.nisu.org muestra las fotos que están en un determinado directorio. Cuando alguien envía un correo a xxxx@nisu.org conteniendo una o varias fotos, automáticamente se visualizan en la página web sin intervención de ningún operador humano. Explica detalladamente cómo implementarías esto. Resp.
El correo enviado a xxxx@nisu.org no va necesariamente a un buzón, puede ir a parar a un programa si así se configura. El programa separa las partes MIME y aquellas cuyo content-type es image/algo son almacenadas en el directorio correspondiente.
Un domino tiene dos servidores de correo (registros MX), los ordenadores A (MX 5) y B (MX 10) situados en dos ubicaciones distintas, es decir que conectan a Internet por líneas diferentes. Pero los servidores de nombres son A y C, estando ambos conectados a Internet por la misma línea. Un día se corta ésta línea durante dos horas, quedando A y C inaccesibles. Discute lo que pasará relativo al correo de ese dominio durante esas horas, y razona si podría mejorarse la configuración. Resp.
Al quedar desconectados A y C no hay servicio de nombres para el dominio. Los servidores de correo que pretenda enviar correo a ese dominio, si estaba la resolución en la caché de los DNS (los que ellos usan), simplemente enviarán le correo a B. Los que no puedan resolver eldominio, dejarán los mensajes en cola. El resultado es que no sucederá nada malo, excepto un improbable (sólo son dos horas) aviso a los enviantes y un retraso obvio en el correo. Se podría hacer alguna mejora, añadiendo como DNS del dominio a algún ordenador que no esté en la misma conexión, por ejemplo B, de modo que en ese caso el correo se hubiera transmtido a B.
Estoy en un ordenador muy raro, que sólo tiene un terminal linux, con conexión a Internet. Quiero mandar un mail a un amigo, pero no hay thunderbird, ni mutt, ni ningún programa cliente de correo, pero sí que hay muchas utilidades en línea de comando. En el mail quiero enviar un fichero de 1 megabytes que llevo en un USB, y quiero, además, asegurarme de que se ha enviado correctamente y no se ha quedado en ninguna cola. Proponme una solución. Resp.
Basta con conectar con el pto 25 de algún servidor y enviar el correo. Como quiero asegurarme de que llega al destino, lo mejor es conectar con el servidor destino. Hago
	  host -t mx dominio_de_mail_de_mi_amigo
y hago
	  (echo "helo este_ordenador"
	   sleep 1
	   echo "mail from: mi_dir_correo"
	   sleep 1
	   echo "rcpt to: dir_de_mi_amigo"
	   sleep 1
	   echo data
	   sleep 1
	   uuencode fichero primer_mx_del_destino 25
Si veo que los sleep no son suficientes, siempre puedo usar telnet y cortar y pegar con paciencia.
Si te conectas al servidor de correo (MX) de xyz.com (por ejemplo con telnet al puerto 25) e inicias un diálogo SMTP, ves que después del comando rcpt siempre te aparece un error 450 vuelva a intentarlo mas tarde ¿Es un problema del servidor? ¿Si no lo es, para qué puede servir? Resp.
Puede tratarse de un error temporal del servidor (saturación, etc.), pero si me lo da siempre, probablemente se trata de greylisting: Sólo los programas que son servidores legítimos de correo harán caso y volverán a intentarlo. Los virus y programejos de spam no vuelven a intentarlo. Esta simple técnica evita virus y spam.
Si tienes que enviar por email un texto cirílico (ruso) en Unicode (UTF-8), ¿qué te convendrá más como método de codificación, quoted-printable o base64? Resp.
Por la naturaleza del texto, van a aparecer pocos caracteres ascii 7 bit, por lo que base64 es más conveniente.
Explica qué condiciones deben cumplirse para que un campo X-Loop sea útil en un corro. Resp.
Este campo es para evitar bucles infinitos en las autorespuestas. Sólo hay que enviar la autorespuesta si el correo no proviene de un daemon (es decir, nos lo envía una persona), si no lleva el X-Loop y esperar que quien lo reciba no tenga una autorespuesta o si la tiene, se fije en si está el campo para no enviarla a su vez.
Un dominio tiene dos registros MX, uno (A) con prioridad 10 y otro (B) con prioridad 20, ¿qué pasará con el correo de ese dominio si se apaga sólo A? ¿Y si se apaga sólo B? ¿Y si se apagan ambos?. Explica también las diferencias prácticas (realistas) entre estas situaciones. Resp.
Si se apaga sólo B no se notará nada, pues el correo siempre va al servidor de mayor prioridad, excepto cuando rechace las conexiones, que no es el caso. Con A apagado el correo deberá quedarse en alguna cola, pues A es el destino final del correo por tener la prioridad más alta. Si se apaga sólo A, el correo irá a B y se quedará en su cola. Si se apagan A y B el correo se quedará en las colas de los servidores smtp que intenten enviar correo a ese dominio. La diferencia práctica entre ambos casos es que si B está encendido el correo se "acerca" en el sentido de que si la línea de comunicaciones entre A y B es rápida el correo entrará rápidamente en A nada más se conecte. Además si la parada de A va a durar varios días, la cola de B se puede programar para que mantenga el correo todo lo necesario, cosa que no sucederá si el correo se queda en la cola de servidores ajenos.
La codificación quoted-printable usada en el correo electrónico apenas incrementa el tamaño de los mensajes de texto. ¿Permite esta codificación enviar cualquier tipo de información?. ¿Por qué se usa base64 si ésta incrementa un 33% el tamaño?. Resp.
Sí, permite codificar cualquier información. Pero si la información no es de tipo texto occidental, el incremento de tamaño puede llegar al 300%, por lo que es preferible el 33% que penaliza base64.
Si te envían un correo que es un multipart/mixed y una de sus partes es otro multipart/mixed y una de las partes de éste último es también otro multipart/mixed, ¿cómo te lo muestra tu lector de correo? (debes decir cual usas). Resp.
La mayoría de lectores de correo hacen un recorrido infijo del árbol MIME, mostrando las hojas, es decir, convierten el árbol en una lista. El lector mutt muestra la estructura arborescente.
Ejecuto el comando:
echo test | /usr/sbin/sendmail amigo@sudominio.com
¿Qué diferencia interna hay entre estar usando el verdadero sendmail o el clon que incorpora postfix? Resp.
El verdadero sendmail es un programa monolítico que usando privilegios del sistema (setuid) escribe directemente en la cola de correo del sistema. En postfix, el clon sendmail se conecta al servidor local como un cliente sin necesidad de privilegios.
En el ordenador A hay un DNS instalado que tiene autoridad sobre el dominio D. El correo de dicho dominio es gestionado por el servidor de correo C (sólo él). En el ordenador N hay un servidor de correo que atiende otros dominios. Queremos que el correo de D ya no sea gestionado nunca más por C, sino que lo sea por N. Indica todos los cambios que hay que realizar, en el debido orden y con detalle. No se valorarán las vaguedades. Resp.
  1. Primero hay que configurar N para que reciba el correo de D. Para ello basta con indicarle al MTA que D es uno de sus dominios. En el caso de Postfix puede conseguirse modificando la directiva mydestination e incluyendo D. Dicha directiva está en main.cf.
  2. Rcargar el servidor de correo.
  3. Modificar el DNS de A, cambiando el MX que apunta a C, haciéndolo apuntar a N, es decir, donde estaba @ IN MX 10 C ahorá estará @ IN MX 10 N. Al (4) recargar el DNS el correo empezará poco a poco a entrar en N.

Nota: La migración de los buzones es un tema más complejo.

El World Wide Web ^

El world wide web (WWW) es un servicio tan universal en Internet, que iincluso el usuario final denomina la operación "abrir el navegador" como "entrar en Internet". Desde las simples páginas informativas de los años noventa a las complejas redes sociales del presente la evolución tecnológica y conceptual ha sido significativa. En este documento intentaremos dar un vistazo a las tecnologías actuales, pero sólo podremos dar una breve descripción. Nuestro objetivo será realmente fundamentar los aspectos básicos del WWW.

El WWW nace en el CERN, que produce un primer servidor muy sencillo y un navegador en modo texto que muestra páginas escritas en HTML, lenguaje de marcas que descibiremos aquí. La aparición de Mosaic, funcionando en entorno X-window supone un avance decisivo al funcionar con el ratón y ser capaz de mostrar imágenes en el propio docuemento. El relevo es tomado por Netscape que desarrolla un potente navegador, líder durante algunos años. El peso que el WWW adquiere en las comunicaciones tal que Microsoft desarola su navegador (Explorer) que desbanca a Netscape. Actualmente Mozilla (Firefox) ha tomado el relevo de Nescape y Google ha entrado en el mundo de los navegadores con Chrome. No obstante Opera sigue siendo el más rápido y eficiente pese a que su uso es marginal. Los navegadores actuales son herramientas muy complejas, inconcebibles sin la potencia de los actuales ordenadores personales. La presentación de HTML4 sólo es una anécdota dentro de las capacidades del navegador, capaz de ejecutar aplicaciones con su intérprete de javascript (y con plugins como flash o applets de java), que junto con las capacidades de los servidores, convierten al navegador en una herramienta casi universal para el trabajo en el PC.

El origen del concepto del Web es la posibilidad de leer un documento que contiene referencias a otros documentos y pasar a leerlos directamente, incluso si están en otros servidores. Es lo que se conoce como hipermedia, un concepto anterior a Internet pero que alcanza su desarrollo con ella.

Para poder referenciar a un documento externo, se introduce el concepto de URL.

El lenguaje PHP

El lenguaje PHP es un lenguaje interpretado de alto nivel que puede ser incrustado dentro de un documento HTML y ejecutarse en el servidor. Es el lenguaje más utilizado en servidores web, y tiene una gran facilidad para trabajar con bases de datos sin demasiados problemas, lo que lo ha hecho muy atractivo para el desarollo web. Además al ser un lenguaje interpretado y con una sintáxis poco complicada, hace que el tiempo de desarrollo de un programa que queramos que ejecute nuestro servidor, sea muy corto, comparado con otros lenguajes como C.

La sintáxis tiene muchas características del C, además de ser un lenguaje no tipado, en el cual no es necesario declarar previamente las variables. Una vez una variable es de un tipo, por ejemplo de los arrays asociativos que ofrece el lenguaje PHP, debe utilizarse como ese tipo.

A la hora de incrustar un código PHP dentro de una página web, necesitamos las etiquetas especiales <?php y ?> que delimitarán el trozo de código que hayamos incluido. Hoy en día el intérprete lenguaje está incluido en el propio servidor web Apache lo que lo hace más rápido y totalmente integrado, de modo que es el propio servidor quien interpreta el código PHP cuando procede.

PHP ofrece ayudas para el desarrollo web como las variables $_GET, $_POST en las que encontramos los campos que se han pasado en la URL o por la petición HTTP POST, normalmente procedente de un formulario. La variable $_REQUEST contiene la combinación de $_GET, $_POST y las cookies.

La variable $_SESSION facilita una manera de mantener la información referente a una sesión del cliente, al que se envía una cookie con el identificador de la sesión. El valor de la cookie es el fichero en el servidor donde se está guardando la información de sesión, de modo que al devolver la cookie al servidor, éste recupera lo guardado en la $_SESSION. Para activar las sesiones es necesario llamar a la función session_start() que crea la sessión si no existe la cookie o usa la que ésta le indica. Dado que la función modifica las cabeceras, es necesario llamarla antes de escribir nada en el output.

Para conocer más sobre PHP es recomendable leer éste documento.

Ejemplos de scripts PHP
Veamos pequeños fragmentos de código relacionados con operaciones que es capaz de hacer el PHP. Primero escribiremos un script que coje los datos enviados desde un formulario y los almacena en base de datos.
  
if ( $_POST['Password'] != $_POST['VerifPassword'] )
    die(
"<h4>Debes de introducir correctamente la password<h4>");
  
$con mysql_connect("usuario","servidor","password");
  
mysql_select_db("baseDeDatos",$con);
  
$sql="INSERT INTO Usuarios VALUES(";
  foreach(array(
"Nombre","Login","Password") as $cmp) {
    if (!
get_magic_quotes_gpc())
      
$_POST[$cmp]=mysql_real_escape_string($_POST[$cmp]);
    
$sql.="'".$_POST[$cmp]."', ";
  }
  
$err mysql_query("$sql)",$con);
  if ( 
$err )
    echo(
"<h4>Ha habido un error en la inserción<h4>");
  else
    echo(
"<h4>La inserción se ha realizado con éxito.<h4>");
  
El script comprueba que el usuario haya tecleado la misma contraseña en los campos Password y VerifPassword. Con las funciones mysql_connect y mysql_select_db se conecta a la base de datos donde desea realizar la consulta. Debemos observer que la contraseña de acceso a la base de datos se encuentra dentro del script, y esto puede ser un problema de seguridad si alguien puede acceder al código fuente. A continuación toma los datos del formulario, con la precaución de "escaparlos" con mysql_real_escape_string si no lo estna ya (viene indicado por get_magic_quotes_gpc) y va construyendo una sentencia SQL que ejecuta con mysql_query.

Veamos cómo usar las sesiones:
  session_start
();
  
$con mysql_connect("usuario","servidor","password");
  
mysql_select_db("baseDeDatos",$con);
  foreach(array(
"usuario","password") as $cmp)
    if (!
get_magic_quotes_gpc())
      $
$cmp=mysql_real_escape_string($_POST[$cmp]);
  if ( 
mysql_num_rows(
mysql_query("SELECT * FROM Usuarios WHERE nombre = '$usuario' and password = '$password'"))) {
    
$_SESSION['login'] = $usuario;
    
header("Location: aplicacion.php");
    die();
  } else {
    echo(
"<h4>Usuario y/o contraseña incorrectos.<h4>");
  }
  
Primero que nada hemos iniciado sesión, aunque no sea estrictamente necesario, hacerlo al inicio del programa evita errores. Realizamos después una consulta a la base de datos para ver si existen usuario y password en la base de datos y si es así, establece en sesión, vía $_SESSION que el usuario está autenticado, salrando a otra aplicación que requiere estarlo. Éste pequeño script ilustra el uso de $$cmp que es la forma de acceder al contenido de la variable cuyo nombre está en la variable $cmp, algo sólo concebible en un lenguaje interpretado.

A la hora de desarrollar en PHP se hace interesante saber que cuenta con dos lineas de apoyo al desarrollador, en las cuales se incorporan librerias de funciones. Existen dos filosofías en el desarrollo de librerías para PHP. Una es PECL que son extensiones programadas en C que se añaden directamente al intérprete PHP. Ofrecen gran velocidad de ejecución y permiten realizar funciones que no podrían implementarse en PHP. La otra es PEAR que son clases programadas en PHP y deben incluirse mediante la directiva require_once que incluye todo el código del fichero referenciado, teniendo que comprobar sintácticamente el intérprete de PHP todo ese código además de nuestro script. Aún así, dada la gran velocidad de los procesadores actuales, PEAR es muy interesante.

Cuestiones del tema ^

Me conecto con mozilla a una página web que inmediatamente me redirecciona a otra. Explica los mecanismos que puede estar usando para realizar la redirección, y explica como podrás averiguar cual de ellos está utilizando (para ello puedes emplear herramientas cualesquiera). Resp.
Mecanismos básicos:
  1. Redirección http a través de las cabeceras usando el campo Location .
  2. Redirección usando un campo <meta http-equiv=refresh .
  3. Usando javascript u otro lenguaje de scripting.
Los mecanismos expuestos los he enunciado en orden de compatibilidad, del más al menos. Para averiguar cual usa no puedo ver el código fuente de la página que visualizo porque ¡no es la que he pedido!. Hago un telnet al puerto 80 del servidor web y simulando una conexión http observo cabecera y cuerpo de la página original.
Explica cómo funcionan las cookies (no sus aplicaciones). Resp.
La cookie es un dato en forma de (variable,valor) que un servidor web envía en la cabecera de una respuesta, invitando al navegador a almacenarlo y reenviarlo al servidor en una próxima visita a la página. Normalmente funcionan, no a nivel de página, sino a nivel de directorios.
Una página web tiene un formulario con un campo "input" que pide el DNI. Al enviar el formulario, mediante javascript, comprueba si el DNI es válido, pero hay un error en la comprobación y no te deja enviar tu DNI. ¿Cómo lo resolverás? Resp.
Deshabilitaré javascript en mi navegador.
Tienes una página php y quieres poner un contador de visitas. ¿Puedes implementarlo sólo con cookies? Resp.
No puedo sólo con cookies, pues debo usar un contador global que tendré que almacenar en un archivo o en una base de datos. De hecho las cookies no las necesito para un contador, a menos que quiera justo lo contrario: descontar visitas de un mismo navegador.
Tienes una página php y quieres poner un contador de visitas. Impleméntalo. Resp.
Puedo usar ficheros o base de datos, con fichero, algo sencillo sería:
	  <? $f=fopen('contador','r');
	     $co=fread($f,400);
	     fclose($f);
	     $co=$co+1;
	     echo $co;
	     $f=fopen('contador','w');
	     fwrite($f,$co); fclose($f);
	  
Mejora el script para no tener que abrir el archivo dos veces.
En el protocolo HTTP, explica una ventaja de usar GET frente a POST y una ventaja de usar POST frente a GET (obviamente se darán en circunstancias diferentes). Resp.
Vetaja de GET: los datos van por la URL, luego puedo hacer un GET con un simple enlace (de hecho un enlace es un GET), tecleando en la barra de dirección de mi navegador, etc. Ventaja de POST: el tamaño de los datos que puedo enviar es mucho mayor que en GET.
Cada vez que me conecto a una página web, dice "Bienvenido Manuel". ¿Cómo puede haberse producido esta situación?. Resp.
La página entregó a mi navegador una cookie que mi navegador le envía cuando me conecto a ella. La primera vez que me conecté debí dar mi nombre, y ahora, gracias a la cookie, lo puede recordar consultando alguna base de datos.
Comenta el siguiente algoritmo PHP-like, que pretende mostrar datos privados a partir de un nombre:
	  if ($que=$_POST['saca']) { consulta $que; muestra resultados }
	  else  if ($autenticado)
		  echo "<form method=post>Nombre de quien quieres los datos:",
		       "<input name=saca><input value=Enviar></form>";
		else
		  echo "Debes autenticarte para acceder a esta página";
	  
Resp.
Cuando se pide la página, si no estás autenticado te dice que te autentiques primero (con un método no descrito). Si lo estás te pide un nombre y te muestra unos datos. Si alguien hace directamente el POST no necesita autenticación, lo que es un error grave de programación.
Al acceder a cierta web buscando municipios de España, me encuentro con que no me da más de 10 resultados por consulta y además sólo los nombres de los municipios, sin información relativa a ellos. Observo que las respuestas son del tipo:
	  <a href="/busqueda.php?ID=4043">Albengibre</a>
	  <a href="/busqueda.php?ID=4044">Alatoz</a>
Y al pinchar en esos enlaces sí que me sale la ficha del pueblo con la información que yo quiero.
Di cómo harías para bajar de un tirón las fichas de los 8110 municipios de España. Resp.
	  for ((i=1; i<8111; i++)); do
	    GET "LAWEB/busqueda.php?ID=$i" >"pueblo$i.html"
	  done
Una página web contiene un formulario con método GET en el que tengo que introducir mi DNI y mi nombre. La persona que ha hecho la página ha olvidado poner botón de envío, ¿cómo puedo enviar mi nombre y DNI de forma fácil? Resp.
Miro el código fuente y veo como se llaman los campos input, sean nom y dni, y que el action del formulario es X. Sólo tengo que cargar con el navegador la url X?dni=MIDNI&nom=mi+nom
Explica el mecanismo de sesiones del PHP. Resp.
La función session_start() comprueba si el navegador ha enviado una cookie de sesión (de nombre PHPSESSID). Si lo ha hecho y existe un fichero asociado (suele hacerse con ficheros) a esa sesión, coje su contenido y lo carga en la variable $_SESSION. Si no, crea una nueva cookie de sesión y su fichero asociado. Al final del programa, el contenido de $_SESSION se guarda en el fichero asociado, de modo que la próxima vez podrá recuperarse. Si las cookies no están habilitadas, puede pasarse una parámetro PHPSESSID (por GET) con el mismo valor.
Cuando quiero enviar un fichero por formulario, ¿qué características debe tener el formulario?, ¿cómo se envía el fichero?, ¿por qué no se usa la codificación normal (urlencoded)? Resp.
El formulario debe ser de método post y la codificación multipart/form-data. En ese tipo de codificación, todos los campos del formulario (input, select, etc), se envían en formato MIME, de modo que los ficheros se mandan en base64. Si se usara urlencode (application/x-www-form-urlencoded) el tamaño del post podría incluso triplicarse.
Explica EXACTAMENTE qué hace este php:
	  <?
	    session_start();
	    echo "Las visitas a esta página son: ".($_SESSION['contador']++);
Resp.
Se incrementa un contador cada vez que se accede ... pero sólo en la sesión. No cuenta las visitas totales de todos los visitantes ni siquiera las de un visitante, sino las de un visitante en una sesión de navegación, es decir sin cerrar el navegador.
La orden:
	  telnet al.nisu.org 80
	  GET / HTTP/1.1
	  Accept: text/html
produce un:
	  HTTP/1.1 400 Bad Request
Explica por qué. Resp.
Como mínimo es necesario especificar Host: en la petición, en este caso sería Host: al.nisu.org u otro website que pudiera estar alojado en esa máquina.
Explica la diferencia conceptual entre una sesión telnet y una sesión web. Resp.
La sesión telnet se implementa a bajo nivel mediante una conexión TCP que se establece al conectar y se termina al desconectar, es decir que la sesión es una conexión TCP.
En cambio, en el web la sesión se implementa completamente por software de aplicación, puesto que las conexiones TCP normalmente se abren y se cierran continuamente, incluso a veces para la carga de cada uno de los objetos de una página.
Explica claramente las diferencias entre validar los datos que un usuario introduce en un formulario web mediante 1) javascript en el formulario y 2) mediante PHP. Resp.
La validación javascript es una comprobación local, a nivel de navegador. Por ello puede ser manipulada por el usuario. Debe emplearse sólo para mejorar el entorno de usuario, nunca con fines de seguridad. La validación PHP es la que provee seguridad, pero implica enviar los datos al servidor para su validación.
He escrito un script en PHP que autentica usuarios mediante sesiones. Al ponerlo en un servidor, me encuentro con que el servidor destruye automáticamente todas las sesiones que no se usan en 24 minutos, con lo que los usuarios que no usan la página en ese periodo, tiene que volver a autenticarse. Propón una forma (bien fácil) de resolver eso, teniendo en cuenta que no puedo modificar la configuración del php del servidor ni usar directivas en .htaccess. Resp.
Una forma compleja es, mediante las directivas de administración de sesiones, cambiar toda la gestión, pero esto me dará bastantes problemas, incluso es posible que el php esté configurado para no dejarme hacer estos cambios.
Una forma muy fácil de hacerlo es la siguiente. En la salida de mi script (HTML) incluyo un frame o iframe de tamaño 0 que llame a mi script con un parámetro tal que mi script sólo refresca la sesión, no hace nada más, pero la salida del script fuerza la recarga cada 5 minutos (usando Location en la cabecera, o meta+refresh o javascript en el HTML de mi iframe).
A la hora de validar un NIF en un formulario web, razona por qué no es suficiente hacerlo en javascript. Y si no es suficiente, ¿para qué hacerlo? Resp.
Pregunta similar a la anterior, Javascriptse ejecuta en el cliente, por lo que puede ser deshabilitado o manipulado. La comprobación deberá ser siempre en el servidor, y se suele hacer (además) en javascript simplemente para mejorar el entorno de usuario.
Razona por qué no se puede enviar un fichero en un formulario (<input type=file) por GET (en ningún caso), ni por POST usando codificación URL-encode. Resp.
La codificación URL-encode puede causar sobrecargas de hasta un 300%, por lo que no es razonable. Además en el caso de GET (que ya descartamos por usar esa codificación), el fichero se codificaría en la URL y por razones de seguridad y rendimiento todos los servidores web acotan la longitud de las URL.
El fichero se envía por POST con codificación multipart, que produce algo similar a un correo.
Si a un script PHP le enviamos datos por POST, se supone que los datos le llegan por la entrada estándar (se los da el servidor), entonces ¿cómo se explica que los datos se encuentren accesibles gracias al array $_POST? Resp.
Al iniciarse cualquier script, hay unas rutinas automáticas que se ejecutan antes que nuestro código, que leen la entrada, la analizan y generan el array en cuestión.
¿Podrías montar tu propio servidor web en lynx? Explica cómo. Resp.
La única restricción es el puerto, yo no soy administrador en lynx, no puedo escuchar por puertos por debajo de 1024. Pero puedo montarme un servidor en un puerto por encima de 1024. Bastaría construir mi propio fichero de configuración de Apache y arrancar el Apache que ya está instalado, pero diciéndole que use mi archivo.
En un servidor web con PHP está configurado con la cookie de sesión con path = / y varias aplicaciones de distintos propietarios establecen la autenticación de usuarios con $_SESSION['aut']=true;. Explica cuál es el problema y qué podrían hacer las aplicaciones considerando que son opensource. Resp.
El problema es que, un visitante/cliente de una aplicación, una vez autenticado en una, queda autenticado en todas y por ello tenemos un bug de seguridad. Una solución sencilla es que la autenticación se establezca con algo del tipo $_SESSION['aut']='algun secreto';, donde el secreto se establece en el momento de instalar la aplicación.
Mediante la URL http://tonto.com/sms?tel=666777888&msg=Esto+es+un+saludo puedo enviar un SMS sin pagar. Escribe exactamente (no vaguedades) la variante de esa URL que usarás para decirle por SMS a un amigo que con esa URL puede mandar SMS sin pagar. Resp.
Debo codificar en URLencode el mensaje que quiero mandarle, puedo hacerlo a mano o con un PHP como este:
	  <?
	    $mens="Ye! Mensajes gratis usando la URL http://tonto.com/sms?tel=666777888&".
	    		"msg=El+mensaje+que+quieres+mandar";
	    echo "http://tonto.com/sms?tel=666777888&msg=".urlencode($mens);
El resultado es: http://tonto.com/sms?tel=666777888&msg=Ye%21+Mensajes+gratis+usando+la+URL+
http%3A%2F%2Ftonto.com%2Fsms%3Ftel%3D666777888%26msg%3DEl%2Bmensaje%2Bque%2Bquieres%2Bmandar
Un portal registra nuevos usuarios simplemente invitando a rellenar este formulario:
	  <form action=reg.php>Nuevo usuario: <input name=user><br>
	  Contraseña: <input name=pass><br>Repite contraseña: <input name=pass2><br>
	  <input type=submit value=Enviar></form>
Explica e implementa un ataque trivial que puede hacerse sobre el portal. Explica qué habría que cambiar en el portal para evitarlo. Resp.
Es muy fácil automatizar, como hemos hecho en prácticas, el envío de datos al formulario y registrar un número indefinido de usuarios en el portal:
	  while true; do
	    p=ABCabc$RANDOM;
	    GET "http://portal/dir/reg.php?user=usu$RANDOM$RANDOM&pass=$p&pass2=$p";
	  done
En este tipo de formularios debe incluirse siempre un CAPTCHA para evitar la automatización.
Sea el formulario:
<form method=post action="x.exe?v1=33"><input name=z><input type=submit></form>
¿Qué encontrará el programa x.exe en la entrada estándar? ¿y en la variable de entorno QUERY_STRING? Resp.
De los apuntes, en la entrada estándar encontrará z=valor_introducido. En QUERY_STRING encontrará v1=33.
Tienes un servidor apache con dos VirtualServer para la misma IP, cada uno con un nombre distinto (resolviendo la misma IP). Pero existe un tercer nombre que resuelve a esa IP. ¿Qué VirtualServer responde cuando accedes al servidor web usando ese nombre? Resp.
Visto en prácticas, coje el primero.
La página de descargas masivas Requeteload, cuando solicitas la descarga de un archivo, te muestra un contador de segundos que se decrementa desde 5 minutos hasta cero y entonces te muestra el botón de descargar. Explica cómo descubrir si podrías evitar la espera. Resp.
El contador se ejecuta en local (con recargas sería insostenible), por tanto puedo ver el código que lo produce y evitarlo, pues todo lo que se ejecuta en mi navageador (javascript por ejemplo) está bajo mi control. Incluso probablemente el botón ya está en el código, sólo que no visible, basta con hacerlo visible. Podré evitar realmente la espera si el control de tiempos se realiza sólo en el cliente. Si se realiza también en el servidor (que es lo lógico), al intentar la descarga antes de tiempo el servidor me devolverá un error.

Cuestiones generales ^

Entras a trabajar en una empresa y te dicen que disponen de una conexión permanente a Internet y de una IP fija (correctamente encaminada). Te dan un ordenador vacío y te piden que sobre esa base montes un conjunto de servicios Internet para la empresa. En particular, te piden que crees empresa.com y que su web (está sin hacer) y todo el correo residan en la empresa, así como el DNS. Explica con detalle todos los pasos necesarios. Resp.
  1. En primer lugar determinaré si el nombre empresa.com está registrado. Si lo está prepararé una lista de alternativas y la contrastaré con la dirección de la empresa.
  2. Determinado el nombre del dominio, lo registraré en el registrar más adecuado, actualmente Godaddy. Registraré el dominio a nombre de la empresa; como contacto administrativo quien me indique la empresa y lo mismo con el contacto de pago, siendo yo el contacto técnico y usaré para ello direcciones de correo en el dominio recién registrado.
  3. No colocaré DNS alguno, sino que lo solicitaré aparcado.
  4. Como sólo tengo una IP, buscaré alguien que quiera actuar de secundario (slave) de mi dominio, que puede ser un colega o una empresa que dé estos servicios, en cualquier caso solicitaré autorización a la dirección para usar un recurso externo.
  5. Instalaré el SO en el ordenador que me han asignado y el software necesario (DNS, mail, web).
  6. Configuraré mi DNS y lo daré de alta como, por ejemplo, ns0.empresa.com. Cuando esté registrado, cambiaré el dominio de aparcado a activo y especificaré mi DNS y el otro que he conseguido.
  7. Comprobaré que en unos días, desde máquinas externas ya se resuelve el nombre empresa.com a mi IP.
  8. Simultaneando estas tareas administrativas, configuraré el servidor de correo, creando las direcciones de correo que la dirección de la empresa me indique y haré una página web sencilla inicial. El DNS sólo especificará como MX a este ordenador.
  9. Contactaré con dirección para obtener los requerimientos de la página web de la empresa, y si es necesario contactaré con un diseñador y realizaré la programación necesaria.
Un servidor web sirve 30Gbytes de páginas, pero se actualizan muy poco, unos 2 Mbytes diarios. La actualización se realiza por los propios visitantes de las webs, de forma totalmente indiscriminada, pero no implica base de datos, sólo archivos que se modifican desde scripts de la propia web. Pretendes migrar este servidor a otro que está comunicado con éste por una línea de 1Mbit. Es decir que quieres trasladar todo el contenido de un ordenador a otro, y que el primero deje de fucionar y funcione el segundo, y que éste esté perfectamente actualizado. Explica cómo realizarás la migración con el mínimo trastorno para los visitantes del servidor, es decir interrumpiendo el servicio lo mínimo posible, y que no haya ninguna incoherencia en los contenidos copiados. Debes especificar los pasos con el debido detalle pero con precisión y brevedad. Resp.
  1. Primero bajare el TTL del DNS al mínimo.
  2. Haré un primer rsync del servidor viejo al nuevo, que tardará bastante, varios días: Son 30*1024*8 Megabits, que al dividir por 3600 son 68 horas.
  3. Mientras configuraré el servidor web nuevo para que vaya idéntico o mejor que el viejo.
  4. Haré otro rsync que debe tardar menos.
  5. Haré un tercer rsync que casi no tardará nada. No creo que haga falta un cuarto rsync.
  6. Apagaré el servidor web originial, no el ordenador, ahora no hay servicio.
  7. Un último rsync que espero sea rapidísimo, y al mismo tiempo:
  8. Cambiaré el DNS, para que las peticiones vayan al nuevo ordenador y dejaré el TTL como toca.
  9. Encenderé el nuevo servidor web.
Además habría que redirigir hacia el nuevo ordenador todas las peticiones que todavían lleguen al viejo ordenador, pues muchos DNS tardan en actualizarse aunque bajemos el TTL. Piensa cómo harías esto con Apache.
Tenemos un servidor web en un ordenador que se ha quedado anticuado y queremos cambiar por otro, que vamos a dejar conectado en la misma red local, de tipo ethernet. El ordenador original irá al desguace cuando acabemos la migración. La cantidad de datos que tenemos que migrar es de 30 Gigabytes. Estos datos se actualizan a razón de 1 Mbyte por hora como máximo. Explica el procedimiento exacto para sustituir un servidor web por otro, minimizando el tiempo de interrupción, teniendo en cuenta que no puede haber incoherencias en los datos traspasados. Resp.
Es obvio que en la ethernet la transmisión de los 30Gbytes no es un problema. El cuello de botella estaría en un cambio de DNS, por lo que lo evitaré a toda costa.
  1. Montaré el nuevo ordenador e instalaré el operativo y el servidor web.
  2. Prepararé la configuración del nuevo servidor web idéntica a la original.
  3. Asignaré al nuevo servidor una ip diferente.
  4. Mediante rsync transferiré los datos de un servidor a otro. Tardará unos minutos o unas horas dependiendo del tipo de ethernet, pero no será mucho.
  5. Arrancaré el segundo servidor web.
  6. Pararé el primer servidor web. No hay servicio.
  7. Haré un segundo rsync.
  8. Apagaré el primer ordenador.
  9. Pondré al nuevo ordenador la ip del antiguo.

Apéndices

Ejemplos de configuración clásica de redes ^

Red segmentada
Vamos a dividir una clase C 194.1.2.0 en dos partes, 194.1.2.0/25 y 194.1.2.128/25. Es la forma más sensata de dividirla, puristas abstenerse. Un equipo con dos interfaces (B) conecta las dos subredes.






A



C





194.1.2.2




194.1.2.130






































194.1.2.3




194.1.2.131












194.1.2.1














B









194.1.2.5
194.1.2.129



194.1.2.132





eth0
eth1






Configuración de A:
 ip a a 194.1.2.2/25 dev eth0
#ip r a 194.1.2.0/25 dev eth0
ip r a default via 194.1.2.1
Estamos en la situación estándar. Sólo debemos añadir una ruta a la otra mitad de la red.
 ip r a 194.1.2.128/25 via 194.1.2.5
La ruta siempre es por una IP directamente alcanzable. He configurado 3 rutas, debe ser igual en todos los equipos.

Configuración de B:
 ip a a 194.1.2.5/25 dev eth0
#ip r a 194.1.2.0/25 dev eth0
ip r a default via 194.1.2.1
Por el lado eth0 es un equipo normal en una red con salida a Internet.

 ip a a 194.1.2.129/25 dev eth1
#ip r a 194.1.2.128/25 dev eth1
Por el eth1 es lo mismo pero sin salida por ahí. Total 3 rutas.

Configuración de C:
 ip a a 194.1.2.130/25 dev eth0
#ip r a 194.1.2.128/25 dev eth0
ip r a default via 194.1.2.129
Es un equipo normal con salida a Internet.
Red segmentada a través de una red privada ^
Ahora la red del ejemplo anterior se divide pero se conecta a través de la red privada 192.168.0.0/24, como muestra la figura.






A



D



E





194.1.2.2




192.168.0.2
194.1.2.129



194.1.2.130










eth0
eth1








































194.1.2.3




192.168.0.3




194.1.2.131

















194.1.2.1



















B



C










194.1.2.5
192.168.0.1



192.168.0.4




194.1.2.132





eth0
eth1











Configuración de A:
 ip a a 194.1.2.2/25 dev eth0
#ip r a 194.1.2.0/25 dev eth0
ip r a default via 194.1.2.1
Es un equipo en red (1 ruta) con salida a Internet (+1=2).
 ip r a 192.168.0.2/24 via 194.1.2.5
Además debe acceder a la red privada (+1=3)
 ip r a 194.1.2.128/25 via 194.1.2.5
Y a la otra mitad de la red (+1=4).

Configuración de B:
 ip a a 194.1.2.5/25 dev eth0
#ip r a 194.1.2.0/25 dev eth0
ip r a default via 194.1.2.1
Por el lado eth0 es un equipo corriente (2 rutas).
 ip a a 192.168.0.1/24 dev eth1
#ip r a 192.168.0.0/24 dev eth1
Por el eth1 está la red privada (+1)
 ip r a 194.1.2.128/25 via 192.168.0.2
Y por ahí accede también a la red 192.1.2.128 .

Configuración de C:
 ip a a 192.168.0.4/24 dev eth0
#ip r a 192.168.0.0/24 dev eth0
# no hay ruta por defecto
Pertenece a la red privada, no hay ruta por defecto. Este equipo carece de acceso a Internet.
 ip r a 194.1.2.0/25 via 192.168.0.1
ip r a 194.1.2.128/25 via 192.160.0.2
Accede además a las dos mitades de la red 194.1.2.0

Configuración de D:
 ip a a 194.1.2.129/32 dev eth0
ip a a 192.168.0.2/24 dev eth0
#ip r a 192.168.0.0/24 dev eth0

ip r a default via 192.168.0.1 src 194.1.2.129
#implica ip r a 194.1.2.0/25 via 192.168.0.1

ip a a 194.1.2.129/25 dev eth1
#ip r a 194.1.2.128/25 dev eth1
Queremos tener una ruta por defecto para este equipo porque dispone de un IP válida en Internet y porque hace de router de las red .128. Sin lo que se ha marcado en itálica, este equipo actuará estupendamente como router para los de la red 194.1.2.128. En cambio, si queremos que la ruta por defecto sirva para sus propios intereses, es necesario lo marcado en itálica.
Primero asignamos en eth0 la misma ip que tiene en el interfaz eth1. Esto puede que no sea necesario. Lo que si es importante es que en la ruta por defecto se especifique que la IP de origen es la pública

Configuración de E:
 ip a a 194.1.2.130/25 dev eth0
#ip r a 194.1.2.128/25 dev eth0
ip r a default via 194.1.2.129
#implica ip r a 194.1.2.0/25 via 194.1.2.129
#implica ip r a 192.168.0.0/24 via 194.1.2.129
Es un equipo normal conectado a Internet que aprovecha la ruta por defecto para alcanzar las demás redes.
ADSL sin NAT
Aunque los routers ADSL suelen hace NAT, ésta es una configuración sin NAT, para un solo equipo detrás del router. El router del proveedor de acceso a internet tiene la IP 217.125.124.193 y la IP pública que se nos ha asignado es la 217.125.124.220. Entre los suministradores de ADSL este esquema suele denominarse configuración monopuesto. La IP pública se asigna a A, que puede además disponer de una IP en la red local. Para que el resto de la red local tenga acceso a internet será necesario que A realice SNAT En nuestro caso hemos dotado a A de dos IP, de modo que es muy fácil pasar al modo multipuesto (con NAT en el router) sin tener que cambiar nada en B.
Lo interesante es la configuración del router. En la parte externa, podemos colocar al router la IP que deseemos, porque la comunicación entre el proveedor de la línea y nuestro router no depende de esa IP: el router T envía los paquetes destinados a 217.125.124.220 a través de la línea ATM y al llegar al router son simplemente encaminados hacia la otra interfaz. En la parte interna del router colocamos la misma IP que tiene T. A verá a R como si fuera T. Los paquetes con destino externo se desean enviar a T, y son recogidos por R que los encamina hacia T.








A







192.168.0.1, 192.168.0.2
T


R



217.125.124.220
217.125.124.193
192.168.254.254 217.125.124.193










B







192.168.0.3










Configuración de A:
ip a a 192.168.0.2/24 dev eth0
ip a a 192.168.0.1/32 dev eth0

ip a a 217.125.124.220/32 dev eth0
ip r a 217.125.124.193 dev eth0
ip rou add default via 217.125.124.193
¿Podría poner ip a a 217.125.124.220/29 dev eth0 ?
iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -j MASQUERADE
SNAT para la red local realizado usando MASQUERADE, puede usarse SNAT
iptables -t nat -I PREROUTING -p tcp --dport 8088 \
-j DNAT --to-destination 192.168.0.3:8088
Añadido: DNAT: los accesos a A en *:8088 se redirigen a 192.168.0.3:8088

Configuración de B:
ip a a 192.168.0.3/24
ip rou add default via 192.168.0.1
Uso de proxyarp.
Supongamos un edificio con despachos en que cada despacho sólo dispone de una toma de red para conectar un equipo. En el despacho donde está el ordenador señalado en la figura como A quiero conectar otro equipo, B, para lo que aprovecho que A tiene dos tomas de red y con un cable cruzado los conecto.


















194.1.2.2

































A


B






194.1.2.3
192.168.0.1


194.1.2.23






eth0
eth1





194.1.2.1

























194.1.2.4










eth0




La configuración es sencilla, pero debe cumplirse el requisito fundamental: que los demás equipos sepan como alcanzar a B. Para ello basta con decir a la red 194.1.2.0/24 (router incluido) que envíe a A los paquetes que van a B. Para ello puedo añadir una ruta a todos estos ordenadores, pero no es práctico/factible. Es mejor usar proxyarp.

Configuración de A:
 ip a a 194.1.2.3/24 dev eth0
#ip r a 194.1.2.0/24 dev eth0
ip r a default via 194.1.2.1
Por el eth0 es un equipo en red normal.
 ip a a 192.168.0.1/32 dev eth1
Le ponemos la IP que nos apetezca, una privada mejor. Podríamos ponerle tb la 194.1.2.3. La máscara es /32 porque realmente no existe la red.
 ip r a 194.1.2.23 dev eth1
Decimos que B es directamente alcanzable por el cable cruzado.
 ip nei add proxy 194.1.2.23
Decimos a la red 194.1.2.0 que nosotros tenemos esa IP, de modo que nos llegarán a nosotros los paquetes con destino a B.

Configuración de B:
 ip a a 194.1.2.23/32 dev eth0
ip r a 192.168.0.1 dev eth0
ip r a default via 192.168.0.1
Por el lado eth0 es un equipo corriente, pero sin red local.
La IP 192.168.0.1 es directamente alcanzable por la eth0 y es la ruta por defecto.
Configuración de una interfaz wifi
Después de lenvatar la interfaz (sea wlan0) y antes de asignar IP, es necesario conectar con el punto de acceso.
iwlist wlan0 scan
Busco puntos de acceso dentro del alcance, y elijo el que queremos, sea su essid el_essid
iwconfig wlan0 essid el_essid
Asigno el essid
iwconfig wlan0 key 1234567890
Si se necesita contraseña WEP, la pongo
iwconfig wlan0 ap 00:22:2D:42:DE:F3
Asocio al punto de acceso elegido

Ejemplos de configuración moderna de redes ^

NAT
Supongamos una red como la de la figura:




R1


A






192.168.0.2



























192.168.0.3
R2
R






194.1.2.1
192.168.0.1

















192.168.0.4








Sólo R tiene acceso a Internet, pues los demás ordenadores tienen IP privadas.  Podrán acceder a Internet a través de R a nivel de aplicación (proxys por servicio) pero no a nivel de IP. Esta es una situación normal cuando contratamos por ejemplo una conexión ADSL que sólo nos provee de una IP pública. Sería deseable no obstante que los ordenadores de la red local (privada) pudieran acceder a internet en condiciones por lo menos similares a las de R.
Para ello, R, con el software adecuado, hace los siguiente: los paquetes que proviene de la red R1 con destino hacia Internet, son modificados, de modo que la IP origen es sustituida por la IP pública de R, es decir un paquete que va por ejemplo de A (192.168.0.2) a 1.1.1.1 es modificado por R de modo que cuando sale de R la IP origen es la 194.1.2.1 . De este modo, el paquete llega a su destino es atendido y el paquete de retorno llega correctamente a R, a la IP 194.1.2.1. R reconoce el paquete como que fue manipulado, y lo vuelve a manipular "deshaciendo" la operación anterior: sustituye la IP destino por 192.168.0.2 y encamina el paquete a su destino (A) De esta forma A tiene la percepción que está bien conectado a Internet (aunque sólo como cliente). Esta manipulación se denomina SNAT (Source Network Address Translation). En las conexiones TCP, UDP, etc, el paquete que sale de A tiene asociado un número de puerto origen. R intentará mantener el número del puerto origen, pero tendrá que cambiarlo si, por ejemplo, otro ordenador de la red ya usa el mismo socket (está conectando con el mismo servidor remoto, mismos puertos origen y destino). También sucede en algunos software de SNAT que si el puerto origen de A es menor que 1024 (privilegiado) es sustituido por uno no privilegiado, lo que imposibilita el uso de comandos especiales como rsh.
Varios encaminadores por defecto ^
La especificación de varias rutas por defecto en el encaminamiento clásico implica que se usa siempre la primera salvo que el router esté inaccesible, con lo que se emplea la segunda, etc. Pero si tenemos varias líneas y queremos aprovecharlas, podemos desear usar varios encaminadores simultáneamente. Para ello podemos usar el comando ip:. En la red de la figura, podemos configurar A como:
ip rout add default equalize \
nexthop weight 10 via 212.95.203.73 \
nexthop weight 10 via 213.171.69.249

R1





212.95.203.73








A





213.171.69.250

R2



212.95.203.76

213.171.69.249










Esta configuración va ligada con la situación que se presenta a continuación.
Selección de ruta ^
Supongamos la red de la figura anterior. Supongamos que el encaminador R1 es el que uso normalmente, y la configuración de A es:
ip a a 213.171.69.250/29 dev eth0
ip a a 212.95.203.76/24 dev eth0

ip r a default 213.171.69.249


Sólo se utiliza el encaminador R2
ip r a 150.128.81.252 via 212.95.203.73
Establezco una ruta explícita al ese equipo por el encaminador R1
La IP seleccionada para el destino 150.128.81.252 será automáticamente la 212.95.203.76 . En cambio, supongamos que A tiene dos IPs en esa red, según la configuración creada con:
ip a a 213.171.69.250/29 dev eth0
ip a a 212.95.203.76/24 dev eth0
ip a a 212.95.203.75/24 dev eth0

ip r a default 213.171.69.249

La IP "principal" es la 76.

Sólo se utiliza el encaminador R2

ip r a 150.128.81.252 via 212.95.203.73 src 212.95.203.75
Establezco una ruta explícita al ese equipo por el encaminador R1 y le fuerzo a usar la segunda IP.
La IP seleccionada para el destino 150.128.81.252 sería de nuevo la 212.95.203.76 si no hubiese especificado el parámetro src.
ADSL con NAT en el router ^
Esta es una configuración típica de un router ADSL que realiza SNAT.
El router del proveedor de acceso a internet tiene la IP 217.125.124.193 y nuestro router R tiene la IP pública que se nos ha asignado, 217.125.124.220 , de modo que configuramos con esos parámetros el interfaz externo.
El router provee SNAT a una red local, que es la 192.168.0.0/24. En la interfaz local del router ponemos la IP 192.168.0.1, que pertenece a dicha red local, y activamos SNAT.
Cada uno de los equipos de la red local tendrá una IP de esa red y como ruta por defecto la IP 192.168.0.1. Esta es la configuración que aparece en la figura sin considerar la IP en itálica. Entre los suministradores de ADSL este esquema suele denominarse configuración multipuesto.
En el equipo A decidimos instalar algunos servicios, como un servidor web. Debemos instruir al router para que realice DNAT sobre A, para todos los puertos o selectivamente (recomendable por seguridad). También querremos acceder a esos servicios desde la red local, pero si queremos hacerlo sobre la IP pública, deberemos acceder al router que nos encaminará a A. Pero nos encontramos con que la mayoría de routers no van a realizar primero el SNAT y luego el DNAT. La solución es poner a A la IP pública 217.125.124.220, e instruir al resto de los equipos de la red local para que la busquen en la red local (o vía 192.168.0.2).








A







192.168.0.2
T


R



217.125.124.220
217.125.124.193
217.125.124.220 192.168.0.1











B







192.168.0.3









Configuración de A:
ip a a 192.168.02/24 dev eth0
ip a a 217.125.124.220/32 dev eth0
ip rou add default via 192.168.0.1
Configuración de B:
ip a a 192.168.0.3/24
ip rou add default via 192.168.0.1
ip rou a 217.125.124.220 dev eth0
Varios proveedores ^
En la figura se muestra un ejemplo en el que se dispone de varios proveedores de acceso a internet. En el encaminamiento clásico, A sólo puede tener una ruta por defecto. La configuración de A sería:
ip a a 212.95.203.76/24 dev eth0
ip a a 213.171.69.250/29 dev eth0
ip r a default via 212.95.203.73
Coloco las 2 IP, que pone las dos rutas en la tabla main y le doy una ruta por defecto cualquiera.
ip r a 217.125.124.220/32 dev eth0 table R1
ip r a 213.171.69.250/29 dev eth0 table R2
Las mismas rutas en dos tablas, no es estrictamente necesario.
ip r a default via 212.95.203.73 table R1
ip r a default via 213.171.69.249 table R2
En cada tabla una ruta por defecto.
ip rule add from 212.95.203.76 table R1
ip rule add from 213.171.69.250 table R2
Cuando un paquete salga de la IP 212.95.203.76 mirará en la tabla R1 para decidir cómo enrutar, y elegirá la ruta por defecto correspondiente. El comportamiento será análogo para la IP 213.171.69.250
Un ejemplo real.
La red se compone de dos segmentos, uno con cuatro servidores, sean A,B,C y D y otro con uno, X.
El router R1 es un router que realiza sólo NAT. La IP pública es 80.59.218.92 y la red local se configura como 192.168.0.202. El router realiza:
  • SNAT de los equipos de la red local hacia fuera
  • DNAT por puertos desde fuera hacia los equipos de la red local, de modo que el 192.168.0.102 recibe la redirección de smtp, 192.168.0.112 la de http, 192.168.0.132 la de DNS y 192.168.0.122 la de POP3
El router R2 se configura con los mismos criterios que R1. R3 es un router sin NAT, de modo que sólo nos interesa la IP que tiene en la red local.
El equipo D tiene una segunda interfaz de red que le conecta a un punto de acceso wireless con la IP 192.168.0.152, que, configurado como  bridge, se comunica con otro idéntico con IP 192.168.0.153, que está en el otro segmento de la red local, donde se conectan el equipo E y el router R4.
Desafortunadamente el router R4 tiene configurada la red "Red X" como 213.171.69.248/29, es decir, que espera encontrar por ejemplo la IP 213.171.69.252 en dicha red, pero no es cierto que estén ahí físicamente, solo están el equipo D y el X. No podemos cambiar la configuración de ese router.








192.168.0.102, 192.168.0.103
A - smtp















212.95.203.77, 213.171.69.252











R1



80.59.218.92, 80.24.139.239



X






80.59.218.92 192.168.0.202







213.171.69.250










192.168.0.112, 192.168.0.113
B - www



192.168.0.1










213.171.69.253, 212.95.203.76







R4



R2



80.59.218.92, 80.24.139.239







213.171.69.249

80.24.139.239 192.168.0.203




















192.168.0.132, 192.168.0.133
C -DNS















213.171.69.251, 212.95.203.74











R3



80.59.218.92, 80.24.139.239











212.95.203.73











Red X







192.168.0.122, 192.168.0.123
D - pop3

P1
wireless
P2











80.59.218.92, 80.24.139.239  213.171.69.254
192.168.0.152

192.168.0.153











212.95.203.75



bridge







Configuración de A:
ip a a 192.168.0.102/24 dev eth0
ip rout add default via 192.168.0.202
En primer lugar lo situamos en su red local y decidimos que el router R1 sea su ruta por defecto. Esto es posible porque el router hace SNAT.
ip rout add default via 192.168.0.202 table R1
ip rule add from 192.168.0.102 table R1
Realizamos la misma operación en la tabla R1 y creamos una regla para que use la tabla.
ip a a 80.59.218.92/32 dev eth0
Le colocamos la IP pública del router a la propia máquina., como hicimos en el caso del ADSL con NAT en el router
ip a a 192.168.0.103/24 dev eth0
ip rout add default via 192.168.0.203 table R2
ip rule add from 192.168.0.103 table R2
ip a a 80.24.139.239/32 dev eth0
Lo mismo para el router ADSL R2
ip a a 212.95.203.77/29 dev eth0
ip rout add default via 212.95.203.73 table R3
ip rule add from 212.95.203.77 table R3
Este es un router sin DNAT, la configuración es sencilla.
ip a a 213.171.69.252/27 dev eth0
ip rout add default via 192.168.0.98 table R4
ip rule add from 213.171.69.252 table R4
La ruta por defecto que lleva a R4 es el servidor D que actua de router.
ip rule add to 192.168.0.0/24 lookup main
Esto es necesario para que todo el tráfico a la red interna de la empresa se despache por la tabla principal de enrutado y no emplee otras reglas previamente especificadas.

Configuración de B:
ip a a 192.168.0.112/24 dev eth0
ip rout add default via 192.168.0.202
ip rout add default via 192.168.0.202 table R1
ip rule add from 192.168.0.112 table R1
ip a a 80.59.218.92/32 dev eth0
ip a a 192.168.0.113/24 dev eth0
ip rout add default via 192.168.0.203 table R2
ip rule add from 192.168.0.113 table R2
ip a a 80.24.139.239/32 dev eth0
ip a a 212.95.203.76/29 dev eth0
ip rout add default via 212.95.203.73 table R3
ip rule add from 212.95.203.76 table R3
ip a a 213.171.69.253/27 dev eth0
ip rout add default via 192.168.0.98 table R4
ip rule add from 213.171.69.253 table R4
ip rule add to 192.168.0.0/24 lookup main
Es idéntico a A

Configuración de D:
ip a a 192.168.0.123/24 dev eth0
ip rout add default via 192.168.0.203
ip rout add default via 192.168.0.203 table R2
ip rule add from 192.168.0.123 table R2
ip a a 80.24.139.239/32 dev eth0
ip a a 192.168.0.122/24 dev eth0
ip rout add default via 192.168.0.202 table R1
ip rule add from 192.168.0.122 table R1
ip a a 80.59.218.92/32 dev eth0
ip a a 212.95.203.77/29 dev eth0
ip rout add default via 212.95.203.73 table R3
ip rule add from 212.95.203.77 table R3
Todo esto está claro.
ip a a 213.171.69.254/29 dev eth1
ip rout add default via 213.171.69.249 table R4
ip rul add from 213.171.69.250/27 table R4
ip route add 192.168.0.0/24 dev eth0 table R4
Configuramos la IP del interfaz eth1
ip rule add to 192.168.0.0/24 lookup main
Esto es como antes.
for t in R4 main; do
  ip rou add 213.171.69.251 dev eth0 table $t
  ip rou add 213.171.69.252 dev eth0 table $t
  ip rou add 213.171.69.253 dev eth0 table $t
  ip rou add 213.171.69.250 dev eth1 table $t
done
La red 213.171.69.248/29 está definida en eth1, pero realmente los equipos estan en la interfaz eth0, lo indicamos.
ip neig add proxy 213.171.69.252 dev eth1
ip neig add proxy 213.171.69.251 dev eth1
ip neig add proxy 213.171.69.253 dev eth1
Y hacemos proxyarp para que el router R4 los encuentre en su red local, donde espera encontrarlos según la máscara especificada en su configuración.

Configuración de X:
ip a a 213.171.69.250/29 dev eth0
ip r a default via 213.171.69.249
De lo más normal.
ip r a 212.95.203.72/27 via 213.171.69.254
La única particularidad es que nos inyeresa dar acceso directo a la red 212.95.203.72/27 . Si no loiciéramos saldría a internet y se daría un buen paseo para acceder a esa red.

Preguntas:
  1. ¿Porqué no hemo usado las ips 192.168.0.152 y 192.168.0.153 en la configuración?
  2. La última orden de enrutado, es obvio su interés, pero qué pasará realmente si X accede por ejemplo a 212.95.203.77?
Otro ejemplo.
Es una modificación del ejemplo anterior donde se han eliminado los proveedores de ancho de banda reducido dejando dos proveedores P1 y P2. Para entenderlo debe estar claro lo que hemos hecho en el ejemplo anterior. La máquina D del ejemplo anterior la llamamos ahora R porque deja de actuar como servidor. Los servidores reales son las máquinas A, B, C, D, E y F. Una posible configuración sería asignar las IPs reales a estos servidores y que R haga proxyarp, como en el ejemplo anterior. Pero el router R1 es un CISCO al que no le gusta nada el proxyarp y se producen latencias en todos los paquetes que circulan hacia los servidores a traves de R1. Suele pasar que cuanto más caro es el router peor funciona. Hay otras configuraciones posibles:
  1. Cambiar el cableado, eliminar R conectando los equipos a la misma red, la denominada en la figura "Red ext".  No nos gusta queremos que R realice diversos funciones interesantes.
  2. Cambiar la máscara de red de los routers R1 y R2 para que solo vean a R  y declarar que éste les enrutará hasta las otras IPs. Un problema para el proveedor P2, perdemos otra IP, solo tenemos 4.
  3. Usar DNAT y que R sea un firewall verdadero, pudiendo incluso hacer una distribución de carga estática sencilla.
Nos quedemos con la última opción. Nos permite resolver el problema del ejemplo anterior usando sólo una IP pública de cada proveedor (ver el final del ejemplo), aparte de la del router. Hemos mantenido la presencia de la máquina externa X que además toma una IP del proveedor 1 (además de la del 2 que ya tenía), y aparece una red privada nueva "ajena" cuyos equipos no son controlados por la empresa (excepto X).
Esta tabla es lo que causa que la página sea demasiado ancha















F

correo


















192.168.0.85

certificado



























A



B


C



D





E
192.168.0.96
serv-pop

192.168.0.100
serv-DNS

192.168.0.97
serv-smtp

192.168.0.99
serv-smtp



192.168.0.101
serv-www
















































Red int




















SNAT
192.168.0.98
DNAT

















R 213.201.69.198
213.171.69.254
















































Red ajena










Red ext
















213.201.69.193





bridge




192.168.1.x





R1












nat por X














wireless



...
...





Proveedor 
P1 12 Mbit

























bridge



192.168.32.x



















nat por X










































213.171.69.250












213.171.69.249




X externo













R2




213.201.69.194


































Proveedor
P2 6 Mbit











Configuración de A (idéntica a B,C,D,E):
ip a a 192.168.0.96/24 dev eth0
Esto es extremadamente fácil
ip rou add default via 192.168.0.98


Configuración de R:
ip a a 192.168.0.98/24 dev eth0
Es su interfaz local.
ip a a 213.201.69.198/27 dev eth1
ip a a 213.171.69.254/29 dev eth1
Es el interfaz externo con dos IPs .
ip rou add default via 213.171.69.249
iptables -t nat -I POSTROUTING -s 192.168.0.0/24 -j SNAT
--to-source 213.171.69.254
El tráfico por defecto lo desvio por el proveedor P2 .
Y ademas hace de SNAT para que toda la red "int" pueda salir a internet.
ip r d default via 213.171.69.249 table R2
ip r d default via 213.201.69.193 table R1
Dos trablas de rutas cada una solo con una ruta por defecto al proveedor correspondiente.
ip rule add from 213.201.69.198 table R1
ip ru a from 213.171.69.254 table R2
Dos reglas para asociar cada IP con su tabla.
ip rule add to 192.168.0.0/24 lookup main
No es estrictamente necesario esta ver ...
iptables -t nat -I PREROUTING -d 213.171.69.254 -p tcp
--dport smtp -j DNAT \
--to-destination 192.168.0.97 \
--to-destination 192.168.0.99
iptables -t nat -I PREROUTING -d 213.171.69.254 -p tcp \
--dport pop3 -j DNAT --to-destination 192.168.0.96
iptables -t nat -I PREROUTING -d 213.171.69.254 -p tcp \
--dport domain -j DNAT --to-destination 192.168.0.100
iptables -t nat -I PREROUTING -d 213.171.69.254 -p udp \
--dport domain -j DNAT --to-destination 192.168.0.100
iptables -t nat -I PREROUTING -d 213.171.69.254 -p tcp \
--dport www -j DNAT --to-destination 192.168.0.101
iptables -t nat -I PREROUTING -d 213.201.69.198 -p tcp \
--dport smtp -j DNAT --to-destination 192.168.0.97 \
--to-destination 192.168.0.99
iptables -t nat -I PREROUTING -d 213.201.69.198 -p tcp \
--dport pop3 -j DNAT --to-destination 192.168.0.96
iptables -t nat -I PREROUTING -d 213.201.69.198 -p tcp \
--dport domain -j DNAT --to-destination 192.168.0.100
iptables -t nat -I PREROUTING -d 213.201.69.198 -p udp \
--dport domain -j DNAT --to-destination 192.168.0.100
iptables -t nat -I PREROUTING -d 213.201.69.198 -p tcp \
--dport www -j DNAT --to-destination 192.168.0.101
Este DNAT provoca un balanceo de carga al 50% hacia los equipos C y D.

El pop3 va a A.

El DNS a B. El DNS suele consultarse mediante UPD, no lo olvidemos ...


El Web a E

Este conjunto de reglas de DNAT podrían simpificarse así:
iptables -t nat -I PREROUTING -i eth1 -p tcp \
--dport smtp -j DNAT --to-destination 192.168.0.97 \
--to-destination 192.168.0.99
iptables -t nat -I PREROUTING -i eth1 -p tcp \
--dport pop3 -j DNAT --to-destination 192.168.0.96
iptables -t nat -I PREROUTING -i eth1 -p tcp \
--dport domain -j DNAT --to-destination 192.168.0.100
iptables -t nat -I PREROUTING -i eth1 -p udp \
--dport domain -j DNAT --to-destination 192.168.0.100
iptables -t nat -I PREROUTING -i eth1 -p tcp \
--dport www -j DNAT --to-destination 192.168.0.101
En lugar de especificar una regla por cada una de las IP, indicamos que la condición se extiende a cualquier IP del eth1

No obstante, esto puede no ser adecuado si por ejemplo queremos contabilizar por IP los paquetes que sufren DNAT, que podemos obtener usando iptables -t nat -L -n -x -v . Tampoco servirá si el ordenador destino cambia en función de la IP, de hecho es nuestro caso, considerando la presencia del servidor F. Hemos introducido una máquina F que es un servidor smtp que no tiene nada que ver con los servidores C y D, a los que actualmente se redirige el tráfico al puerto smtp. Por ello necesita su propia IP externa. Esto causa modificaciones a R, concretamente añadimos:
ip a a 213.201.69.199/27 dev eth1
Otra IP externa
iptables -t nat -I PREROUTING -d 213.201.69.199 \
-p tcp --dport smtp \
-j DNAT --to-destination 192.168.0.85
DNAT hacia F

La configuración de F es la misma que A o B, etc.

Configuración de X:
ip a a 213.201.69.194/27 dev eth0
ip a a 213.171.69.250/29 dev eth0
ip rou add default via 213.171.69.249
Obvio
ip rou add default via 213.171.69.249 table R2
ip rou add default via 213.201.69.193 table R1
ip ru a from 213.201.69.194 table R1
ip ru a from 213.171.69.250 table R2
Dos tablas de rutas

Y sus reglas
iptables -t nat -A POSTROUTING -s 192.168.0.0/16 \
-j SNAT --to-destination 213.171.69.250
SNAT para la "Red ajena"

Obsérvese que, como en el ejemplo anterior, el tráfico en las líneas va a depender de lo que digan los DNS, no fporma parte de la configuración.

Las máquinas de la "Red ajena" usan a X para que haga SNAT". Su configuración es extremadamente simple.

Preguntas:
  1. ¿Cuál es el error de concepción de la "Red ajena"?
  2. Si queremos montar en E una colección de servidores web https, ¿cómo podemos hacerlo? (cada servidor ssl, virtual o real,  requiere una IP).
Un túnel IP-gre-IP ^
Este tipo de túnel va soportado directamente por el kernel de Linux. En la siguiente figura, ignoremos inicialmente las IPs en itálica.
A

 







 


150.128.81.251
 











192.168.254.254/32


 











 
150.128.80.1
 
internet  
213.171.69.249
 















B
150.128.82.211










 
213.171.69.250




red 150.128.80/21



red 213.171.69.248/29



150.128.81.194

Se trata de dos redes completamente distintas simplemente conectadas a través de Internet. Configurando A y B, deseo dar a B una IP de la red donde está A, concretamente la 150.128.81.194., y por supuesto, conectividad. Para ello establezco un túnel entre A y B del siguiente modo:

Configuración de A:
modprobe ip_gre
ip tunnel add tunelito mode gre \
remote 213.171.69.250 local 150.128.81.251
Creo un túnel gre entre A y B y llamo al dispositivo virtual tunelito.
ip addr add 192.168.254.254 dev tunelito
ip link set tunelito up
Le doy una IP y lo activo. La IP es una cualquiera, elijo esa IP privada.
ip route add 150.128.81.194 via 192.168.254.254
Podría poner: ip route add 150.128.81.194 dev tunelito
ip neigh add proxy 150.128.81.194 dev eth0
Proxyarp para la IP asignada a B

Configuración de B:
modprobe ip_gre
ip tunnel add tunelito mode gre \
remote 150.128.81.251 local 213.171.69.250
Creo un túnel gre entre A y B y llamo al dispositivo virtual tunelito.
ip addr add 150.128.81.194/16 dev tunelito
ip link set tunelito up
Le doy una IP y lo activo. Enruto toda la red 150.128.0.0/16 por el tunelito. ¡Ojo! He perdido la ruta real con 150.128.81.251
ip route add 192.168.254.254 via 150.128.81.194
Doy una ruta a la IP auxiliar que hay en A
ip route add 150.128.81.251/32 via 213.171.69.249
Este paso es necesario porque no puedo perder la ruta real a 150.128.81.251

Obsérvese que si accedo desde B a cualquier ordenador de la red de A, lo haré a través del túnel. Por ello los ordenadores verán un acceso desde 150.128.81.194 y no desde 213.171.69.250, que es lo que pretendo. Esto no es cierto para A, al que debo acceder sin túnel por necesidad (es quien soporta el túnel). Si quiero acceder de B a A a través del túnel lo haré con accediendo a la IP 192.168.254.254 y por ello B aparecerá ante A como 150.128.81.194.
Un ejercicio práctico ^
Un ordenador mío esté en una red privada de una empresa con conexión a Internet a través de un router con NAT. El router está configurado para realizar DNAT, de modo que si desde fuera de la empresa hago un ssh a la IP pública, el router redirige la conexión a éste ordenador. La IP actual del ordenador es 192.168.1.3 que pertenece al rango 192.168.1.X que es la red de la empresa, siendo la IP del router la 192.168.1.1.
Me notifica la empresa que por la tarde van a cambiar las IPs privadas de 192.168.1.X a 192.168.10.X por diversas razones, y quiero cambiar la IP de mi ordandor a la 192.168.10.3, teniendo en cuenta que la IP del router será 192.168.10.1. ¿Cómo lo hago?

Una primera solución es fácil: conecto por ssh, cambio la configuración del equipo y les digo a los de la empresa que reinicien el equipo cuando hayan cambiado las IPS. El ordenador estará sin red un tiempo indeterminado.

Otra solución sin requerir reinicio es: conecto por ssh, cambio la configuración del equipo sin hacer efectivos los cambios y dejo éste proceso en ejecución:

while ping -c 1 192.168.1.1 >/dev/null 2>&1; do sleep 1; done ; /etc/init.d/network restart
Es decir que cuando pierda el ping al router, reinicia sólo la red y coge la configuración nueva. El ordenador estará sin red unos segundos. Es una buena solución, salvo que haya un reinicio accidental antes del cambio de IP.

Una solución más complicada, es poner las 2 IPs al ordenador de modo que el cambio de IP ni se note apenas. Si hay un reinicio accidental no se notará si le pongo las 2 IPs por configuración. Para añadir la otra IP:

ip a a 192.168.10.3/24 dev eth0
Es más complejo de lo que parece, pues sólo funciona una ruta por defecto. Para poner dos rutas por defecto, debo crear dos tablas de rutado, por ejemplo la 10 y la 20 y proceder como sigue:
ip r add 192.168.1.1 dev eth0 tab 10
ip r add default via 192.168.1.1 tab 10
ip r add 192.168.10.1 dev eth0 tab 20
ip r add default via 192.168.10.1 tab 20
Ahora debo establecer cuando usar una tabla y cuando la otra:
ip rul add from 192.168.1.3 tab 10
ip rul add from 192.168.10.3 tab 20
Esto establece que cuando los paquetes salgan con dirección 192.168.1.3 usarán la tabla 10 y cuando la dirección seleccionada sea la 192.168.10.3 usarán la tabla 20. Para ello debo asegurarme que las redes son disjuntas, por ejemplo, que usan máscara 24, es decir que he configurado la red con:
ip a a 192.168.1.3/24 dev eth0
ip a a 192.168.10.3/24 dev eth0
Si por error la red actual fuera de máscara 16, es decir que hubiera sido configurada con
ip a a 192.168.1.3/16 dev eth0
habría problemas con las peticiones generadas desde el ordenador a la red 192.168.10.0/24, pues la IP 192.168.10.3 no se no se seleccionaría nunca como IP de origen. Tendría entonces que cambiar la máscara de red. La forma más segura de hacerlo es cambiando la configuración y reiniciando la red, pero en "plan suicida" podría ejecutar:
ip a d 192.168.1.3/16 dev eth0; ip a d 192.168.1.3/24 dev eth0; ip r add default via 192.168.1.1
Si me equivoco al ejecutar el comando me quedo sin acceso al equipo. Es necesario ejecutar los comandos separados por ";", si no, tras el primer comando me quedo sin red.

Ejemplos MIME ^

Un mensaje que contiene una página web con una imagen incrustada:
	MIME-Version: 1.0
	Content-Type: multipart/related; boundary=1904820100203140510CET

	--1904820100203140510CET
	Content-ID: <1904820100203140510CET.1>
	Content-Type: text/html
	Content-Transfer-Encoding: quoted-printable
	Content-Disposition: inline

	Esto es una imagen: <img =
	src=3D"cid:1904820100203140510CET.ca.gif">
	--1904820100203140510CET
	Content-ID: <1904820100203140510CET.ca.gif>
	Content-Type: image/gif; name="ca.gif"
	Content-Transfer-Encoding: base64
	Content-Disposition: inline

	R0lGODdhDQAJAIACAP8AAP//ACwAAAAADQAJAAACEIyPB8vNCY2bK0I6bcJOowIAOw==
	--1904820100203140510CET--

Un mensaje cifrado tiene este aspecto:

	Subject: Pruebas-(S)MIME
	MIME-Version: 1.0
	Content-Type: application/x-pkcs7-mime; name="smime.p7m"
	Content-Transfer-Encoding: base64
	Content-Disposition: attachment; filename="smime.p7m"
	Content-Description: S/MIME Encrypted Message

	MIAGCSqGSIb3DQEHA6CAMIIBggIBADGB9jCB8wIBADCBrDCBpTELMAkGA1UEBhMC
	RVMxETAPBgNVBAgUCENhc3RlbGzzMREwDwYDVQQHFAhDYXN0ZWxs8zEWMBQGA1UE
	ChMNTmlzdSBTZWN1cml0eTEXMBUGA1UECxMOQ2VydCBBdXRob3JpdHkxITAfBgNV
	BAMTGE5pc3UgU2VjdXJpdHkgQ0EgQ2xhc3MgMTEcMBoGCSqGSIb3DQEJARYNaW5m
	b0BuaXN1Lm9yZwICAWUwDQYJKoZIhvcNAQEBBQAEMBdOfJ7M0+80awpCStqW+W2o
	0ikvCjcXr7h71S1BeiUBCEgXp6Ygb+F2YciHBzhzjjCBgwYJKoZIhvcNAQcGMBQG
	CCqGSIb3DQMHBAhn8lpGTbJ7EIBgjHcc55BUOpGh+FXKFiaOPkBkt7Cs8eWtn88Q
	g+dSLCBBewhs6oAKLoLQQeRwl+AzVjFj97tEcrGRvDL4kwYlo86X59hlMQnxynUL
	Y/Dg5PlAep4AKZSMR+U0UYrJPfzMAAAAAA==
Como puede verse el cuerpo es un bloque cifrado que no puede leerse si no se es el propietario de la llave que lo descifra. Puede leerse empleando la llave y el certificado que están aquí.

El siguiente mensaje está firmado. Contiene dos partes, la primera es el mensaje sin firmar, que se compone a su vez de dos partes MIME y la segunda es la firma:

	Subject: Pruebas-(S)MIME
	MIME-Version: 1.0
	Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; 
		micalg=sha1; boundary="15284126535786313362"

	This is a cryptographically signed message in MIME format.

	--15284126535786313362
	Content-Type: multipart/mixed; boundary=1528412653578631336-1

	If you are reading this part you should use a MIME reader.

	--15284126535786313362-1
	Content-Type: text/plain
	Content-Transfer-Encoding: quoted-printable

	Este mail firmado lleva una peque=F1a imagen
	--15284126535786313362-1
	Content-Type: image/gif; name="sound2.gif"
	Content-Transfer-Encoding: base64
	Content-Disposition: inline

	R0lGODlhFAAWAMIAAP///8z//8zMzJmZmWZmZjMzMwAAAAAAACH+TlRoaXMgYXJ0IGlzIGlu
	IHRoZSBwdWJsaWMgZG9tYWluLiBLZXZpbiBIdWdoZXMsIGtldmluaEBlaXQuY29tLCBTZXB0
	ZW1iZXIgMTk5NQAh+QQBAAABACwAAAAAFAAWAAADUBi63P7OSPikLXRZQySmGyF6UCgKV8md
	m/FFHHqRVVvcNOzdSt7sr4CPMRS6VC8bsmcADIrMT/M5VBo3QYkzh81ufTce0Zph7sqMcBDN
	XiQAADs=
	--15284126535786313362-1--

	--15284126535786313362
	Content-Type: application/x-pkcs7-signature; name="smime.p7s"
	Content-Transfer-Encoding: base64
	Content-Disposition: attachment; filename="smime.p7s"
	Content-Description: S/MIME Cryptographic Signature

	MIAGCSqGSIb3DQEHAqCAMIIGzAIBATEJMAcGBSsOAwIaMIAGCSqGSIb3DQEHAQAA
	oIIFRjCCBUIwggQqoAMCAQICAgFlMA0GCSqGSIb3DQEBBAUAMIGlMQswCQYDVQQG
	EwJFUzERMA8GA1UECBQIQ2FzdGVsbPMxETAPBgNVBAcUCENhc3RlbGzzMRYwFAYD
	VQQKEw1OaXN1IFNlY3VyaXR5MRcwFQYDVQQLEw5DZXJ0IEF1dGhvcml0eTEhMB8G
	A1UEAxMYTmlzdSBTZWN1cml0eSBDQSBDbGFzcyAxMRwwGgYJKoZIhvcNAQkBFg1p
	bmZvQG5pc3Uub3JnMB4XDTk5MTIzMTEyMTI1NloXDTAwMTIzMDEyMTI1NlowgZMx
	CzAJBgNVBAYTAlhYMQ0wCwYDVQQIEwROb25lMQ0wCwYDVQQHEwROb25lMQ0wCwYD
	VQQKEwROb25lMQ0wCwYDVQQLEwROb25lMScwJQYDVQQDEx5UaGlzIGlzIGFuIGlu
	dmFsaWQgY2VydGlmaWNhdGUxHzAdBgkqhkiG9w0BCQEWEG5vbmVAbm9uZS5hdC5h
	bGwwTDANBgkqhkiG9w0BAQEFAAM7ADA4AjEAxJMJP2aUJ2ak95OgajEemVBw9Ucs
	YXS2L4guFbrzNKbCe0o3NupNvW4e5dtYC8NBAgMBAAGjggJiMIICXjAJBgNVHRME
	AjAAMCsGCWCGSAGG+EIBBAQeFhxodHRwOi8vY2EubmlzdS5vcmcvbmlzdTEuY3Js
	MIICIgYJYIZIAYb4QgENBIICExaCAg9UaGlzIENlcnRpZmljYXRlIGVuc3VyZXMg
	b25seSB0aGF0IHRoZSBzdWJqZWN0IHRoYXQgaGF2ZSByZXF1ZXN0ZWQgaXQgaXMg
	Y2FwYWJsZSBvZiByZWFkaW5nIHRoZSBtYWlsIHNlbnQgdG8gdGhlIGFkZHJlc3Mg
	aW5jbHVkZWQgb24gdGhlIERpc3Rpbmd1aXNoZWQgTmFtZS4gU28sIHRoaXMgQ2Vy
	dGlmaWNhdGUgZG9lcyBub3QgZXN0YWJsaXNoIGFueSByZWxhdGlvbiBiZXR3ZWVu
	IHRoZSBtYWlsIGFkZHJlc3MgYW5kIHRoZSByZXN0IG9mIHRoZSBkYXRhIGluY2x1
	ZGVkIG9uIHRoZSBEaXN0aW5ndWlzaGVkIE5hbWUsIHRoYXQgaGF2ZSBiZWVuIGlu
	Y2x1ZGVkIGluIHRoZSBDZXJ0aWZpY2F0ZSB3aXRob3V0IHByZXZpb3VzIHZhbGlk
	YXRpb24uIE5pc3UgU2VjdXJpdHkgZG9lcyBub3QgZ2l2ZSBhbnkgZ3VhcmFudGVl
	IGZvciB0aGlzIGNlcnRpZmljYXRlLCBhbmQgZG9lcyBub3QgaGF2ZSBhbnkgcmVz
	cG9uc2liaWxpdHkgaW4gYW55IGNpcmN1bXN0YW5jZS4gUmVhZCBodHRwOi8vY2Eu
	bmlzdS5vcmcvZGlzY2xhaW0uaHRtbDANBgkqhkiG9w0BAQQFAAOCAQEAwCZ8GBcq
	F7YcysBBc30JObb82i+Br6ucmQLvnu2FCowk1Mv/94V5tRR5gUnSojtnR4Gqp8I6
	U2NyFNxHgYczj6GEH33Vzm13nkg9k8SvsKUN6Pq7jpVHLdtoZkqpyFjcTkHS2FbW
	mXik3FjY+w8YGztf78SgZ8zIged0BBfVcKRjBDFnpKenQrWgntlZeqbO+i7lY6Wi
	AMCgj45L7inFa0JXV+V7+8q7nj4NT1Try/VmEH3nIgkN7D3CVg0uHMrZf/QbWTa0
	mA/9Y6BFwDs7WLsD1PK/9TW7SrB3J8dq3pXFAV7onl410Wk2Z2U6N/0vS3MjlgHZ
	qSDtgu0HgCWAOjGCAWEwggFdAgEBMIGsMIGlMQswCQYDVQQGEwJFUzERMA8GA1UE
	CBQIQ2FzdGVsbPMxETAPBgNVBAcUCENhc3RlbGzzMRYwFAYDVQQKEw1OaXN1IFNl
	Y3VyaXR5MRcwFQYDVQQLEw5DZXJ0IEF1dGhvcml0eTEhMB8GA1UEAxMYTmlzdSBT
	ZWN1cml0eSBDQSBDbGFzcyAxMRwwGgYJKoZIhvcNAQkBFg1pbmZvQG5pc3Uub3Jn
	AgIBZTAJBgUrDgMCGgUAoF0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq
	hkiG9w0BCQUxDxcNMDAwMjExMTA1NjQ5WjAjBgkqhkiG9w0BCQQxFgQUpjukrrfw
	2rb9f9BrmNDjCedNiKkwDQYJKoZIhvcNAQEBBQAEMCz6nT9sXV4V3DvjtuBpVnuY
	CSd3KUQJu/tIzueYdcwDKEQyWlrXltCE112jBTHQHAAAAAA=
	--15284126535786313362--
Elige estilo - Legal