Ix41 - Gestión de Servicios de Internet

Repaso de TCP/IP

ip link set dev eth0 up

 ip a a 194.1.2.2/24 dev eth0
#ip r a 194.1.2.0/24 dev eth0

 ip r a default via 194.1.2.1

Modelo Cliente/Servidor ^

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 2¹⁶ 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.

Cuestiones del tema ^

El súper servidor Inetd

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.

• Ú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.

Telnet

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

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.

Sobre la realización de las prácticas ^

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 ^

• 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 ^

• 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).

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

ssh-keygen -t rsa

cat ~/.ssh/id_rsa.pub

ssh servidor "cat >>~/.ssh/authorized_keys" <~/.ssh/id_rsa.pub

ssh servidor ls

ssh -fN -L 2500:localhost:25 miuser@elservidor

ssh -fN -L 2500:elservidor:25 miuser@otramaquina

ssh -fN -R 969:localhost:969 root@maquina

ssh -X user@maquina firefox

eval $(ssh-agent)

ssh-add

ssh -A servidor1

ssh servidor2

ssh -A servidor1

ssh-add

exit

ssh servidor2

ssh -A servidor0 ssh -A servidor9 ssh-add

for s in 1 2 3 4 5 6 7 8 9; do
  ssh -A servidor0 "ssh servidor$s 'cat >fichero'" <fichero
done

Rsync ^

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

rsync -e ssh --bwlimit=10 -acvP *.avi mon@servidor:sueltos/

command="rsync --server --daemon --config=rsyncd.conf ."

[ejemplo]
  path = /home/yomismo/cosas/
  use chroot = no
  read only = no

rsync -e ssh yomismo@servidor::

rsync -e ssh -a yomismo@servidor::cosas/. .

rsync -e ssh -a yomismo@servidor::cosas/..

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.

#!/bin/bash
while true; do
  l=$(  l=${l%% *}
  l=${l/./}

  [ $l -le 200 ] && break
  sleep5
done

rsync -aP --bwlimit=5000 "$1" "$2" && rm "$1"

dd if=/dev/null seek=102400 bs=102400 count=0 of=fichero

Network File System (NFS) ^

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),...

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

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 ^

for s in 1 2 3 4 5 6 7 8 9; do
  ssh -A servidor0 "scp fichero servidor$s;"
done

ssh -A servidor0 "scp 'fichero' servidor$s;"

ssh -A servidor0 "ssh servidor$s 'cat >\"fichero\"'" <"fichero"

ssh -fn MAQ2 "while true; do xwd -display :0 -name miVentanita | convert - gif:- \
		| ssh MAQ1 'cat >volcado.gif'; sleep 1m; done"

		#!/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"
	  

rsync -e ssh -aP MAQ:archivo .

rsync -e "ssh MAQ" -aP "":archivo .

rsync -e "ssh -A MAQ_INT ssh" -aP MAQ:archivo .

	  eval $(ssh-agent)
	  ssh-add
	  ssh -A B ssh C comando
	  

command="ls" ssh-rsa AAAAB............PPsKEZk= pepito@jame

	  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

	  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

	  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
	  

	  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
	  

	  rsync -e ssh -aP am1:archivo .
	  

	  while ! rsync --bwlimit=8 -aP servidor:archivo . ; do sleep 1m; done
	  

	  for f in $(<archivo-lista) ; do
	    rsync -aP $f .
	  done

	  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:

	  ssh -n $h "dd if=/dev/zero bs=$bs count=$[ta/bs+1] of='$f'"

	  #!/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
	  

	  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"

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.

Delegación de autoridad ^

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 ^

Relación entre servidores ^

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 ^

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; };
};

logging {
  category lame-servers {
    null; };
};

zone "." {
  type hint;
  file "root.hint";
};

zone "mobelt.com" {
  type master;
  file "master/mobelt.com";
};
zone "asgn.com" {
  type slave;
  file "slave/asgn.com";
  masters { 213.98.42.173; };
};

zone "168.192.in-addr.arpa" {
  type master;
  file "master/168.192.in-addr.arpa";
};

key dyn.mia {
  algorithm HMAC-MD5;
  secret "gvcn43v518=";
};
zone "dyn.nisu.org" {
  type master;
  file "dyn/dyn.nisu.org";
  allow-update {
    key dyn.mia;
  };
};

$TTL 300

