Author Archives: Manuel Jesús Begines González

  • 0

Actulización de Debian Jessie 8 a Debian Stretch 9

 

En la siguiente entrada vamos a ver como actualizar nuestra versión de Debian Jessie a Debian Stretch, el proceso es algo muy sencillo y se hace en pequeños pasos como vamos a ver ahora:

1– En primer lugar lo que debemos de hacer es conectarnos a nuestro servidor, una vez ahí como root debemos actualizar nuestros sistemas actual al máximo de que nuestros repositorios nos permita:

#apt update
#apt upgrade
#apt dist-upgrade

(como podéis comprobar desde Debian 8 podemos ejecutar el gestor de paquetes “apt” sin necesidad de escribir “apt-get“)

2– A continuación los que vamos a hacer es configurar nuestros repositorios para Debian Stretch, para ello nos vamos al fichero “/etc/apt/sources.list” y cambiamos en todos los lugares donde ponga “jessie” por “stretch” y guardamos los cambios para que quedes como a continuación:

deb http://ftp.es.debian.org/debian/ stretch main
deb-src http://ftp.es.debian.org/debian/ stretch main

deb http://security.debian.org/ stretch/updates main
deb-src http://security.debian.org/ stretch/updates main

# stretch-updates, previously known as 'volatile'
deb http://ftp.es.debian.org/debian/ stretch-updates main
deb-src http://ftp.es.debian.org/debian/ stretch-updates main

También todo lo que haya en la carpeta “/etc/apt/sources.list.d” cambiar en cada archivo la palabra “jessie” por la palabra “stretch“, en este caso no tenemos ningún repositorio aparte por lo que no hace falta hacer nada.

3– Una vez hecho esto volvemos a ejecutar los comando de que hemos visto en el punto uno para que todos los paquetes que tenemos instalado se actualicen ya a la nueva versión de Debian. Tened en cuenta que puede tardar un buen rato porque lo que no es mala idea que lo hagamos en un “screen” por si perdemos la conexión con el servidor la actualización no se haya visto afectada.

#apt update
#apt upgrade
#apt dist-upgrade

Cuando haya terminado  hacemos “reboot” y tendremos por fin nuestro Debian actualizad a la versión Stretch.

#cat /etc/issue
Debian GNU/Linux 9 \n \l

  • 5

OwnCloud en Alta Disponibilidad.

INSTALACION DE OWNCLOUD EN ALTA DISPONIBILIDAD

Lo que vamos a hacer a continuación es crear una alta disponibilidad para Owncloud. Owncloud es un sistema de almacenamiento y aplicaciones en línea.

nuestro objetivo es lograr un paridad y disponibilidad que sean transparentes para el usuario. Para empezar lo que hemos hecho es crear dos máquinas virtuales de unas 300 GB cada una para para tener un espacio de almacenamiento grande. Nuestras máquinas se encuentran en redes distintas con un direccionamiento IP distintos.

El primero paso que debemos de hacer es lograr que las máquinas tengan conexión entre ellas, para ello la solución que hemos dado es que ambas estén en la misma VPN.

Cluster de MariaDB

Una vez que tengamos las dos máquinas virtuales metidas en la VPN vamos a proceder a instalar MariaDB en los servidores que vamos a utilizar, las bases de datos se replicarán.

Ahora nos vamos al primero servidor y añadimos los siguientes repositorios:

#apt-get install software-properties-common
#apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 0xcbcb082a1bb943db
#add-apt-repository 'deb [arch=amd64,i386] http://tedeco.fi.upm.es/mirror/mariadb/repo/10.0/debian jessie main'
#apt update

A continuación instalamos Galera con el siguiente comando en todos los servidores que tengamos para la alta disponibilidad, en este caso 2:

#apt install rsync galera mariadb-galera-server

Una vez instalado procederemos a crear el cluster de Galera con MariaDB, para eso debemos de crear el fichero “galera.cnf” en “/etc/mysql/conf.d/” y añadimos las siguiente configuración en cada uno de los nodos:

[mysqld]
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
query_cache_size=0
query_cache_type=0
bind-address=0.0.0.0

# Galera Provider Configuration
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_cluster_name="avengers" 
wsrep_cluster_address="gcomm://10.100.0.10,10.100.0.20" 
wsrep_sst_method=rsync
wsrep_node_address="10.100.0.10"#

Donde pone “bind-addres” hemos puesto la dirección de la VPN, también está la opción de poner la dirección “0.0.0.0” para que permita todas las conexiones de la máquina.

Ahora vamos a proceder a para MySQL en todos los nodos ejecutando el siguiente comando:

# systemctl stop mysql

Una vez hecho esto debemos de tener especial cuidado en el siguiente paso, ya que debemos tener un archivo exactamente igual en todos los nodos, replicando el que más nos interese en todos los demás, que sea el cual vayamos a empezar el cluster. El fichero de configuración al que nos referimos en este caso es “/etc/mysql/debian.cnf”.

Hechos esto procedemos a arrancar el cluster. Para ellos empleamos el siguiente comando solo en un nodo:

# /etc/init.d/mysql start --wsrep_new_cluster  --wsrep-cluster-address="gcomm://10.100.0.10,10.100.0.20"

Después, en los otros nodos arrancamos mysql

# systemctl start mysql

Y en el primer nodo, debemos “apagar” mysql y volverlo a encender con systemd:

#/etc/init.d/mysql stop
#systemctl start mysql

Esta ultima parte de arrancar el cluster habrá que hacerla siempre que se caigan todos los nodos y queramos volver a arrancar el cluster. Es muy importante hacer el “–wsrep_new_cluster” solo en una máquina y solo cuando sea necesario porque no haya ningún otro nodo arrancado, ya que si no, tendríamos una bifurcación

GlusterFS

