INSTALACION DEBIAN 7 fresh , SSH, y APACHE

A veces necesitamos una instalación limpia de un Sistema Operativo con el que se va a trabajar, implementando diferentes servicios, por ejemplo. A este tipo de instalaciones se les llama fresh, y en este caso utilizaremos un debían.

DESCARGA E INSTALACIÓN DE DEBIAN 7

—————————————————————————————————————-

Descargamos de http://cdimage.debian.org/debian-cd/7.3.0/amd64/iso-cd/debian-7.3.0-amd64-netinst.iso la imagen. 

Chequear la integridad de la iso.

partimos de una instalación fresh de 64 debían. todo poro defecto, particionado guiado, etc.

al instalar he tenido un pequeño problema con el mirror. lo he obviado.

continuar con la imagen de instalación.

Al aparecer la consola de las aplicaciones que se quieren instalar, utilizar la barra espaciadora para desmarcar las opciones que vengan por defecto.
En nuestro caso no se va a instalar en este momento ninguna, lo realizaremos de modo manual a medida que se vaya necesitando.

como es una máquina virtual, editar el archivo de configuración de red:

nano /etc/network/interfaces le cambio el allow hot-plug por auto

Tratándose de servidores, lo idóneo es configurar la ip estática, pero en este caso lo haremos más adelante, a fin de realizar todas las instalaciones. Si se quiere poner ip estática,

la tarjeta de red de la máquina virtual la tenemos en NAT por si acaso, ya que suele dar menos problemas de conectividad, de manera que comparte la ip del host, aunque luego la cambiaremos a bridget, para que tenga su propia ip.

esta configuración del vmware y la interface de red de la máquina virtual es una especie de “a prueba de fallos” que utilizamos para agilizar el proceso.

INSTALAR SSH

———————————————————————————————————————

para mayor comodidad, instalamos SSH secure shell, para poder acceder remotamente a la máquina virtual de forma segura, ya que no tenemos entorno gráfico. Esto nos permitirá copiar y pegar texto desde una terminal del host.

Para instalar secure shell

apt-get install openssh-server

para iniciar la conexión remota abrimos una terminal en el host y ejecutamos

ssh nombreusuario@ip de la máquina de debian 7

para saber la ip, en la máquina ejecutamos 

ifconfig

en nuestro caso ponemos root@ip

esto nos pedirá la contraseña del root y nos dará una huella para la conexión segura. Veremos el prompt de debían

root@debianez:~# 

verificar que hay conexión a internet

--------------sources

puede que dé error al reiniciar, o al intentar actualizar, o al instalar un programa.

https://wiki.debian.org/SourcesList#Example_sources.list_for_Debian_7_.22Wheezy.22

editar el archivo de sources del repositorio del gestor de paquetes

nano /etc/apt/sources.list
comentar la línea deb cdrom


sources generator beta. yo no lo he testado. pero te da la sources según la versión de la instalación.


http://debgen.simplylinux.ch

INSTALAR APACHE2--------------------------------------------------------------------------------------------------------------------------

antes de realizar cualquier instalación, conviene actualizar el SO:

apt-get update

apt-get upgrade

apt-get install apache2

En caso de error, 

revisar la conectividad #ifconfig -a (verificar que se tiene ip)

#ping a alguna web

si hay conectividad, editar el archivo /etc/apt/sources.list como se explica anteriormente

INSTALAR SERVIDOR DHCP DEBIAN

INSTALAR SERVIDOR DHCP DEBIAN

biblio:

https://wiki.debian.org/DHCP_Server

poner en vmware adaptador modo bridget (en todas las máquinas). Si tenemos problemas de conectividad probar modo NAT durante las instalaciones. Generalmente funciona la conexión a internet automática, porque comparte ip con el host.

arrancar como root

actualizar:

#apt-get update

#apt-get upgrade

#apt-get install isc-dhcp-server

para iniciar cualquier servicio PONER EN MODO ESTÁTICO EL ADAPTADOR DE RED

para ello editamos el fichero de configuración del adaptador de red:

#nano /etc/network/interfaces

allow-hotplug eth0----->auto eth0 

cambiar dhcp--->static

address 192.168.1.103

network  192.168.1.0

netmask 255.255.255.0

gateway 192.168.1.1

allow-hotplug: quiere decir que permite el cambio en caliente y suele dar problemas cuando se trata de máquinas virtuales

static: cambiando a modo estático haremos que tenga una ip fija

address: para saber la ip que tenemos, si queremos conservar la conexión a internet el parámetro lo obtenemos con

#ifconfig -a

editar fichero de interface por defecto del servicio dhcp

#nano /etc/default/isc-dhcp-server

INTERFACES “eth0”

poner un nombre de dominio a la máquina

#nano /etc/hostname

debianez.damocles.net

el fichero de configuración es

/etc/dhcp/dhcpd.conf

Es conveniente hacer una copia de seguridad del fichero antes de modificarlo

#cat /etc/dhcp/dhcpd.conf > /etc/dhcp/back01dhcpd.conf

configuración básica:

#nano /etc/dhcp/dhcpd.conf

añadir linea 

option domain-name  “damocles.net”;

me parece que esto vale para los nombres de los equipos dentro de la red interna LAN

poniendo sólo “equipo.” en vez de “equipo.damocles.net”

la siguiente linea es el dns. le pongo la propia ip, y dos de opendns (aunque sin conexión a internet, no resuelve nombres externos).

option domain-name-servers 192.168.1.103, 208.67.222.222, 208.67.220.220;

respetar las lineas que vienen por defecto sin comentar. Son el tiempo mínimo y máximo de vigencia de las IPs que se otorgan.

default-lease-time 600;

max-lease-time 7200;

como estamos en una red local, desmarco el # de

authoritative

en principio le voy a dar una configuración básica que dará ip automáticamente a los clientes. para ello especificarle la red y el rango donde pone

#this is a very basic subnet declaration

subnet 192.168.1.0 netmask 255.255.255.0 {

range 192.168.1.103 192.168.110;

option routers debianez.damocles.net;

}

--------le he metido en el rango la propia ip del servidor. esto en el servidor dhcp de windows  daba error si los ámbitos eran empezando por la propia ip. aqui funciona.

reiniciar el servicio

/etc/init.d/isc-dhcp-server restart

para comprobar errores desde el servidor

tail /var/log/syslog

resumen1

estados de adyacencia OSPF

Estados de OSPF

• Desactivado (DOWN). En el estado desactivado, el proceso OSPF no ha intercambiado información con ningún vecino. OSPF se encuentra a la espera de pasar al siguiente estado (Estado de Inicialización)

• Inicialización (INIT). Los routers (enrutadores) OSPF envían paquetes tipo 1, o paquetes Hello, a intervalos regulares con el fin de establecer una relación con los Routers vecinos. Cuando una interfaz recibe su primer paquete Hello, el router entra al estado de Inicialización. Esto significa que este sabe que existe un vecino a la espera de llevar la relación a la siguiente etapa. Los dos tipos de relaciones son Bidireccional y Adyacencia. Un router debe recibir un paquete Hello (Hola) desde un vecino antes de establecer algún tipo de relación.

• Bidireccional (TWO-WAY).(encaminador = enrutador). Empleando paquetes Hello, cada enrutador OSPF intenta establecer el estado de comunicación bidireccional (dos-vías) con cada enrutador vecino en la misma red IP. Entre otras cosas, el paquete Hello incluye una lista de los vecinos OSPF conocidos por el origen. Un enrutador ingresa al estado Bidireccional cuando se ve a sí mismo en un paquete Hello proveniente de un vecino. El estado Bidireccional es la relación más básica que vecinos OSPF pueden tener, pero la información de encaminamiento no es compartida entre estos. Para aprender los estados de enlace de otros enrutadores y eventualmente construir una tabla de enrutamiento, cada enrutador OSPF debe formar a lo menos una adyacencia. Una adyacencia es una relación avanzada entre enrutadores OSPF que involucra una serie de estados progresivos basados no solo en los paquetes Hello, sino también en el intercambio de otros 4 tipos de paquetes OSPF. Aquellos encaminadores intentando volverse adyacentes entre ellos intercambian información de encaminamiento incluso antes de que la adyacencia sea completamente establecida. El primer paso hacia la adyacencia es el estado ExStart.