@         IN SOA mobelt.com.
                 root.mobelt.com. (
          	158    ; serial number
                10800  ; time to refresh
                3600   ; time to retry
                604800 ; expire
                86400  ; mínimum TTL
              )

          IN NS    dns.mobelt.com.
          IN NS    dns2.mobelt.com.

          IN A     89.128.67.11

          IN MX 10 mail
          IN MX 20 mail2

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

www       IN A     89.128.67.11
pelis     IN A     89.128.67.11

litus     IN A     89.128.67.11
www.litus IN A     89.128.67.11

pepe      IN NS    ns.soypepe.com.

otro      IN NS    ns.otro
ns.otro   IN A     94.23.10.112

pop       IN A     150.128.97.91
          IN A     150.128.97.92

*         IN A     89.128.67.11

3.30      IN PTR   portatil-eth.casa.

zone "1.0.8.0.e.f.f.3.ip6.int" {
  type master;
  file "3ffe:0801";
};

La resolución de nombres en un ordenador ^

nameserver 1.2.3.4
nameserver 6.7.8.9
search patata.com

Cuestiones del tema ^

	  pepe	IN	NS 1.2.3.4

	  pepe		IN	NS	dns.pep
	  dns.pepe	IN	A	1.2.3.4

	  domi. IN NS 150.123.45.67

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

Las direcciones de correo

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 ^

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.

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 ^

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

220 ESMTP mobelt

helo mobelt.com
250 mobelt.com

mail from: prueba1@nisu.org
250 2.1.0 Ok

rcpt to: prueba2@mobelt.com
250 2.1.5 Ok

data
354 End data with <CR><LF>.<CR><LF>

Subject:ejemplo smtp

Hola
.

250 2.0.0 Ok: queued as A74C14D5BF

quit
221 2.0.0 Bye

Relays, spam ^

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

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 ^

• 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.

telnet anubis.uji.es pop3

user mollar
pass torpedo

list
+OK 3 visible messages (163026 octets)
1 34325
2 3631
3 21426

retr 3
dele 3

quit

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 ^

• 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.

echo test | sendmail alguien@dominio.com

echo $'Subject: prueba\n\nHola' | sendmail -f yo@midominio.com alguien@dominio.com

Formato del mensaje ^

/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

	  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--

Cuestiones del tema ^

	  @	IN MX 10 mail.pepito.com
	  mail	IN A 192.192.192.192

echo "user lukas
	  pass pelucas
	  dele 1
	  quit" | netcat localhost 110

	  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

	  :0
	  *^X-mio: envio
	  estebuzon

	  formail -s uudecode <estebuzon
	  unrar ....

	  if [ "$1"]; then
	    sendmail -f yo@miemail.com -F "Mi nombre" $* <mail.txt
	    sleep 1m
	  else
	    cat destinatarios | xargs -r -n 100 $0
	  fi
	  

	  	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

	  for ((i=0; i<30000; i++)); do
	    al=al$(printf "%06d" $i)
	    sendmail $al@anubis.uji.es < fichero_con_el_mail
	  done

	  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

	  export SPLITSIZE=1000000
	  tar zcvf - archivos | mail destino

	  rar a -vn -v1000 -ep trozos.rar archivos
	  for f in trozos.r*; do mutt -a $f destino; done
	  

	  host -t mx dominio_de_mail_de_mi_amigo

	  (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

El lenguaje PHP

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.

Cuestiones del tema ^

	  <? $f=fopen('contador','r');
	     $co=fread($f,400);
	     fclose($f);
	     $co=$co+1;
	     echo $co;
	     $f=fopen('contador','w');
	     fwrite($f,$co); fclose($f);
	  

	  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";
	  

	  <a href="/busqueda.php?ID=4043">Albengibre</a>
	  <a href="/busqueda.php?ID=4044">Alatoz</a>

	  for ((i=1; i<8111; i++)); do
	    GET "LAWEB/busqueda.php?ID=$i" >"pueblo$i.html"
	  done

	  <?
	    session_start();
	    echo "Las visitas a esta página son: ".($_SESSION['contador']++);

	  telnet al.nisu.org 80
	  GET / HTTP/1.1
	  Accept: text/html

	  HTTP/1.1 400 Bad Request

	  <?
	    $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);

	  <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>

	  while true; do
	    p=ABCabc$RANDOM;
	    GET "http://portal/dir/reg.php?user=usu$RANDOM$RANDOM&pass=$p&pass2=$p";
	  done

