O nivel de aplicación

Artículo copiado da páxina do IES S. Clemente de Santiago.

Contenido     1 Introdución 2 Arquitecturas de aplicacións en rede 2.1 Arquitectura cliente/servidor 2.2 Arquitectura P2P pura 2.3 Arquitecturas híbridas C/S e P2P 3 Comunicación de procesos 4 Protocolos do nivel de aplicación 4.1 O HTTP 4.1.1 Un pouco de historia 4.1.2 Conceptos previos 4.1.3 Características 4.1.4 Tipos de conexións 4.1.5 Mensaxes 4.1.5.1 Solicitudes 4.1.5.2 Respostas 4.1.6 As cookies 4.1.7 Servidores Proxy 4.1.8 Instalación e configuración do Apache 4.2 O File Transfer Protocol 4.3 O DNS 4.4 O correo electrónico

Introdución

Neste tema descríbese toda unha serie de aplicacións ou programas que utilizan a rede como medio de comunicación, así como os protocolos de comunicacións que teñen asociados. Devanditas aplicacións coñécense como aplicacións distribuídas, posto que están formadas por diferentes partes e cada unha se atopa en máquinas diferentes. Por norma xeral, hai unha parte chamada servidor que se executa nun computador, á que se conectan os diferentes clientes (que se atopan noutros computadores remotos) para requirir os seus servizos (polo xeral, solicitan a execución dalgún tipo de operación).

Existe unha gran cantidade de aplicacións que seguen este modelo e que, nalgúns casos, usamos diariamente, entre elas: o correo electrónico, a navegación Web, a mensaxería instantánea, a telefonía IP, o acceso remoto a outros computadores, a vídeoconferencia, a computación paralela masiva, a compartición de ficheiros, os xogos en rede multiusuario, a descarga de vídeo e audio e un longo etc.

Estas aplicacións empregan protocolos concretos para poder entenderse. Este protocolos atópanse no nivel de aplicación.

Arquitecturas de aplicacións en rede

As aplicacións execútanse en diferentes computadores no que se coñece como sistemas finais, e comunícanse mediante a rede. Por exemplo: un programa que fai de servidor Web comunícase cun programa navegador. Xa que logo, a comunicación para unha aplicación en rede ten lugar entre sistemas finais no nivel de aplicación.

Hai tres tipos de arquitecturas para as aplicacións en rede:

• Arquitectura Cliente/Servidor
• Arquitectura Peer-to-peer (P2P)
• Arquitectura híbrida entre cliente/servidor e P2P

Arquitectura cliente/servidor

O modelo ou arquitectura cliente/servidor está formado por dúas partes.

• O servidor. Sempre está funcionando (24x7) e ten unha dirección IP permanente. Pódense instalar granxas ou clusters de servidores para dar servizo a un maior número de usuarios.
• Os clientes. Poden estar conectados intermitentemente. As súas direccións IP son dinámicas. Os clientes non se comunican directamente entre eles, senón que o fan co servidor

Moitas das aplicacións de uso frecuente de Internet, como a navegación Web ou o correo electrónico, usan este modelo.

Arquitectura P2P pura

Este modelo ten unhas características diferenciadas respecto á cliente/servidor pura. Estas diferenzas son as seguintes:

• Non existe un servidor acendido permanentemente
• Non se distingue entre clientes e servidores, senón que existen sistemas arbitrarios finais, chamados peers, que se comunican directamente
• Os peers están conectados intermitentemente e cambian a súa dirección IP con frecuencia
• Todos os nodos teñen a mesma función, peso e importancia dentro da rede

Un exemplo de programa que usa unha arquitectura P2P pura é o software de intercambio de ficheiros Gnutella, que usa protocolo de distribución de ficheiros entre pares, sen un servidor central.

A principal vantaxe desta arquitectura fronte a anterior é que é moi escalable. Como contrapartida é máis difícil de xestionar.

Arquitecturas híbridas C/S e P2P

Son unha mistura das anteriores. De tal xeito que para algunhas funcións usan un servidor central e para outras fan unha comunicación directa con outro peer. Vexámolo con dúas aplicacións de exemplo:

• eMule. No programa de intercambio de ficheiros eMule a transferencia de ficheiros realízase mediante P2P. Con todo, a busca de ficheiros é centralizada xa que os pares, ou peers, rexistran contido nun servidor central (os ficheiros que comparten). Para localizar un contido, o pares consultan un servidor central ou varios servidores distribuídos, pero para a transferencia usan P2P.
• Mensaxería instantánea. As conversas que se manteñen entre dous usuarios realízase mediante P2P, pero o rexistro e localización é mediante C/S, é dicir, centralizada nun servidor. De feito, os usuarios rexistran a súa IP nun servidor cando arrincan o programa. Este servidor é un servidor central de contactos para IP de amigos.