A continuación lo que vamos a hacer es isntalar GlusterFS, que no aportará la replicación de ficheros entre los servidores, de manera todo lo que se guarde en un servidor se replicará en los otros.

En primer lugar lo que debemos de hacer es instalar en este caso en los dos nodos que usamos el paquete “glusterfs-server”:

#apt install glusterfs-server

Una vez instalado, creamos la carpeta que se replicará entre los nodos:

#mkdir /gluster

Luego nos vamos a “/etc/glusterfs/glusterfsd.vol” y pegamos el siguiente contenido. Esto hay que hacerlo en ambos nodos:

volume posix
  type storage/posix
  option directory /gluster
end-volume

volume locks
  type features/posix-locks
  subvolumes posix
end-volume

volume brick
  type performance/io-threads
  option thread-count 8
  subvolumes locks
end-volume

volume server
  type protocol/server
  option transport-type tcp
  subvolumes brick
  option auth.addr.brick.allow *
end-volume

volume posix
  type storage/posix
  option directory /gluster
end-volume

volume locks
  type features/posix-locks
  subvolumes posix
end-volume

volume brick
  type performance/io-threads
  option thread-count 8
  subvolumes locks
end-volume

volume server
  type protocol/server
  option transport-type tcp
  subvolumes brick
  option auth.addr.brick.allow *
end-volume

Una vez hayamos creado el archivo lo que debemos de hacer es reiniciar el servicio:

#service glusterfs-server restart

Para el siguiente paso debemos crear el fichero “/etc/glusterfs/glusterfs.vol”:

volume node1         
  type protocol/client         
  option transport-­type tcp         
  option remote­host 10.100.0.10     
  option remote­-subvolume brick 
end­-volume

volume node2         
  type protocol/client         
  option transport-­type tcp         
  option remote­host 10.100.0.20     
  option remote­-subvolume brick 
end­-volume

volume replicated_storage
  type cluster/replicate
  subvolumes node1 node2
end­-volume

Luego por seguridad reiniciamos el servicio de Gluster como hemos hecho anteriormente.

Para probar que funciona y se conectan ejecutamos desde el nodo1 el siguiente comando con la dirección IP del nodo2:

# gluster peer probe 10.100.0.20
peer probe: success. 

Ahora crearemos el volumen que sera el que se replique. Debemos ejecutar el siguiente comando solo en una maquina y automáticamente se pondrá en la otra:

#gluster volume create owncloud replica 2 transport tcp 10.100.0.10:/gluster 10.100.0.20:/gluster force

Después arrancamos el volumen que hemos creado anteriormente, solo hace falta hacerlo en una máquina:

# gluster volume start owncloud
volume start: owncloud: success

Para tener exito tuvimos que parar el volumen y volverlo a arrancar

# gluster volume stop owncloud
# gluster volume start owncloud

Por último con Gluster lo que vamos a hacer es montar los volúmenes en ambas máquinas de la siguiente forma:

#mount localhost:owncloud /var/www/html/ -t glusterfs

Ya tenemos toda preparado y lo único que quedaría, seria instalar ownCloud de manera habitual en una máquina y automáticamente se hará en la otra.

Manuel Jesús Begines González y Gabriel Amador Garcia.


  • 4

Recuperar una Base de datos en modo Sospechoso

En esta entrada vamos a ver como recuperar una base de datos en modos Sospechoso. Cuando una Base de datos, está en modo SOSPECHOSO no podemos conectarnos a ella, provocando que la aplicación o sistema que dependa de la misma falle.

 

1- En primer lugar cuando nos encontramos con un escenario así, lo que debemos de hacer es poner a dicha base de datos en modo Emergencia, esto pondría a la base de datos en modo lectura para poder extraer los datos si quisiéramos. Para ello usaremos el siguiente comando:

Alter database nombre_bbdd set emergency

 

2- Luego para realizar tareas de mantenimiento ponemos la base de datos en Monousuario:

Alter database nombre_bbdd set single_user

 

3- Un vez hecho esto procedemos a la reparación de la base de datos, que sería con el comando que se muestra a continuación:

DBCC CHECKDB (nombre_bbdd, ‘REPAIR_ALLOW_DATA_LOSS’)

 

4- Por último si todo ha salido bien debemos devolver la base de datos a modo Multiusuario para que vuelva a estar en línea con el siguiente comando:

Alter table database nombre_bbdd set multi_user

 

Por fin tenemos la base de datos restaurada, ahora lo que debemos de hacer es reiniciar y el programa y lo tendremos funcionado de nuevo.

 


  • 2

Zen Load Balancer

zen_logo

 

La primera entrada del año tratará sobre Zen Load, un balanceador de carga de software libre basado en Debian, fácil de instalar y de comprender su funcionamiento, muy útil para servicios de alta disponibilidad.

 

Definición:

Zen load Balancer es un Balanceador de carga de licencia Open Source, es un software con una interfaz gráfica de configuración. Tiene una versión libre y una versión de pago que incluye el mantenimiento del balanceador.

 

Instalación:

Para empezar la isntalación podemos descargarnos la iso de desde su página oficial
http://www.zenloadbalancer.com/community/downloads/ y una vez la tengamos descargada instalamos como si fuera la instalación de un sistema operativo, zen load balancer esta integrado en una iso con debian squeeze.

Cuando se inicia la instalación nos sale como si estuviéramos instalando una máquina normal:

 

Captura de pantalla de 2016-01-11 19-06-57

Captura de pantalla de 2016-01-11 19-08-39

 

Continuamos con la instalación normal hasta que nos pida que le introduzcamos la IP de la máquina que vayamos a utilizar, normalmente en un distro de linux cualquiera intentaría coger por DHCP pero en este caso la introduciremos manualmente para que quede siempre con esa IP y facilite la configuración. Después esto la instalación es típica de una instalación de linux.