Ejemplos de configuración clásica de redes ^

 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

 ip r a 194.1.2.128/25 via 194.1.2.5

 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

 ip a a 194.1.2.129/25 dev eth1
#ip r a 194.1.2.128/25 dev eth1

 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

 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

 ip r a 192.168.0.2/24 via 194.1.2.5

 ip r a 194.1.2.128/25 via 194.1.2.5

 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

 ip a a 192.168.0.1/24 dev eth1
#ip r a 192.168.0.0/24 dev eth1

 ip r a 194.1.2.128/25 via 192.168.0.2

 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

 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

 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

 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
		

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

iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -j MASQUERADE

iptables -t nat -I PREROUTING -p tcp --dport 8088 \
         -j DNAT --to-destination 192.168.0.3:8088

ip a a 192.168.0.3/24
ip rou add default via 192.168.0.1

 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

 ip a a 192.168.0.1/32 dev eth1

 ip r a 194.1.2.23 dev eth1

 ip nei add proxy 194.1.2.23

 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

iwlist wlan0 scan

iwconfig wlan0 essid el_essid

iwconfig wlan0 key 1234567890

iwconfig wlan0 ap 00:22:2D:42:DE:F3

Ejemplos de configuración moderna de redes ^

ip rout add default equalize \
   nexthop weight 10 via 212.95.203.73 \
   nexthop weight 10 via 213.171.69.249

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

ip r a 150.128.81.252 via 212.95.203.73

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

ip r a 150.128.81.252 via 212.95.203.73 src 212.95.203.75

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

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

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

ip r a 217.125.124.220/32 dev eth0 table R1
ip r a 213.171.69.250/29 dev eth0 table R2

ip r a default via 212.95.203.73 table R1
ip r a default via 213.171.69.249 table R2

ip rule add from 212.95.203.76 table R1
ip rule add from 213.171.69.250 table R2

ip a a 192.168.0.102/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.102 table R1

ip a a 80.59.218.92/32 dev eth0

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

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

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

ip rule add to 192.168.0.0/24 lookup main

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

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

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

ip rule add to 192.168.0.0/24 lookup main

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

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

ip a a 213.171.69.250/29 dev eth0
ip r a default via 213.171.69.249

ip r a 212.95.203.72/27 via 213.171.69.254

ip a a 192.168.0.96/24 dev eth0

ip rou add default via 192.168.0.98

ip a a 192.168.0.98/24 dev eth0

ip a a 213.201.69.198/27 dev eth1
ip a a 213.171.69.254/29 dev eth1

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

ip r d default via 213.171.69.249 table R2
ip r d default via 213.201.69.193 table R1

ip rule add from 213.201.69.198 table R1
ip ru a from 213.171.69.254 table R2

ip rule add to 192.168.0.0/24 lookup main

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

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

ip a a 213.201.69.199/27 dev eth1

iptables -t nat -I PREROUTING -d 213.201.69.199 \
	 -p tcp --dport smtp \
	 -j DNAT --to-destination 192.168.0.85

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

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

iptables -t nat -A POSTROUTING -s 192.168.0.0/16 \
	 -j SNAT --to-destination 213.171.69.250

modprobe ip_gre
ip tunnel add tunelito mode gre \
       remote 213.171.69.250 local 150.128.81.251

ip addr add 192.168.254.254 dev tunelito
ip link set tunelito up

ip route add 150.128.81.194 via 192.168.254.254

ip neigh add proxy 150.128.81.194 dev eth0

modprobe ip_gre
ip tunnel add tunelito mode gre \
       remote 150.128.81.251 local 213.171.69.250

ip addr add 150.128.81.194/16 dev tunelito
ip link set tunelito up

ip route add 192.168.254.254 via 150.128.81.194

ip route add 150.128.81.251/32 via 213.171.69.249

while ping -c 1 192.168.1.1 >/dev/null 2>&1; do sleep 1; done ; /etc/init.d/network restart

ip a a 192.168.10.3/24 dev eth0

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

ip rul add from 192.168.1.3 tab 10
ip rul add from 192.168.10.3 tab 20

ip a a 192.168.1.3/24 dev eth0
ip a a 192.168.10.3/24 dev eth0

ip a a 192.168.1.3/16 dev eth0

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

Ejemplos MIME ^

	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==

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--