Comunicación de procesos

Un proceso é un programa que se executa nun computador. Un proceso cliente é o que inicia a comunicación. Un proceso servidor é o que espera a ser contactado. Por exemplo: O programa dhclient lanza un proceso cliente que solicita unha dirección IP. O programa dhcpd espera a recibir peticións para respostar con direccións IP dinámicas aos clientes.

As aplicacións están formadas por varios procesos. No caso das arquitecturas P2P as aplicacións teñen procesos clientes e procesos servidores ao mesmo tempo.

Os procesos pertencen a un usuario que, normalmente, os lanza ou provoca que se lancen. Para ver os procesos dun usuario que se están executando nun computador para podes teclear:

ps ­-u nome_usuario

Nun computador pode haber varios procesos executándose polo que se identifican mediante un número de porto. Os procesos comunícanse uns cos outros a través dos sockets. Un socket especifica a dirección, o porto e o protocolo de transporte que se usa na comunicación. Por exemplo: (192.168.100.10, 80, TCP).

Protocolos do nivel de aplicación

Os procesos comunícanse enviándose mensaxes. As características destas mensaxes están determinadas no protocolo, o cal define:

• Os tipos de mensaxes que se intercambian, i.e: mensaxes de solicitude e resposta
• A sintaxe dos tipos de mensaxe, i.e: campos que terán as mensaxes
• A semántica dos campos, é dicir, o que significa a información dos campos das mensaxes
• As regras sobre cando e como os procesos poden enviar e respostar mensaxes

Os protocolos do nivel de aplicación poden ser de dominio público ou propietarios. No primeiro caso, están definidos nos RFC (Request For Comments). Ao estar publicamente accesibles permiten a interoperabilidade entre aplicacións de distintos fabricantes. Exemplos deste tipo de protcolos son HTTP (HyperText Transfer Protocol) ou o SMTP (Single Mail Transfer Protocol). No segundo caso é o fabricante dun determinado software quen o define e a interoperabilidade non está garantida. Un exemplo deste tipo de protocolos é o que usa a aplicación Skype.

O HTTP

Un pouco de historia

O HTTP naceu no 1989 no CERN (Centro Europeo de Investigación Nuclear). A Web xurdiu pola necesidade de lograr que os equipos de investigadores dispersos internacionalmente colaborasen, usando un conxunto sempre cambiante de informes, planos, debuxos, fotos e outros documentos.

A proposta inicial dunha rede (web) de documentos vinculados xurdiu do físico do CERN Tim Berners-Le. O primeiro prototipo estaba baseado só en texto. En decembro de 1991 fíxose unha demostración pública e o desenvolvemento continuou durante o seguinte ano, culminando coa liberación da primeira interface gráfica, Mosaic, no ano 1993. Mosaic tivo tanto éxito que, un ano despois, o seu autor, Marc Andreeseen formou a compañía, Netscape Communications Corp.

En 1994, o CERN e o M.I.T. asinaron un acordo para establecer o World Wide Web Consortium, unha organización adicada ao desenvolvemento da Web, a estandarización de protocolos e o fomento da interoperabilidade entre as instalacións. Berners-Le converteuse no director.

Conceptos previos

As páxinas Web están formadas por obxectos. Os obxectos poden ser ficheiros HTML, imaxes, ficheiros de audio, vídeo, etc. Unha páxina web é un ficheiro HTML base que inclúe varias referencias aos obxectos. A cada obxecto accédese mediante unURL (Uniform Resource Locator) que ten a seguinte forma:

Características

O HTTP é un protocolo do nivel de aplicación para a Web. Segue o modelo ouarquitectura cliente/servidor, tal e como se ve na figura. O cliente é un navegador (browser) que solicita, recibe, e mostra obxectos Web. O servidor Web envía obxectos como resposta ás peticións do cliente. Hai dúas versións do protocolo, o HTTP 1.0, especificada no RFC 1945, e o HTTP 1.1, especificado no RFC 2068.

HTTP utiliza TCP como protocolo de transporte. Os clientes inician conexións TCP (crean un socket) co servidor, no porto 80. Os servidores aceptan conexións TCP dos clientes. Unha vez establecida a conexión intercámbianse mensaxes HTTP (mensaxes do protocolo do nivel de aplicación) entre o cliente (cliente HTTP) e o servidor Web (servidor HTTP). Finalmente, péchase a conexión TCP.

HTTP non ten “estados” (stateless). Isto quere dicir que o servidor non mantén información sobre solicitudes anteriores dos clientes. Deseñouse así porque os protocolos que manteñen o estado son complexos, xa que hai que manter un histórico do que acontece (estado). Se o cliente ou o servidor fallan pode haber inconsistencias e deberán volver ao estado anterior, co correspondente consumo de recursos.