• Inicio de Intercambio (EXSTART). Técnicamente, cuando un encaminador y su vecino entran al estado ExStart, su conversación es similar a aquella en el estado de Adyacencia. ExStart se establece empleando descripciones de base de datos tipo 2 (paquetes DBD), también conocidos como DDPs. Los dos encaminadores vecinos emplean paquetes Hello para negociar quien es el "maestro" y quien es el "esclavo" en su relación y emplean DBD para intercambiar bases de datos. Aquel encaminador con el mayor router ID "gana" y se convierte en el maestro. Cuando los vecinos establecen sus roles como maestro y esclavo entran al estado de Intercambio y comienzan a enviar información de encaminamiento.

• Intercambio (EXCHANGE). En el estado de intercambio, los encaminadores vecinos emplean paquetes DBD tipo 2 para enviarse entre ellos su información de estado de enlace. En otras palabras, los encaminadores se describen sus bases de datos de estado de enlace entre ellos. Los encaminadores comparan lo que han aprendido con lo que ya tenían en su base de datos de estado de enlace. Si alguno de los encaminadores recibe información acerca de un enlace que no se encuentra en su base de datos, este envía una solicitud de actualización completa a su vecino. Información completa de encaminamiento es intercambiada en el estado Cargando.

• Cargando (LOADING). Después de que las bases de datos han sido completamente descritas entre vecinos, estos pueden requerir información más completa empleando paquetes tipo 3, requerimientos de estado de enlace (LSR). Cuando un enrutador recibe un LSR este responde empleando un paquete de actualización de estado de enlace tipo 4 (LSU). Estos paquetes tipo 4 contienen las publicaciones de estado de enlace (LSA) que son el corazón de los protocolos de estado de enlace. Los LSU tipo 4 son confirmados empleando paquetes tipo 5 conocidos como confirmaciones de estado de enlace (LSAcks).

• Adyacencia completa (FULL). Cuando el estado de carga ha sido completada, los enrutadores se vuelven completamente adyacentes. Cada enrutador mantiene una lista de vecinos adyacentes, llamada base de datos de adyacencia.

areas OSPF

Como ya hemos comentado, el protocolo OSPF es un protocolo de enrutamiento interno IGR, que opera en grandes redes, y para ello divide el AS (sistema autónomo) en áreas de forma lógica.
Esto permite no saturar la red con la información de enrutamiento, ya que el envío de paquetes para confirmar los nodos activos y las actualizaciones se produce a intervalos regulares.

Un área OSPF es una unidad de enrutamiento. Cada área consta de un grupo de routers (lógico) que comparten la misma base de datos del estado de la topología de la red (Link State Database-estado de enlace).
Esta información, y los cambios en la topología de un área, no son conocidos por las demás áreas, de manera que el tráfico de datos de enrutamiento se divide.
Además las áreas no se comunican directamente unas con otras, si no que lo hacen a través de los rotures del área 0 o Backbone área, a la que obligatoriamente, tienen que ser colindantes.
Virtual link: es un tunel formado para conectar dos áreas a través de una intermedia. Los dos routers finales tienen que compartir un área común. Por lo menos uno de ellos tiene que estar en el área 0 (Backbone). No puede atravesar stubb áreas (áreas colindantes a la Backbone).

De esta forma, existen 3 formas de enrutamiento:

• enrutamiento intra-area. dentro del mismo área
• enrutamiento inter-área. distintas áreas del AS
• enrutamiento exterior. desde el AS al exterior o importadas a OSPF por otro protocolo o rutas estáticas

Como se ve en la figura, existen varios tipos de router, dependiendo del área en la que se encuentren, y su posición dentro de la misma.