Captura de pantalla de 2016-01-11 19-10-23

 

Acceso al panel web.

Una vez terminada la instalación debemos de irnos al navegador web y poner la dirección IP que hemos puesto antes pero debemos de acceder mediante “https” y por el puerto “444”como por
ejemplo:

https://192.168.130.24:444/

El usuario y la contraseña por defecto son “admin” y “admin”.

 

Un a vez que accedemos por el navegador, vemos que nos aparecen unas gráficas que es información sobre es uso del balanceador, memoria, carga, trafico de red o las granjas de servidores.

Captura de pantalla de 2016-01-11 19-13-52

 

 

Configuración del Cluster.

Como tenemos dos servidores con el balanceador de carga por motivos de alta desponibilidad, debemos de configurar un cluster entre ellos para que trabajen como uno y si se cae uno de los dos pueda seguir trabajando y el sistema siga funcionando. Si nos fijamos vemos como en la parte superior nos dice que no tenemos configurado el cluster, esto es porque Zen Load Balancer recomienda de que haya mas de un balanceador por precaución. En primer lugar nos vamos al menú de configuración y hacemos clic en Settings > Cluster.

Captura de pantalla de 2016-01-11 19-16-29

 

Hacemos clic en “crear una nueva IP virtual”, a partir de que tengamos el cluster funcionando accederemos a esta IP y no a las físicas de las máquinas.

Captura de pantalla de 2016-01-11 19-17-39

 

Guardamos la configuración y volvemos a hacer clic en “settings > cluster” y seleccionamos la IP virtual que acabamos de crear.

Captura de pantalla de 2016-01-11 19-18-24

 

Pinchamos en “Save IP” e iniciamos la configuración del cluster y rellenamos el siguiente formulario.

Captura de pantalla de 2016-01-11 19-19-20

 

Cuando guardamos la configuración se nos desglosa automáticamente mas opciones que tenemos que rellenar, como la contraseña de ROOT del otro servidor y el tipo de cluster que lo podremos que ambos sean maestro.

Captura de pantalla de 2016-01-11 19-20-32

 

Luego volvemos a cargar y ya no nos aparecerá el mensaje que nos aparecía antes en la parte superior de la página.

Captura de pantalla de 2016-01-11 19-21-49

 

Para comprobar que funciona bién lo que debemos hacer es intentar en el panel de configuracion del Zen Load Balancer desde la IP virtual https://192.168.130.28:444/ .

 

 

 

Creación de las Granjas.

Ya hemos configurado el cluster entre los dos nodos de balanceadores, ahora lo que debemos de hacer es configurar las granjas de servidores a las cuales los balanceadores enviaran las peticiones. Estas granjas consisten en agrupar los servidores por los servicios que van a dar. En primer lugar lo que debemos de hacer es irnos al menú de arriba y hacer clic en “Manage” >
“Farms”:

Captura de pantalla de 2016-01-11 19-23-20

 

A continuación escribimos el nombre de la granja que vamos a crear y el perfil que va a tener dicha granja (http, udp, tcp, etc).

Captura de pantalla de 2016-01-11 19-24-05

 

Hacemos clic en “Save & continue” nos aparecerá nuevo campos de texto a rellenar en el cual especificamos la IP Virtual que hemos creado anteriormente y especificamos el puerto por el que irá el tráfico.

Captura de pantalla de 2016-01-11 19-25-18

 

Ahora nos aparecerá que la granja ha sido creada correctamente y nos muestra información sobre la misma.

Captura de pantalla de 2016-01-11 19-26-02

 

A continuación vamos a hacer clic en el botón de editar que se encuentra en acciones y nos aparecerá la configuración de la granja que podemos modificar como queramos. Nos vamos al final y hacemos clic en “Add service” después de poner el nombre del nuevo servicio:

Captura de pantalla de 2016-01-11 19-27-35

 

Nos aparecera un cuerpo nuevo en la página en el cual añadiremos los servidores (IP’s) que vamos
a usar. Como podemos ver no permite elegir el tipo de persistencia de sesión, que podrá ser por IP, cookies url, etc. En este caso escogeremos por cookie:

Captura de pantalla de 2016-01-11 19-28-25

 

Luego nos vamos para abajo y en acciones añadimos un nuevo servidor real que ya tengamos preparado para este fin, poniendo la IP y el puerto que va a usar, también podemos elegir el “timeout” y el “weight” pero lo dejaremos en blanco por el momento, luego hacemos clic en guardar y realizamos esto tantas veces como servidores queramos añadir:

Captura de pantalla de 2016-01-11 19-31-34

Captura de pantalla de 2016-01-11 19-32-10

 

Una vez agregado todos los servidores debemos de reiniciar la granja como se nos indica en en la parte superior de la pagina del balanceador:

Captura de pantalla de 2016-01-11 19-33-37

 

 

Prueba de funcionamiento.
Por ultimo lo que tenemos que hacer es irnos al nevegador y poner la IP virtual con la que trabaja el balanceador o el dominio si lo hemos metido en DNS

Captura de pantalla de 2016-01-11 19-35-33

 

Captura de pantalla de 2016-01-11 19-36-25

 

 

 


  • 3

Bloquear el acceso a Root

En internet hay gran cantidad de maquinas que se dedican a intentar acceder a los distintos servidores por fuerza bruta. Su ataque consiste en que con la certeza de que en todos los servidores linux tienen un usuario “root” por lo que hacen es intentar un loguin por fuerza bruta hasta averiguar la contraseña, en el momento que lo logran tiene un usuario con todos los privilegios sobre la máquina, con otros usuarios es mas complicado ya que el atacante debe conocer que usuarios están registrados en la máquina y si es un bot es aún mas complicado.