Tipos de conexións

As conexións HTTP poden ser de dous tipos:

• Conexión non persistentes. Nelas, envíase un obxecto como máximo en cada conexión TCP. Para cada nova petición do cliente precísase unha nova conexión TCP. HTTP/1.0 utiliza HTTP non persistente. Por exemplo, se unha páxina Web ten referencias a 10 obxectos, abriranse 10 conexións TCP.
• Conexións persistentes. Envíanse varios obxectos nunha única conexión TCP entre o cliente e o servidor. HTTP/1.1 utiliza conexións persistentes por defecto. As conexións persistentes supoñen menos sobrecarga para o SO xa que os navegadores non abren varias conexións TCP paralelas para conseguir os obxectos referenciados. O servidor deixa a conexión TCP aberta despois de enviar unha resposta, xa que logo, as mensaxes HTTP entre o mesmo cliente e servidor usan a mesma conexión TCP.

Mensaxes

En HTTP hai mensaxes de solicitude e mensaxes resposta. Ambas as dúas mensaxes están en formato ASCII, polo que poden verse e lerse se capturamos unha sesión HTTP cun analizador de rede como, por exemplo, o Wireshark.

Solicitudes

Unha mensaxe HTTP de solicitude ten o seguinte formato:

Se queremos facer unha solicitude de envío de datos (por exemplo, cando facemos unha consulta nun buscador enviámoslle ao servidor a palabra a buscar, ou cando enviamos un formulario) podemos usar dous métodos:

• Método POST, no que os datos se envían ao servidor dentro da mensaxe de solicitude HTTP.
• Método URL, tamén chamado método GET, no que os datos se envía na URL da liña de solicitude, por exemplowww.unsite.com/buscaAnimal?mono&banana

Dependendo da versión do protocolo que se use están soportadas distintas mensaxes HTTP (tamén coñecidas como métodos):

• Para HTTP 1.0: están soportadas as mensaxes GET e POST xa vistas. Tamén está soportada a mensaxe HEAD que só devolve a cabeceira, non o obxecto referenciado
• Para HTTP 1.1: están soportadas as tres mensaxes anteriores e tamén PUT, que permite subir o ficheiro especificado no URL ao servidor, e DELETE, que permite borrar o ficheiro especificado no URL.

Respostas

As mensaxes HTTP de resposta teñen un formato similar ás de solicitude:

As mensaxes de resposta inclúen un código dependendo do significado da mesma. Dito código vai na primeira liña da mensaxe (liña de estado). Algúns exemplos son os seguintes:

200 OK
Solicitude correcta, envíarase o obxecto solicitado nesta mensaxe   301 Moved Permanently
Obxecto solicitado noutro URL, especifícase a nova localización nesta mensaxe (Location:)   400 Bad Request
Mensaxe non entendida polo servidor   404 Not Found
Obxecto solicitado non atopado no servidor   505 HTTP Version Not Supported

As cookies

Dixemos que HTTP é un protocolo sen estado. Isto, ás veces, pode non ser o desexado. Por exemplo, supoñamos que temos unha web na que as súas páxinas están restrinxidas a determinados usuarios. Se non mantemos o estado do cliente teremos que estar solicitándolle para cada páxina que queira ver o seu nome de usuario e clave. HTTP resolve este escenario coas cookies.

As cookies están definidas no RFC 2109 e permiten monitorizar a navegación do usuario. Moitos sites usan cookies. Son útiles, por exemplo, para validar un usuario, escoller opcións personalizadas (idioma, etc.), rexistrar hábitos de navegación, etc. Están formadas por catro compoñentes:

1. Liña de cabeceira da cookie na resposta HTTP.
2. Liña de cabeceira da cookie na solicitude HTTP.
3. Ficheiro que se mantén no computador do cliente, xestionado polo navegador.
4. Base de datos no servidor.

Un exemplo de funcionamento das cookies podémolo ver na figura.

Servidores Proxy

Dun modo xenérico, pódese definir un proxy como un software que fai de intermediario entre un cliente e un servidor. Os proxies en HTTP úsanse, entre outras cousas, para facer de caché das páxinas visitadas. É o que se coñece como un Web cache e o seu obxectivo é respostar aos clientes sen interactuar co servidor, gañando en velocidade, xa que o proxy está normalmente na mesma rede ou máis cercano que o servidor Web que contén a páxina orixinal.

O proxy configúrase no navegador. É o navegador quen envía as solicitudes HTTP ao proxy. Se o obxecto está na cache o proxy é quen o devolve. Se non, o proxy solicita o obxecto ao servidor orixinal que á súa vez é enviado ao cliente. O proxy ten, xa que logo, unha parte cliente e outra servidor. Normalmente instálanse en universidades, compañías, ISP, etc., para axilizar o tráfico. Entre as vantaxes de usar un servidor proxy están as seguintes:

• Reducir o tempo de resposta das solicitudes dos clientes.
• Reducir o tráfico, e polo tanto ampliar o largo de banda.
• Filtrar contido.

Un exemplo de software de servidor proxy é o Squid.

Instalación e configuración do Apache

Instalación e configuración do servidor Web Apache

O File Transfer Protocol

O FTP

O DNS

O DNS

O correo electrónico

O correo-e

Servidor DNS en Ubuntu

1.- Instalación del servidor de DNS

Los Servidores de DNS nos facilitan la adiminstración de los nombres de los equipos de un sitio, sin ellos tendríamos que asignar en cada equipo los nombres e ip en el fichero /etc/hosts. Los servidores de DNS se pueden clasificar en:

• Primarios o maestros: cuando obtiene la información de sus zonas de sus archivos locales que es en los que se realizan todas las modificaciones de la zona.

• Secundarios o esclavos: obtienen la información de su zona de otro servidor -generalmente primario-, es decir, contienen “una copia” de sólo lectura de la zona.

• Caché: sólo atienden consultas de los clientes y no contienen ningún tipo de información de la zona, se emplean sólo para acelerar las consultas.

Se define un servidor de nombres de dominio DNS autoritario para una zona como aquel que contiene los registros de recursos para dicha zona (SOA y NS). Cada zona puede tener uno o más servidores autoritarios y al menos, uno de ellos debe ser primario.

Existen varios paquetes de servicios de servidores de dominio. La mas conocida y usada es BIND, para instalarlo:

# apt-get install bind9 bind9-doc dnsutils

1.1 Configuración del servidor DNS Bind

El servicio de DNS está compuesto, básicamente por dos programas: el demonio named -el servidor de nombres de dominio y el resolver -cliente que genera las peticiones-. El archivo de configuración del demonio named se encuentra en /etc/bind/named.conf, aunque desde aquí se cargará el fichero /etc/bind/named.conf.local que es -en la versión que he instalado- en el que introduciremos las zonas de búsqueda directa e inversa y el nombre de los ficheros dónde configuraremos dichas zonas, en mi caso /etc/bind/db.mczones.es y /etc/bind/db.192.168.2. Si queremos que el servidor haga uso del servidor instalado tendremos que añadir su dirección ip en el fichero /etc/resolv.conf también.

Los siguientes son los ficheros para configurar la zona “mczones.es” y los servidores -maestro- y clientes incluidos en dicha zona tanto para búsqueda directa como inversa.

Fichero: /etc/bind/named.conf.local

zone "mczones.es" {

type master; Maestro o servidor principal

allow-query {127.0.0.1; 192.168.2.3/24;}; dejamos activas las consultas internas y a la máquina local

allow-transfer {127.0.0.1; 192.168.2.3/24;}; restringir las transferencias de zona a estas ip

allow-update {127.0.0.1; 192.168.2.3/24;}; permitir actualizaciones desde estas ip -el propio servidor-

file "/etc/bind/db.mczones.es"; fichero dónde configuraremos los equipos de la zona

};

//Resolución Inversa

zone "2.168.192.in-addr.arpa" {

type master;

allow-query { 127.0.0.1; 192.168.2.3/24; };

allow-transfer { 127.0.0.1; 192.168.2.3/24;};

allow-update {127.0.0.1; 192.168.2.3/24;};

file "/etc/bind/db.192.168.2";

};

Fichero de configuración /etc/bind/db.mczones.es

$ttl 604800

mczones.es. IN SOA servidorubuntu.mczones.es. root.mczones.es. ( ;Servidor autoritario y email

3 ; Serial

604800 ; Actualizar cada en segundos

86400 ; Reintentar en segundos

2419200 ; Tiempo en que expira en segundos

604800 ) ; Cache TTL Negativa

; en caso de no añadir la dirección de email en el SOA, la versión que he instalado, no interpreta bien el fichero

@ IN A 192.168.2.3 ;asocia nombre de dominio a una dirección ip

@ IN NS servidorubuntu.mczones.es. ; Servidor de nombres autorizado para esta zona

; Servidores

servidorubuntu IN A 192.168.2.3 ; asocia una ip a un nombre de equipo

servidor IN CNAME servidorubuntu ;alias para el servidor ; asocia otro nombre/alias a un nombre existente

; Estaciones de trabajo

juan-cliente IN A 192.168.2.2

clienteubuntu IN CNAME juan-cliente

anfitrion IN A 192.168.2.1

Fichero /etc/bind/db.192.168.2

$ttl 604800 ; Fichero para resolución inversa

2.168.192.in-addr.arpa. IN SOA mczones.es. root.mczones.es. (

3

604800

86400

2419200

604800 )