• IR. (Internal Router). Son todas las interfaces que residen en el mismo área.
• BR. (Backbone Router). Son los routers que tienen una interface en el área 0 (Backbone).
• ABR. (Area Border Router). Son los routers que conectan dos o más áreas.
• ASBR. (Autonomous System Border Router). Son los routers que conectan el AS (Sistema Autónomo) con dominios de enrrutamiento adicionales, otro AS, por ejemplo. En la figura se encuentra en un área colindante a la Backbone, en el área 1, pero normalmente se suelen ubicar en el área 0.

Tipos de áreas:

• Standard area. Area OSPF por defecto
• Backbone area o area 0. Es el área dorsal, las demás son colindantes. Es la única que obligatoriamente tiene que existir. Conecta el resto de las áreas del AS mediante los ABR, que gestionan las rutas entre el área y la red (ínter-area).
• Stub area. Rutas de segmento. No recibe rutas externas (importadas a OSPF desde otro protocolo externo de enrutamiento) y tienen que compartir un ABR con la Backbone. Al no recibir rutas externas, se tienen que apoyar en rutas por defecto (predeterminadas-default) para enviar tráfico a rutas fuera del segmento: Los LSAs (Link State Announcement) tipo 5 son sustituidos por una ruta por defecto. Recordemos que los LSA (Link State Announcement) tipo 5 (External link) son generados por un ASBR (AS Boundary Router) e inundados a través del AS (Sistema Autónomo) para informar de una ruta externa a OSPF.
• Totally stubby area.Los LSAs (Link State Announcement) tipo 3, 4, y 5 son reemplazados en esta área por una ruta por defecto. Esto afecta además de a los paquetes que acabamos de ver, los LSA tipo 5 (External links),  a los LSA tipo 3 (Network Summary), que son un resumen generado por el ABR (Area Border Router) para informar sobre las áreas, y a los LSA tipo 4 (ASBR Summary), que son los inyectados por un ABR en la Backbone, para informar sobre la presencia de un ASBR en un área.
• NSSA.Not so stubby area. Son un tipo de stub area, que permite importar rutas externas de sistemas autónomos y enviarlas al backbone. Para ello contiene un ABR, que convierte LSAs tipo 7 (NNSA external link), que son los paquetes generados por el ASBR que se usan en el área para transportar información externa, en LSAs tipo 5 (external link) cuando dejan el área.

tipos de paquetes

Como hemos dicho existen 5 tipos de paquetes que utiliza el protocolo OSPF:

1. HELLO (Type1)
2. BDB o DDP (Database Description) (Type2) descripción de la base de datos              
3. LSR (Link State Request) Solicitud del estado de enlace
4. LSU (Link State Update) Actualización del estado de enlace
5. LSA (Link State ACK) Reconocimiento o confirmación del estado de enlace

hay 5 tipos de LSA:

• Tipo 1: LSA ruteador. describe el enlace y coste del router al área. Todos los enlaces de routers deben ser incluidos en un LSA para él. Inundación en un área en particular y no más. El router indica si es un ASBR(router de borde de sistema), ABR(router de borde de área) o un virtual link.OSPFv2 y v3) Router-LSA 
• Tipo 2: LSA red. describe todos los rotures unidos a la red. es generado por cada red de tránsito con broadcast o sin broadcast. Sólo el DR (Designated Router) origina este LSA. Inundado en el área y no más.(OSPFv2 y v3) Network-LSA 
• Tipo 3 y 4: LSA resumen. Describe el destino fuera del área pero aún dentro del AS (sistema autónomo). inundado a través de un sólo área. Originado por el ABR (router de área). sólo las rutas intra-área son anunciadas a la dorsal. El tipo 4 es información sobre el ASBR (router de sistema autónomo).(OSPFv2 y v3) Summary-LSA. En OSPFv2 se distinguen dos tipos: tipo 3, dirigidos a unrouter fronterizo de red; y tipo 4, dirigidos a una subred interna. En OSPFv3, los Summary-LSA tipo 3 son renombrados como Inter-Area-Prefix-LSA, y los tipo 4 pasan a denominarse Intra-Area-Prefix-LSA. 
• Tipo 5 y 7: LSA externo. El tipo 5 define rutas a enlaces externos al AS (Sistema Autónomo). Se envía la ruta por defecto (default) como externa. hay 2 tipos de LSA externo:E1: el que tiene en cuenta el costo total de la ruta E2: considera sólo el costo de la interfaz del destino externo.(OSPFv2 y v3) AS-External-LSA 
• Link LSA o LSA de enlace. no se transmite más allá del link de origen. (OSPFv3) 