Para solucionar tenemos una opción muy sencilla que es bloquear el acceso a root por ssh, de esta manera nadie puede entrar por dicho usuario. Si lo usuarios necesitan acceder al usuario root deberán en primer lugar entrar con su usuario y luego una vez dentro entrar como sudo o su como vamos a ver a continuación:

#nano /etc/ssh/ssh_config

Dentro del fichero debemos de buscar lo siguiente:

PermitRootLogin yes

Ahora lo que hacemos es cambiar el “yes” por “no” y reiniciamos el servicio ssh.

#systemctl reload ssh

Y a continuación probamos a intentar acceder como root y comprobamos que verdaderamente no podemos hacerlo.


  • 0

Encaminamiento real de Internet.

En esta entrada veremos explicaremos como funciona el encaminamiento de internet, la manera en la que está organizado las redes en el mundo y lo que permite la comunicación entre dos puntos del planeta y porque es posible.

 

Puntos de Presencia (PoP)

Los puntos de presencia son los puntos de interconexión entre las instalaciones de comunicación y las instalaciones de distribución. Los puntos de presencia nos permiten establecer conexiones entre las distintas redes de ordenadores y servidores de internet. Los puntos de presencia mantienen conexiones como parecida a las telefónicas con la diferencia del tipo de tatos a convertir y a transferir en estos puntos. Con el tiempo estos puntos de presencia han permitido gestionar grandes cantidades de datos evolucionando a las comunicaciones de alta velocidad de las que disponemos hoy.

 
Un configuración Típica para un punto de presencia incluye routers, switches , servidores, conexiones punto a punto y dispositivos que pueden ser digitales y analógicos. Incluso las comunidades más pequeñas pueden llegar a tener docenas de puntos de presencia, lo cual permite a los usuarios disfrutar todos los servicios disponibles, como los servicios de telefonía hasta servicios inalámbricos internacionales de voz y datos. Con una central telefónica local, se consigue que los usuarios puedan realizar llamadas, con la
señal enrutada por la central local y saltando por enlaces de larga distancia a otras
localizaciones.

 
Gracias a este tipo de POP, la señal es capaz de llegar a su destino donde una señas de vuelta confirma que la conexión se ha realizado y permita la comunicación.

 

Puntos de Intercambio (IX)

Los gobiernos de todo el mundo le han dado una gran prioridad al desarrollo de su infraestructura nacional de conexión a internet y alcanzar niveles más altod de penetración de internet entre sus pobladores.

 
Un punto de intercambio es un componente de la infraestructura que permite a las redes locales que intercambien información de manera eficiente en un punto común dentro de un país, sin la necesidad de intercambiar el tráfico de internet local en el extranjero.

 
Los IX son relativamente similares a los centros de aeropuertos regionales en el mundo real. En los IX un mensaje de internet originado desde un usuario local y destinado a otro local, se enruta a un punto local dentro del país, en lugar de cambiarse en el extranjero.

 

 

Captura de pantalla de 2015-08-09 12:37:28

 

 

 

Política Transit entre ISPs.

En un mecanismo por el cual un Sistema de Autónomo permite el intercambio de informaciónentre la red que lo contrata y las redes a las que este sistema autónomo está conectado. Al contrario que el peering, la red que quiere conectarse al Sistema Autónomo tiene que contratar un servicio que le permite enviar y recibir una cantidad determinada de información, comúnmente medida en Mbps. Si el contratante excede los límites de la cantidad establecida, habrá un cargo adicional dependiendo de la cantidad de información excedida.

 

 

Política Peering entre ISPs.

La política Peering implica entre dos redes, con el propósito de intercambiar información entre usuarios de cada una de ellas. Este mecanismo implica un libre acuerdo entre las redes, es decir, ninguna de las redes paga a la otra por el intercambio de datos haciéndose cargo únicamente de los gastos de infraestructuras, cables, dispositivos, etc.
Peering Público: Se logra a trevés de una tecnología del acceso de la capa 2 del modelo TCP IP
generalmente llamada una tela compartida.

 

Peering Privado: Es la interconexión directa entre solamente dos redes, a través de medios de
la paca 1 o 2 que ofrece la capacidad dedicada que no es compartida por ninguna de otros partidos.

 

neutralidad de Internet.

A continuación está la definición de neutralidad de internet, la cuál pues estar siendo ignorada o no conservada en muchos países:

 

La ley de Neutralidad garantiza tu derecho de acceder libremente a cualquier tipo de contenido o servicio legal en Internet, sin que tu proveedor pueda negar dicho acceso o interferir en tus decisiones de navegación o consumo. Estos contenidos y servicios incluyen, entre otros: descargas de archivos (P2P), proveedores de vídeo en línea, juegos en línea, telefonía IP, tethering desde tu celular, etc., o cualquier contenido o servicio que puedas encontrar en la red.

 

 


  • 6

Encaminamiento Dinámico

En esta entrada vamos a ver como montar encaminamiento dinámico en linux, Windows Server y CISCO. El encaminamiento dinámico se encarga de elegir las rutas a seguir los paquetes de manera de que siempre cojan la más idónea y si cae en un enlace coge otra ruta alternativa.

Encaminamiento dinámico en Linux usando Quagga.

En el siguiente escenario vamos a ver como instalar en máquinas linux Quagga para que puedan realizar encaminamiento dinámico y usar protocolos de dicho encaminamiento como es RIP y OSPF.

Captura de pantalla de 2015-08-06 23:28:22

El escenario la haremos en linux en Netgui ya que en este emulador podremos contar con maquinas linux en su totalidad y de esta manera poder usar los router que son maquinas linux para configurar “Quagga” el primer paso es montar el escenario que tenemos, y a continuación le daremos direcciones IP a todas las interfaces que tenemos para que haya comunicación, pero solo debemos de poner puertas de enlace o rutas por defecto a las maquinas cliente, no a los routers. Para dar IP a las interfaces debemos de editar los ficheros de configuración que entonctramos en “/etc/network/interfaces”.

Captura de pantalla de 2015-08-06 23:33:09

Captura de pantalla de 2015-08-06 23:34:23

 

Quedando de esta manera la configuración de las redes:

Captura de pantalla de 2015-08-06 23:36:11

 

A continuación como ya tenemos Quagga instalado no hace falta que lo instalemos, pero en caso de que lo necesitemos el comando a ejecutar es simple “apt-get install quagga”. Ahora vamos a editar el fichero quagga en “/etc/quagga/daemons” y ponemos en “yes” los protocolos “zebra” y “rip” u “ospf” en este caso escogeremos OSPF pero el procedimiento a seguir seria el mismo.

Captura de pantalla de 2015-08-06 23:38:47

 

A continuación reiniciamos el servicio de Quagga con el comando: “/etc/init.d/quagga restart”

Captura de pantalla de 2015-08-06 23:40:00

 

El siguiente paso es crear los ficheros de configuración para cada servicio, para eso copiamos el ejemplo que tenemos en “/usr/share/doc/quagga/examples” y los pegamos en “/etc/quagga”, como vemos en el siguiente ejemplo:

r1~#cp /usr/share/doc/quagga/examples/zebra.conf.sample /etc/quagga/zebra.conf
r1~#cp /usr/share/doc/quagga/examples/ospfd.conf.sample /etc/quagga/ospfd.conf

Captura de pantalla de 2015-08-06 23:56:09

 

Una vez hecho esto debemos de cambiar los permisos del propietario para que no haya porblemas a la hora de que se ejecuten los servicios de quagga. Para eso debemos de ejecutar los siguentes comandos:

Captura de pantalla de 2015-08-06 23:57:34

 

Con la primera entrada cambiamos el propietario del grupo le aplicamos “*.conf” para que todos los ficheros acabados en “.conf” que se encuentran en la carpeta. Y en la segunda entrada aplicamos los permisos que tendrá todos los ficheros acabados en “.conf” que serán lectura y escritura para el /propietario, lectura para el grupo y nada para el resto de grupos(otros).

 

Luego reiniciamos el servicio de Quagga y ya podemos configurar OSPF, como si estuviéramos en
un router CISCO, los comandos a usar serán los mismos de CISCO.

Captura de pantalla de 2015-08-06 23:59:11

 

Para empezar a configurar el router para hacer OSPF ejecutamos “telnet localhost ospfd” nos pedirá una contraseña que será “zebra”, dicha contraseña se podrá cambiar en el fichero “/etc/quagga/ospfd.conf”.

Captura de pantalla de 2015-08-07 00:01:00

 

Cuando estemos configurando OSPF tenemos que introducir las direcciones de red de las redes a las que esta directamente conectado el router de tal manera que el R1 deberá ser configurado para las redes “192.168.4.0 /24” y “192.168.6.0 /24” que son las redes a las que va a estar a la escucha.

opfd> enable
ospfd# configure terminal
ospfd(config)# router ospf
ospfd(config-router)# network 192.168.4.0/24 area 0
ospfd(config-router)# network 192.168.1.0/24 area 0
ospfd(config-router)# network 192.168.6.0/24 area 0
ospfd(config-router)# exit
ospfd(config)# exit
ospfd# write

 

Si nuestra maquina no es un router Linux si no una maquina linux normal debemos de activar el bit
de enrutamiento en “/proc/sys/net/ipv4/ip_forward”

Captura de pantalla de 2015-08-07 00:02:37

 

Una vez que ya tenemos ping con todas la maquinas de la red y tenemos el ecaminamiento dinámico funcionando vamos a cortar uno de los cable de la red, para ver si el router elige una ruta alternativa y la red sigue funcionando.

Captura de pantalla de 2015-08-07 00:03:29

 

Hacemos ping desde PC3 a PC2 que sigue funcinado correctamente:

Captura de pantalla de 2015-08-07 00:04:17

 

Con el comadno “show ip ospf route” podemos ver las rutas que tiene el route guardadas.

Captura de pantalla de 2015-08-07 00:05:11

 

Encaminamiento dinámico RIPv2 en Windows 2008 Server.

A continuación lo que vamos a hacer es crear una red con Windows server 2008 funcionando como routers y con el protocolo RIPv2 en el simulador GNS3. En primer lugar lo que debemos de hacer es montar el escenario con los routers(maquinas windows server), las maquinas que harán de router no pueden ser copias unas de otras ya que crearan un conflicto y no habrá conexión entre ellas, deberán de ser instalaciones limpias e independientes unas de otras y las maquinas clientes utilizaremos VPCS para que no ser consuman tantos recursos de nuestro PC.

Captura de pantalla de 2015-08-07 12:55:25

A continuación lo que debemos de hacer es arrancar las maquinas server y configurarlas para que hagan enrutamiento.

Captura de pantalla de 2015-08-07 12:59:18

 

Luego nos vamos a Inicio > Herramientas Administrativas > Enrutamiento y acceso remoto.

Captura de pantalla de 2015-08-07 13:01:20

 

 

Nos vamos a configuración personalizada para activar el enrutamiento en LAN.

Captura de pantalla de 2015-08-07 13:03:12

Iniciamos el servicio.

Captura de pantalla de 2015-08-07 13:03:58

 

Para comprobar que funciona hacemos Ping a una de las interfaces del router que no están en la misma red que la maquina cliente.

Captura de pantalla de 2015-08-07 13:04:44

Luego hacemos lo mismo con los demás routers.

 

Una vez hayamos configurado todas la interfaces de red de todas las máquinas lo que debemos de
hacer es configurar RIP.
No vamos a “Acceso remoto y enrutamiento > IPV4 > General” hacemos clic en el botón
secundario en “Protocolo de enrutamiento nuevo”.

Captura de pantalla de 2015-08-07 13:05:29

 

Y nos saldrá una ventana donde nos dejará escoger el protocolo de enrutamiento que queramos en
este caso queremos RIPv2.

Captura de pantalla de 2015-08-07 13:06:39

 

Nos aparecerá en el panel de navegación de IPv4.

Captura de pantalla de 2015-08-07 13:07:14

 

Hacemos clic con el botón secundarion en RIP y pinchamos en nueva interfaz.

Captura de pantalla de 2015-08-07 13:07:46 Captura de pantalla de 2015-08-07 13:07:55

 

Cuando le demos a aceptar nos aparecerá una ventana con la configuración por defecto de RIP, si es
la que queremos le damos a aceptar y listo.

Captura de pantalla de 2015-08-07 13:08:50

 

Y hacemos los mismo con las demás interfaces que tenemos y de las cuales queremos hacer RIP.

Captura de pantalla de 2015-08-07 13:09:24

 

Una vez hayamos terminado de configurarlo todo nos vamos a una maquina cliente y hacemos ping a otra cliente que este en otra red, de esta manera comprobaremos que todo funciona perfectamente y el protocolo de encaminamiento RIP esta ejecutandose.

Captura de pantalla de 2015-08-07 13:10:11

 

 

Ahora para probar que las Rutas cambian cuando uno de los routers o interfaces se caen, vamos a eliminar un una interfaz para probar que coge otra ruta alternativa y sigue funcionando el encaminamiento. Para ello elegiremos el cable que va desde R1 a R2 para seguir probando con las maquinas con las que lo hicimos antes.

 

Captura de pantalla de 2015-08-07 13:11:04

 

 

 

Y hacemos ping desde PC3 a PC1y a la inversa.

Captura de pantalla de 2015-08-07 13:11:35

 

 

Captura de pantalla de 2015-08-07 13:18:36

Y vemos que efectivamente hacemos ping desde un host a otro funcionando perfectamente el encaminamiento dinámico en Windows 2008 Server.

 

 

Encaminamiento dinámico en CISCO con el protocolo OSPF.

 

A continuación lo que vamos a hacer es configurar OSPF para router cisco. Lo que debemos de hacer es arrancar el simulador y montar el escenario que tenemos, los routers que vamos a utilizar es el router 7200.

Captura de pantalla de 2015-08-07 13:21:57

 

El primer paso que debemos de realizar es la asignacion de IP a todas las interfaces que tenemos en el proyecto.

Captura de pantalla de 2015-08-07 13:22:47

 

Ahora procederemos a hacer la configuración de OSPF para CISCO, para ellos introduciremos los siguientes comandos:

Captura de pantalla de 2015-08-07 13:23:30

Debemos de poner todas las redes a las que esta directamente conectado el router y hacemos lo mismo con los demás routers.

 

Una vez configurado los routers hacemos ping de una maquina cliente a otra y vemos como funciona.

Captura de pantalla de 2015-08-07 13:24:41

 

Si hacemos como en casos anteriores del encaminamiento dinámico y quitamos uno de los cables que unen los routers veremos que el encaminamiento se sigue produciendo.

Captura de pantalla de 2015-08-07 13:25:23

 

Captura de pantalla de 2015-08-07 13:25:56

 

Ahora trataremos los costes de las rutas a tomar de los routers para ello daremos a una ruta un coste desorbitado y a otra un coste pequeño para que el router tome esa ruta siempre.

En la interfaz que queramos que tenga mas costes pondremos un coste de 9999.

Captura de pantalla de 2015-08-07 13:26:52

 

Y en la interfaz que queramos que tenga menos coste pondremos un coste de 1.

Captura de pantalla de 2015-08-07 13:27:36

 


  • 2

Comando básicos para la creación de máquinas virtuales en KVM

En esta entrada vamos a ver los comandos básicos para la creación de máquinas virtuales dentro de nuestro servidor, de esta manera podremos hacerlo por ssh y de manera remota sin recurrir a una interfaz gráfica.

Creación y configuración de máquinas

En primer lugar lo que debemos de hacer es crear un disco duro virtual para que podamos instalar el sistema operativo que queramos, para ello lo que hacemos es ejecutar el siguiente comando:

#qemu-img create -f qcow2 -o preallocation=metadata RUTA_A_DISCO_DURO_VIRTUAL ESPACIO

Un ejemplo real sería:

#qemu-img create -f qcow2 -o preallocation=metadata /mnt/discoduro 10G

El siguiente paso es crear la máquina virtual usando el disco virtual que hemos creado anteriormente, también debemos de especificar la imagen que vamos a usar para la instalación:

#virt-install -r RAM_EN_MB -n NOMBRE -f RUTA_A_DISCO_DURO_VIRTUAL --cdrom RUTA_A_ISO --vcpus=NUMERO_DE_CORES --graphics vnc,listen=0.0.0.0 --noautoconsole --network bridge:br0
#virt-install -r 1024 -n maquina1 -f /mnt/discoduro --cdrom /mnt/isos/debian8.iso --vcpus=2 --graphics vnc,listen=0.0.0.0 --noautoconsole --network bridge:br0

Si observamos el ultimo parámetro que le marcamos es la red en la cual hemos puesto que sea en modo puente por la interfaz “br0” que se creó para que las máquinas pudieran acceder a la misma red que el servidor.

Si queremos que la máquina tenga mas de un duro debemos debemos de ejecutar el comando anterior pero con un añadido:

#virt-install -r RAM_EN_MB -n NOMBRE -f RUTA_A_PRIMER_DISCO_DURO_VIRTUAL -f RUTA_A_SEGUNDO_DISCO_DURO_VIRTUAL --cdrom RUTA_A_ISO --vcpus=NUMERO_DE_CORES --graphics vnc,listen=0.0.0.0 --noautoconsole --network bridge:br0

Otra opción que tenemos es crear una máquina virtual a partir de un disco duro virtual que ya existente y que ha sudo usando e instalado un sistema operativo:

#virt-install -r RAM_EN_MB -n NOMBRE -f RUTA_A_DISCO_DURO_VIRTUAL --vcpus=NUMERO_DE_CORES --graphics vnc,listen=0.0.0.0 --noautoconsole --network bridge:br0

Opciones de KVM.

Ahora vamos a ver los comando necesarios para poder gestionar KVM y las máquinas de creemos.

En primer lugar si lo que queremos es arrancar una máquina virtual debemos de ejecutar el siguiente comando:

#virsh start nombre

Para apagarla sería de la siguiente manera:

#virsh destroy nombre

No nos confundamos, aunque ponga “destroy” no significa que la destruya como hemos dicho lo que hace es apagarla.

Ahora si vamos a ver el comando para eliminar o destruir la máquina que sería de la siguinete forma:

#virsh undefine nombre

Cuando creamos mas de una máquina se le asignan puertos para poder acceder por vnc de manera que las máquinas están separadas y definidas perfectamente. Para ver los puertos que tiene cada máquina podemos usar uno de los dos comandos que tenemos a continucación:

#virsh domdisplay nombre
#virsh vncdisplay nombre

Si lo que queremos es hacer un listado de las distintas redes que tenemos en KVM podemos hacer con un comando muy sencillo que es:

#virsh net-list

Ahora vamos a ver el comando con el cual nos muestra un listado de todas las máquinas que tenemos creadas y si están encendidas o apagadas:

#virsh list --all

Acciones fuera de KVM.

Si lo que queremos es ver las direcciones IP que hay concedidas en nuestra red local lo que debemos de hacer es usar el comando nmap de la siguiente manera:

#nmap -sP 192.168.1.1-254

También es una buena opción para cuando estemos desarrollando y probando en una máquina virtual el montarnos la carpeta donde se este ejecutando el código de la aplicación en nuestra máquina real. Esto lo podemos hacer con “sshfs” de la siguiente manera:

#sudo sshfs -o allow_other user@address:/directorio/ /carpeta_destino_de_montaje/
#sudo sshfs -o allow_other usuario@192.168.100.11:/home/usuario/ /mnt/MaquinaVirtual/

Si estamos fuera de nuestro red, podemos realizar un tunel mediante los siguientes comandos:

ssh -f userB@systemB -L 2222:systemC:22 -N
sshfs -o allow_other -p 2222 userC@localhost:/remote/path/ /mnt/localpath/

Para quitar el enlace usamos:

 
umount /mnt/localpath/

Y para eliminar el tunel:

ps ax | grep "ssh_command" | awk '{print $1}' | \
	xargs -i kill {} 2>/dev/null

  • 0

Squid

En esta entrada vamos a configurar un servidor Squid, un proxy para web con caché, los clientes realizan la petición sobre el servidor proxy y si este no tiene guardada la pagina en su caché es él quién realiza la petición, pero si ya la tiene guardada en caché devuelve al usuario la página y de esta manera agiliza el proceso. También puede hacer que los usuarios no puedan acceder a ciertas páginas que indiquemos en el servidor.

1. Configuración del servidor:

En primer lugar lo que debemos de hacer es instalar squid para ello ejecutamos el siguiente
comando:

root@squid:/home/debian# apt­get install squid3

Una vez instalado lo que debemos de hacer es irnos al fichero “/etc/squid/squid.conf” y le damos el
siguiente valor a la línea “http_port”:

# Squid normally listens to port 3128
http_port 3128

Luego descomentamos la siguiente línea y le damos el valos de nuestro rango de red:

acl localnet src 172.22.0.0/16
acl localnet src 172.19.0.0/16

Y por ultimo descomentamos las líneas:

http_access allow localnet
http_access allow localhost

2. Configuración del proxy

A continuación lo que vamos a hacer es tener dos tipos de usuarios, profesores y alumnos, los
profesores y los usuarios se identificarán por “profesor” cuya contraseña será “profe” y alumnos
cuya contraseña será “alumno” respectivamente.

Empezamos por definir a profesores y a alumnos, para ello vamos a elegir el módulo “NCSA”
instalando el siguiente paquete:

root@squid:/home/debian# apt­get install apache2­utils

Una vez hecho esto lo que debemos de hacer es editar el fichero “/etc/squid3squid.conf” y
descomentamos las siguientes líneas, en la primera especificamos donde se encontrará:

auth_param basic program /usr/lib/squid3/ncsa_auth 
/etc/squid3/passwd
auth_param basic children 5
auth_param basic realm Squid proxy­caching web server
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off

Ahora lo que debemos de hacer es crear los ficheros donde estarán las contraseñas de los usuarios
en la ruta que hemos especificado anteriormente con el comando “htpasswd”:

root@squid:/etc/squid3/passwd# htpasswd ­c /etc/squid3/usuarios 
alumno
New password: 
Re­type new password: 
Adding password for user alumno
root@squid:/etc/squid3/passwd# htpasswd ­c /etc/squid3/usuarios 
profesor
New password: 
Re­type new password: 
Adding password for user profesor
root@squid:/etc/squid3/passwd# 

Si miramos dentro del fichero veremos que al usuario con su contraseña encriptada.

profesor:$apr1$0oYR0y8k$AMhAodqLlf/5Olmq3vpb2/
alumno:$apr1$4mykyuEv$/JdI3QFqCfZbtVQkWaVAu.

Luego cambiamos los permisos y el propietario del la carpeta:

root@squid:/home/debian# chown root:proxy /etc/squid3/usuarios 
root@squid:/home/debian# chmod 640 /etc/squid3/usuarios
root@squid:/home/debian# 

Luego editamos el fichero “/etc/squid3/squid.conf” y descomentamos ademas de editar la siquiente
línea marcando donde irá el fichero de las contraseñas:

auth_param basic program /usr/lib/squid3/ncsa_auth 
/etc/squid3/usuarios

Luego descomentamos también las siguientes líneas:

auth_param basic children 5
auth_param basic realm Squid proxy­caching web server
auth_param basic credentialsttl 2 hours

Una vez hecho esto el siguiente paso es añadir la acl siquiente:

acl usuarios proxy_auth REQUIRED

volvemos al fichero y editamos la siguiente línea:

http_access allow usuarios localnet

Y reinicamos el servicio de squid:

root@squid:/etc/squid3# service squid3 restart
[ ok ] Restarting Squid HTTP Proxy 3.x: squid3[....]  
Waiting.....................done.
. ok 
root@squid:/etc/squid3#

Luego nos vamos al navegador e intentamos acceder a google, y comprobamos que nos pide
usuarios y contraseña:

Captura de pantalla de 2015-06-25 23-40-52

Captura de pantalla de 2015-06-25 23-41-51

3. Limitaciones de los usuarios.

A continuación vamos a limitar los siguientes puntos.

Para los profesores y alumnos:
• No se pueden bajar ficheros que se puedan instalar (exe,msi,rar,zip,bin,iso).
• No tienen acceso a internet los fines de semana.
Para los alumnos:
• No pueden ver contenido multimedia.
• Sólo tienen conexión de 8:00 h. a 14:00 h.

Para definir a los alumnos y los profesores establecemos los siguiente:

acl alumno proxy_auth alumno
acl profesor proxy_auth profesor

Ahora configuraremos para que no puedan entrar en el fin de semana:

acl findesemana time AS 00:00­23:59 
http_access allow alumno !findesemana localnet
http_access allow profesor !findesemana localnet

Debemos de tener en cuenta que las líneas deben ir en su sitio, no juntas.

Ahora tenemos que definir nuevas normas para los alumnos, no podrán descargar ficheros
multimedia y solo tiene acceso a internet desde las 8 a las 14 horas:

acl horario_alumno time MTWHF 8:00­14:00
http_access deny horario_alumno alumno

La siguiente regla que vamos a poner es que no se puedan descargar fichero multimedia:

acl multimedia rep_mime_type ­i ^video/xmatroska$ ^video/mpeg$ 
^video/x­msvideo$ ^audio/mpeg$ ^audio/xms­wma$ ^audio/x­ms­wma$
http_reply_access deny multimedia alumnos

4. Control de dominios y de url’s.

Ahora lo que vamos a hacer es configurar que squid deniegue el acceso a ciertos dominios y url’s,
squid leerá los dominio desde un fichero de texto plano que le indiquemos:

acl url_invalida dstdomain "/etc/squid3/url_invalida.acl"
acl dominio_invalido dstdomain "/etc/squid3/dominio_invalido.acl"
http_access deny url_invalida 
http_access deny dominio_invalido

5. Configuración PAC

En primer lugar lo que debemos de hacer es crear nuestro virtualhost pero antes creamos el
siguiente fichero “nano /var/www/wpad/wpad.dat”:

function FindProxyForURL(url, host)
  {
    return "PROXY 172.22.200.216:3128";
  }

Luego nos vamos a “/etc/apache2/sites-availables/” y creamos “wpad” con la siguiente estructura:


        ServerAdmin webmaster@localhost
        ServerName wpad.manu.gonzalonazareno.org
        DocumentRoot /var/www/wpad
        
                Options FollowSymLinks
                AllowOverride All
        
        
                Options Indexes +FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                allow from all
        

Luego nos vamos al servidro DNS y añadomos las siguientes líneas al fichero
“/var/cache/bind/db.manu.gonzalonazareno.org”:

squid   IN      A       172.22.200.216
wpad    IN      CNAME   squid

Y reiniciamos el servicio:

root@targaryen:/home/debian# service bind9 restart
[....] Stopping domain name service...: bind9waiting for pid 2139 
to die
. ok 
[ ok ] Starting domain name service...: bind9.
root@targaryen:/home/debian#

Luego nos vamos al cliente y cambiamos por la dirección del servidor DNS que en este caso sería
172.22.200.53

A continuación nos vamos al cliente y en la configuración ponemos la URL del squid:

Captura de pantalla de 2015-06-25 23-50-39

6. Monitorización del tráfico.

Por último vamos a instalar SARG que sirve para monitorizar el tráfico. Para instalarla ejecutamos
el siguiente comando:

root@squid:/etc/apache2/sites­available# apt­get install sarg

El siguiente paso que debemos de hacer es editar el fichero “/etc/sarg/sarg.conf” para que lea los
ficheros de squid3 para poder generar los datos:

access_log /var/log/squid3/access.log
output_dir /var/www/sarg
date_format e

* Si la carpeta “/var/www/sarg” no existe la creamos y le cambiamos el propietario a “www-data:www-data”

Luego reiniciamos apache y ejecutamos el comando:

root@squid:/etc/apache2/sites­available# sarg

Luego nos vamos a la dirección “http://squid.manu.gonzalonazareno.org/sarg/” y vemos que nos
sales las información del sitio.

Captura de pantalla de 2015-06-25 23-53-53

Captura de pantalla de 2015-06-25 23-54-52


  • 0

Servicio Web de Alta Disponibilidad

En esta entrada dejo un enlace de descarga con la memoria sobre mi proyecto de Trabajo de fin de ciclo, el cuál consiste en un servicio web de alta disponibilidad para ownCloud, también es aplicable para otros CMS o servicios web, pero este se ha orientado al almacenamiento de datos de los usuarios. En definitiva lo que hacemos en este proyecto es asegurarnos de que el servicio siempre este activo y no haya ninguna perdida para los usuarios.

Espero que os sirva.

Memoria completa