;

@ IN A 192.168.2.3

@ IN NS servidorubuntu.mczones.es.

;servidores internos

3 IN PTR servidorubuntu.mczones.es.

;estaciones

2 IN PTR juan-cliente.mczones.es.

1.2.168.192.in-addr.arpa. IN PTR anfitrion.

1.2 Otras comprobaciones de Configuración

Podemos reiniciar el servicio tras modificar los ficheros y comprobar el log del sistema para verificar que no hay errores en el arranque de named en el fichero /var/log/syslog:

# /etc/init.d/bind9 restart

# tail -15 /var/log/syslog

También podremos emplear los comandos dig – por ejemplo dig any servidorubuntu.mczones.es o dig @192.168.2.3 mczones.es-, host - host clienteubuntu.mczones.es-, nslookup -nslookup anfitrion.mczones.es- o directamente con ping -ping juan-cliente.mczones.es-.

Para asegurarnos de que se crean los enlaces simbólicos para que al arrancar el equipo se inicie el servicio de DHCP podemos teclear # update-rc.d bind9 defaults. Si necesitamos parar el servicio: sudo /etc/init.d/bind9 stop (con start o restart para iniciarlo o reiniciarlo respectivamente o force-reload para cargar las opciones que hemos cambiado en la configuración).

2.- Archivos de zona y archivos de resolución inversa de la zona.

Para resolver los nombres los servidores DNS consultan las zonas, los cuales contienen registros de recursos (RR) que describen la información relativa al dominio DNS.

El formato de cada regsitro de recursos es:

Propietario TTL Clase Tipo RDATA

Dónde:

• Propietario: nombre de máquina o dominio DNS al que pertenece el recurso. Puede ser un nombre de una máquina, @ -zona que se está describiendo- o cadena vacía representando al propietario del registro anterior.

• TTL: Tiempo de vida o número de segundos que puede estar el registro en caché. Es opcional y puede expresarse en segundos, dáis, horas y/o minutos.

• Clase: define la familia de protocolos en uso. Por defecto IN (Internet), indicando red TCP/IP.

• RDATA: Información específica del tipo de recurso. Por ejemplo para un registro IN de tipo A, especificará una dirección IP.

• Tipo: identifica el tipo de registro. Para la clase IN:

  • SOA: Inicio de autoridad. Identifica el servidor autoritario de una zona y sus parámetros de configuración.

  • NS: Servidor de Nombres. Identifica servidores de nombres autorizados para una zona.

  • A: Dirección: asocia un nombre de dominio FQDN con una dirección IP.

  • PTR: Puntero: asigna una dirección IP a un nombre de dominio completamente cualificado para las búsquedas inversas.

  • MX. Registro de correo: indica equipos encargados de la entrega del correo en el dominio.

  • CNAME: Nombre canónico. Permite asignar uno o más nombres a una máquina.

  • TXT. Text: almacena cualquier información.

  • SRV. Servicios: ubicación de los servidores para un servicio o protocolo determinado. El formato de un registro SRV es el siguiente:

    

    Ejemplos:

  • juan-cliente IN A 192.168.2.2

  • clienteubuntu IN CNAME juan-cliente

  • http.tcp.mczones.es. IN SRV 0 0 80 www.mczones.es

  • ftp.tcp.mczones.es IN SRV 0 0 21 ftp.mczones.es

 

3.- Ficheros que intervienen en las configuraciones.

Ficheros de configuración del servidor DNS:

• /etc/bind/named.conf: fichero de configuración del demonio named. En las versiones actuales, desde este fichero se llama al fichero -mediante un include- named.conf.local que es el que debemos modificar.

• /etc/bind/named.conf.local: fichero en el que configuramos las zonas de búsqueda directa e inversa y especificamos el nombre de dichos ficheros en mi caso db.mczones.es y db.192.168.2.

• /etc/init.d/bind9: ejecutable al que se le pasa el parámetro: stop, start, restart o force-reload para parar, iniciar, reiniciarlo o para cargar las opciones que hemos cambiado en la configuración respectivamente.

4.- Configuración mediante webmin

Webmin es una aplicación web que nos permitirá configurar numerosas características de nuestro servidor como ip, paquetes,.... En nuestro caso se puede emplear para instalar/configurar también los servicios de DNS y DHCP.

Para instalarla nos bajamos la última versión disponible en la página web del proyecto - http://www.webmin.com/ - , dónde podremos encontrar los fuentes para compilar, o bajarnos directamente el paquete deb para Ubuntu o Debian . Yo he empleado este último y lo he instalado con gdebi (apt-get install gdebi). Para ello simplemente teclearemos en la consola:

# gdebi webmin_1.500_all.deb