Los paquetes comparten un encabezado común que especifica el tipo de paquete, la versión, la longitud, el ID del router source (el que envía el paquete), el ID del área, checksum, tipo de autenticación (instance id), un espacio reservado y luego están los datos del paquete.

paquete OSPF generico

version	type-tipo de mensaje	length-longitud del paquete
source ospf router-ID del router que envia el mensaje
identificador de area
checksum	tipo de autenticacion	reserved
autenticación
autenticación
datos

funcionamiento de OSPF

El fundamento principal en el cual se basa un protocolo de estado de enlace es en la existencia de un mapa de la red el cual es poseído por todos los nodos y que regularmente es actualizado.

Para llevar a cabo este propósito la red debe de ser capaz de entre otros objetivos de:

• Almacenar en cada nodo el mapa de la red.

• Ante cualquier cambio en la estructura de la red actuar rápidamente, con seguridad sin crear bucles y teniendo en cuenta posibles particiones o uniones de la red.

Protocolo HELLO: Descubrimiento de vecinos (otros routers OSPF conectados a su misma subred).
Intercambio de la base de datos topologica de OSPF: DB Link-state. 
Cada router mantiene una base de datos (DB Link-state) con la topologia completa de la red en cada router.
Estudiaremos dos tipos de tablas de esta base de datos que se encuentran en todos los routers OSPF:

Router Link State: Informacion de cada una de las interfaces de todos los routers OSPF.
Network Link State: Informacion de las subredes a las que estan conectados todos los routers OSPF.

El Algoritmo de Dijkstra se computa localmente en cada router para rellenar la tabla de encaminamiento partiendo de la base de datos de la topologıa de la red.


Si se producen cambios en la topologıa, se envıan mensajes del estado del enlace (con informaci ́on sobre los vecinos) mediante inundacion.

Mapa de Red Local

Los routers crean un mapa de la red local, mediante una tabla:

Fila: representa a un router de la red; y cualquier cambio que le ocurra a ese router será reflejado en este registro de la tabla a través de los registros de descripción.

Columna: representa los atributos de un router que son almacenados para cada nodo. Entre los principales atributos por nodo tenemos: 

• un identificador de interface
• número de enlace
• información acerca del estado del enlace, o sea, el destino y la distancia o métrica. 

Con esta información en todos los router de la red se pretende que cada router sea capaz de crear su propio mapa de la red y que sean todos iguales, lo cual implicará que no se produzcan bucles y que la creación de este mapa de red local se realiza en los router lo más rápido posible.  

Ejemplo

A --- 1 --- B --- 2 --- C --- 4 --- D --- 3 --- A

DE  A ENLACE DISTANCIA

A B 1 1

B C 2 1

C D 4 1

D A 3 1
B A 1 1

C B 2 1

D C 4 1

A D 3 1

Los routers envían periódicamente mensajes HELLO para que el resto de routers, tanto si pertenecen al mapa local como a un circuito virtual para  sepan que están activos. 

Para que un router sepa que sus mensajes se están escuchando los mensajes HELLO  incluyen una lista de todos los identificadores de los vecinos cuyos saludos ha oído el emisor.

Respuesta ante un cambio en la topología de la red

Un cambio en la topología de la red es detectado en primer lugar o por el nodo que causo el cambio o por los nodos afectados por el enlace que provoco el cambio. El protocolo o mecanismo de actualización la información por la red debe ser rápido y seguro, y estos son los objetivos del protocolo de inundación y de intercambio o sincronización empleado en OSPF.

Protocolo de Inundación: The flooding Protocol. Este protocolo consiste en el paso de mensajes entre nodos, partiendo el mensaje del nodo o nodos que han advertido el cambio, tal que cada nodo envía el mensaje recibido por todas sus interfaces menos por la que le llega siempre y cuando no haya recibido ese mensaje, para ello cada mensaje cuenta con un identificador de mensaje o contador de tiempo para constatar su validez.
Ejemplo
Supongamos que en la red anterior el enlace que va del nodo A a B, queda fuera de servicio tal que la distancia pasa a ser infinito.

El mensaje que A enviara a D será:

Desde A hacia B, enlace 1, distancia infinito, numero 2.

El mensaje que B enviara a C será:

Desde B hacia A, enlace 1, distancia infinito, numero 2.

La base de datos después del protocolo de flooding quedaría:

        DE  A ENLACE DISTANCIA    NUMERO 
A B 1 infinito               2
B     C 2 1                   1
C     D       4 1                   1
D A 3 1                   1
B A 1 infinito               2
C B 2 1                   1
D C        4 1                   1
A D 3 1                    1

Hay que tener que un cambio en un enlace de la red puede dejar aislados a unos nodos de la red, es decir, puede partir la red. Este cambio tal como está planteado el mapa local no es problema ya que aunque todos los nodos de la red inicial no tendrán el mismo mapa local este si que será idéntico para cada uno de los nodos en cada una de sus particiones.

Del mismo modo debemos considerar el caso contrario que ocurre cuando un cambio en la topología de la red provoca una unión de redes de nodos, ya que pueden surgir problemas como la existencia de enlaces modificados en una mapa local de un nodo de una subred que no esta modificado en el mapa local de la otra subred. El proceso mediante el cual se produce el chequeo del mapa local de las diferentes subredes para formar uno idéntico para todos los nodos  de la nueva red se denomina:

Protocolo de Chequeo de Mapas:Bringing Up Adjacencies
Se basa en la existencia de que existen identificadores de enlace y número de versiones, a partir de estos OSPF forma unos paquetes de descripción del mapa local e inicializa un proceso de sincronización entre un par de routers de la red  que tiene dos fases:

• Intercambio de paquetes de descripción del mapa local entre los nodos y en cada nodo creación de una lista de nodos especiales a tener en cuenta o bien porque su número de versión es mayor que la copia local o bien porque no existía en ese mapa local el identificador del enlace.
• Creación en cada nodo de paquetes con información acerca de esos nodos especiales que se envían a sus vecinos para que corroboren la información.

Tras terminar este intercambio de información, ambos routers conocen: 

Nodos que son obsoletos en su mapa local.
Nodos que no existían en su mapa local.

Los mensajes que se usan para solicitar todas las entradas que necesiten actualización son los LSR Link State Request o mensajes de petición de estado de enlace.
Los mensajes de respuesta son los LSU Link State Update.  

algoritmo de Dijkstra

El algoritmo puede ser descrito como:

N= conjunto de nodos en la red.

S = nodo origen.

M = conjunto de nodos incorporados en un instante t por el algoritmo.

D ij = el coste del enlace del nodo i al nodo j. Teniendo en cuenta que:

Dii = 0;

Dij = infinito si los dos nodos no están conectados directamente.

Dn = coste del camino de coste mínimo desde un nodo s hacia un nodo n que es conocido por el algoritmo.

El algoritmo tiene tres pasos; los pasos 2 y 3 son repetidos hasta que M = N, es decir, se han calculado todos los caminos posibles con todos los nodos de la red.

1.- Inicializar:

M = {s}

Dn = dsn para n<>s

2.- Encontrar el nodo vecino que no está en M tal que 

Dw = min DjDw = min Dj

                 Y j no pertenece a M.

     

      Añadir w a M.

3.- Actualizar el camino de coste mínimo :

Dn = min [ Dn, Dw + dwn] para todo n no perteneciente a M.

   

     Si el último termino es el mínimo, el camino desde s hasta n es ahora el camino desde s hasta w concatenado con el enlace desde w hasta n.