Una vez lo hayamos instalado, tan sólo debemos abrir un navegador web e introducir la ip de nuestro servidor, en mi caso localhost, y conectarnos con el puerto 10000, dónde nos pedirá que introduzcamos un nombre de usuario (root o alguno con privilegios de administrador) y su contraseña. Tras esto entraremos en la interfaz de la aplicación que nos permitirá realizar múltiples consultas y modificaciones tal y cómo se puede ver en la siguiente imagen:

para continuar viendo el resto de manuales Linux siga el enlace:administración de servidores con Linux

 

Bibliografía y enlaces:

BIND para mortales - Mexico Extremo RC3

Práctica Sistemas de Videovigilancia

1. Configurar el equipo Servidor de videovigilancia con la cámara web AXIS. Localiza el software de la cámara en Internet e instálalo en el equipo. Establece la configuración de red (IP y máscara que estimes pertinente)

1. Una vez instalada y configurada comprueba su funcionamiento desde un equipo cliente.

1. Realiza una documentación técnica indicando los pasos realizados en los ejercicios anteriores.

1. Configurar el equipo Servidor de videovigilancia con la cámara web Logitec. Localiza en Internet un software que permita realizar tareas específicas de videovigilancia (capturar imágenes, movimientos, …). Elabora una especie de manual de usuario con las opciones de configuración del programa.

1. Exposición en clases de la documentación desarrollada.

1. Resolución de preguntas sobre el servicio y la práctica desarrollada.

NOTAS:

1. Las 3 primeras sesiones no se resolverán dudas relativas a la práctica.
2. Toda la documentación relativa a la práctica deberá ser entregada el jueves siguiente antes de comenzar la realización de la práctica siguiente, en caso contrario se considerará que no ha sido superada.

Práctica configuración de enrutadores (router)

1. Leer el manual y configurar el enrutador para que sus datos coincidan con el de la imagen. ¿Cuál es la ip de la interfaz externa? Razona porqué.

1. Asignar una ip dinámica a los equipos 1 y 2 mediante el Enrutador, de modo que queden incluidos en la misma red. Realizar un ping desde el equipo1 al equipo2. (equipo 1 y equipo2 deben estar ejecutándose en Linux en la máquina virtual). Captura una pantalla realizando ping de un equipo a otro. En qué red (escribe la ip) están el equipo 1 y 2 ¿porqué?, razona la respuesta.

1. Los equipos 1 y 2 no salen a internet. ¿Sabes a qué puede ser debido?. Habilita la salida a Internet del Equipo1. Documenta la solución

1. Instala apache en el equipo1. Comprueba que sirve la página inicial en el equipo local –equipo1. (captura la pantalla).

1. Configura el enrutador para permitir el acceso desde equipo exterior al servidor web en equipo1. Haz una captura de pantalla dónde se muestre la página web inicial de dicho equipo accediendo desde la red externa.

1. Documentación técnica indicando los pasos realizados para resolver los ejercicios (presentación odt –openoffice.org-)

1. Exposición en clases de la documentación desarrollada.

1. Resolución de preguntas sobre el servicio y la práctica desarrollada.

NOTAS:

1. Las 3 primeras sesiones no se resolverán dudas relativas a la práctica.
2. Toda la documentación relativa a la práctica deberá ser entregada el jueves siguiente antes de comenzar la realización la siguiente, en caso contrario se considerará que no ha sido superada.

Práctica PLC y cámara web inalámbrica (OvisLink)

1. Instala los dos plc y configúralos. En uno irá conectado el servidor de videovigilancia y en el otro la máquina cliente (máquina virtual).

1. Configurar el equipo Servidor de videovigilancia con la cámara web Ovislink. Localiza el software de la cámara instálalo en el equipo. Establece la configuración de red (IP y máscara que estimes pertinente)

1. Una vez instalada y configurada comprueba su funcionamiento desde un equipo cliente.

1. Realiza una documentación técnica indicando los pasos realizados en los ejercicios anteriores.

1. Configurar el equipo Servidor de videovigilancia con la cámara web Logitec. Localiza en Internet un software que permita realizar tareas específicas de videovigilancia (capturar imágenes, movimientos, …). Elabora una especie de manual de usuario con las opciones de configuración del programa.

1. Exposición en clases de la documentación desarrollada.

1. Resolución de preguntas sobre el servicio y la práctica desarrollada.

NOTAS:

1. Las 3 primeras sesiones no se resolverán dudas relativas a la práctica.
2. Toda la documentación relativa a la práctica deberá ser entregada el jueves siguiente antes de comenzar la realización de la práctica siguiente, en caso contrario se considerará que no ha sido superada.

Práctica configuración red inalámbrica

Dentro de las clases de redes y empleando el hardware  disponible para ello realizar las siguientes prácticas y respondiendo a las siguientes cuestiones:

1. Leer el manual y configurar el enrutador para que sus datos coincidan con el de la imagen. ¿Cuál es la ip de la interfaz externa? Razona porqué.
2. Instala las tarjetas de red inalámbricas en la máquina virtual bajo Windows XP
3. Qué algoritmos de encriptación puedes emplear en el router. ¿Cuál de los disponibles has empleado y por qué?¿Cuál es la ventaja de usar algún algoritmo de encriptación?
4. ¿Qué medidas de seguridad puedes emplear al usar redes inalámbricas? ¿Cuáles pueden ser implementadas en este router?¿Qué buscas configurando el router con dichos parámetros?
5. Asignar una ip dinámica a los equipos 1 y 2 mediante el Enrutador, de modo que queden incluidos en la misma red empleando los mecanismos de seguridad que habrás descrito previamente. Realizar un ping desde el equipo1 al equipo2. (equipo 1 y equipo2 deben estar corriendo Windows XP en la máquina virtual). Captura una pantalla realizando ping de un equipo a otro. En qué red (escribe la ip) están el equipo 1 y 2 porqué, razona la respuesta.
6. Los equipos 1 y 2 no salen a internet. ¿Por qué?. Habilita la salida a Internet del Equipo1. Documenta la solución.
7. REALIZAR ESTE PUNTO SÓLO SI DISPONÉIS DE TIEMPO SUFICIENTE: Existe software para intentar revelar claves en redes inalámbricas, que algoritmo de encriptación resulta más fácil de revelar. Usa alguno de los programas disponibles para intentar descubrir la clave de vuestra red. (captura una pantalla realizando dicho proceso).
8. Documentación técnica indicando los pasos realizados para resolver los ejercicios (presentación odt –openoffice.org-)
9. Exposición en clases de la documentación desarrollada.
10. Resolución de preguntas sobre el servicio y la práctica desarrollada.

NOTAS:

1. Las 3 primeras sesiones no se resolverán dudas relativas a la práctica.
2. Toda la documentación relativa a la práctica deberá ser entregada el jueves siguiente antes de comenzar la realización la siguiente, en caso contrario se considerará que no ha sido superada.

Servidor de DHCP en Ubuntu

Siguiente entrega de la serie administración de servidores con Linux:

1.- Instalación del servidor de DHCP

Antes de comenzar la configuración del servidor hay que asegurarse de que el núcleo tiene instalada la opción MULTICAST que es necesaria para llevar a cabo la asignación de direcciones de multidifusión. Para comprobarlo tecleamos

# ifconfig

debería aparecernos una línea como

ARRIBA DIFUSIÓN CORRIENDO MULTICAST MTU:1500 Métrica:1

en caso de no aparecer deberíamos recompilar el núcleo añadiendo la opción IP: multicast routing.

La última versión del servidor DHCP es dhcp3. El servidor proporcionará al cliente al menos los siguientes parámetros: dirección IP y máscara de subred, opcionalmente podríamos emplearlo para asignar otros valores como puerta de enlace, servidores DNS, ...

Para instalar el servidor podemos emplear aptitude, Synaptic,... o simplemente:

# apt-get install dhcp3-server
//versión actual (tras hacer apt-get update)
apt-get install isc-dhcp-server

1.1.- Configuración del servidor DHCP

La configuración del servidor se lleva a cabo en el fichero /etc/dhcp3/dhcpd.conf (en la nueva versión está en /etc/dhcp/dhcpd.conf), se compone de dos partes:

• Parámetros: dónde configuramos el comportamiento del servidor. Por ejemplo: max-lease-time 86400; suelen ir al comienzo del fichero.
• Declaraciones: las empleamos para describir las redes, máquinas y rangos de direcciones que concederemos a los clientes. Nos permiten anidar unas declaraciones dentro de otras. Por ejemplo host {….}

Los rangos de direcciones IP se especifican en secciones que empiezan con la palabra clave 'subnet' seguido de la dirección de red de la subred, continúa con la palabra 'netmask' seguido de la máscara de red. A continuación estará la lista de parámetros para dicha sección encerrados entre llaves. Además de la dirección IP podremos asignar, entre otras, la dirección de la puerta de enlace, servidores DNS, servidor Netbios específico distinto del general....

También se pueden hacer reservas de IP para un determinado equipo en función de la MAC de su tarjeta de red. Para establecer una configuración de equipo es necesario crear una sección host.

Veamos el fichero de configuración que he usado, comentando en cada línea qué hace cada párametro o declaración:

authoritative; #para que actualice la ip del clientes en caso de error, prevalece el servidor

ddns-update-style ad-hoc; #si vamos a actualizar dinámicamente el servidor de Dns puede tomar los valores none, ad-hoc, interim

ddns-updates on;# para permitir las actualizaciones en el servidor de DNS

# option definitions common to all supported networks...

option domain-name "mczones.es";# nombre del dominio para los clientes

option domain-name-servers 192.168.2.3, 8.8.8.8; #Servidores de DNS para los clientes

option netbios-name-servers 192.168.2.3; #IP del servidor netbios

default-lease-time 600; #tiempo en segundos de la cesión de la ip

max-lease-time 7200;#máximo tiempo que durará la cesión

subnet 192.168.2.0 netmask 255.255.255.0 { #Red y máscara que se dará a los clientes

option routers 192.168.2.3; # dirección de la puerta de enlace que se les dará

option domain-name-servers 192.168.2.3, 8.8.8.8;#servidores DNS -pueden ser distintos de los por defecto

range 192.168.2.10 192.168.2.50; #rango de direcciones que se cederán ambas incluidas

}

#reserva de dirección para el cliente

host clienteUned {

hardware ethernet 08:00:27:05:dc:d4; #dirección MAC del equipo

fixed-address 192.168.2.49; #dirección IP que se le asignará.

}

Si tenemos más de una tarjeta de red y queremos que el servidor DHCP arranque sólo en una de ellas tendremos que modificar el fichero /etc/default/dhcp3-server (en la nueva versión está en /etc/default/isc-dhcp-server ) e incluir una línea:

INTERFACES=”eth0” #podríamos poner todas las que queremos que escuchen separadas por espacios

1.2 Otras comprobaciones de Configuración

Para asegurarnos de que se crean los enlaces simbólicos para que al arrancar el equipo se inicie el servicio de DHCP, podemos teclear # update-rc.d dhcpd3-server defaults. Si necesitamos parar el servicio: sudo /etc/init.d/dhcp3-server stop (con start o restart para iniciarlo o reiniciarlo respectivamente o force-reload para cargar las opciones que hemos cambiado en la configuración).

Finalmente, si queremos comprobar si hay algún problema con el fichero de configuración, teclearemos en consola sudo dhcpd3 -d. Si lo que queremos comprobar es que direcciones ha concedido el servidor, por cuánto tiempo y a quién, tan sólo hay que echarle un vistazo al fichero /var/lib/dhcp3/dhcpd.leases (igual que en los casos anteriores en la nueva versión está en /var/lib/dhcp/dhcpd.leases).

En la siguiente imagen se puede comprobar el resultado de ejecutar ifconfig en el cliente tras haberle sido cedida una dirección mediante dhcp. Asimismo se ve la captura del fichero dhcpd.leases dónde se puede comprobar la concesión de la misma.

Para reiniciar el servicio /etc/init.d/isc-dhcp-server restart 

en caso de error podéis emplear el comando dhcpd -d para comprobar errores

 

 

2.- Ficheros que intervienen en las configuraciones.

2.1 Ficheros de configuración de la red:

• Para reiniciar el servicio /etc/init.d/isc-dhcp-server restart (en las versiones antiguas /etc/init.d/dhcp3-server restart)

• 
  /etc/network/interfaces: Configuramos la ip, gateway, servidores dns,.... de nuestras tarjetas de red
• /etc/resolv.conf: incluimos los dominios de búsqueda y las direcciones de los servidores DNS
• /etc/hosts: se pueden relacionar nombres e ip de equipos
• /etc/nsswitch.conf: se establece la prioridad a la hora de realizar la búsquedas o identificaciones, puede ser, por ejemplo primero el fichero hosts y en caso de no encontrarlo buscarlo en el servidor DNS -especificados en el fichero resolv.conf.
• /etc/hostname: nombre del equipo
• /etc/init.d/networking: ejecutable que me permite stop, start, restart (parar, iniciar, reiniciar) el servicio de red con los valores cargados en los ficheros anteriores.

2.2 Ficheros de configuración del servidor DHCP:

• /etc/dhcp3/dhcpd.conf (o /etc/dhcp/dhcpd.conf): fichero de configuración del servicio
• /var/lib/dhcp3/dhcpd.leases (/var/lib/dhcp/dhcpd.leases): cada vez que el servidor DHCP concede una ip a un equipo se registra una entrada en este fichero indicando la ip, mac y fechas de cesión y duración de la concesión.
• /etc/default/dhcp3-server (/etc/default/isc-dhcp-server): podemos especificar que tarjeta/s escuchará el servidor y por lo tanto a que redes dará servicio en función de la interfaz de red a la que estén conectadas.

• /etc/init.d/dhcp3-server (/etc/init.d/isc-dhcp-server): ejecutable al que se le pasa el parámetro: stop, start, restart o force-reload para parar, iniciar, reiniciarlo o para cargar las opciones que hemos cambiado en la configuración respectivamente.

Esta entrada tiene su continuación en administración de servidores con Linux: