Si queremos instalar GNS3 0.8.2 en Ubuntu 11.10 (merece la pena) no podemos hacerlo desde repositorios ni desde el centro de software de Ubuntu ya que la versión oficial disponible en repositorios es la versión GNS3 0.7.4-1 (que instala conjuntamente Dynamips 0.2.7-0.2.8RC2-5ubuntu1 por dependencias). Por lo que la solución a esta tarea pasa por hacer la descarga de dependencias, el parcheo de qemu y la compilación manual de la versión 0.8.2 de GNS3.


Este es el paso a paso:

1. Primero instalamos las dependencias:
   
   

   hnoguera@hnoguera-desktop:~$ sudo apt-get install python
   hnoguera@hnoguera-desktop:~$ sudo apt-get install qt4-dev-tools
   hnoguera@hnoguera-desktop:~$ sudo apt-get install pyqt4-dev-tools
   hnoguera@hnoguera-desktop:~$ sudo apt-get install libncurses5-dev zlib1g-dev libsdl-dev libpcap-dev
   

   
   
   

2. Creamos árbol de directorios que usará GNS3 para almacenamiento de proyectos, de imágenes IOS, de caché de temporales, etc y cambiamos permisos:
   

   hnoguera@hnoguera-desktop:~$ cd /opt/
   hnoguera@hnoguera-desktop:/opt$ sudo mkdir GNS3
   hnoguera@hnoguera-desktop:/opt$ cd GNS3/
   hnoguera@hnoguera-desktop:/opt/GNS3$ sudo mkdir Dynamips
   hnoguera@hnoguera-desktop:/opt/GNS3$ sudo mkdir IOS
   hnoguera@hnoguera-desktop:/opt/GNS3$ sudo mkdir Project
   hnoguera@hnoguera-desktop:/opt/GNS3$ sudo mkdir Cache
   hnoguera@hnoguera-desktop:/opt/GNS3$ sudo mkdir tmp
   hnoguera@hnoguera-desktop:/opt/GNS3$ sudo mkdir qemu
   hnoguera@hnoguera-desktop:/opt/GNS3$ cd ../
   hnoguera@hnoguera-desktop:/opt$ sudo chmod -R 755 GNS3/
   

   
   
   

3. Descargamos la última versión de GNS3 disponible, en este caso la 0.8.2:
   

   hnoguera@hnoguera-desktop:/opt$ cd GNS3/
   hnoguera@hnoguera-desktop:/opt/GNS3$ wget http://sourceforge.net/projects/gns-3/files/GNS3/0.8.2/GNS3-0.8.2-src.zip

   
   
   

4. Descargamos el binario de la última versión de Dynamips disponible, en este caso la 0.2.8-RC2 y lo hacemos ejecutable:
   Versión de 32 bits:
   
   

   hnoguera@hnoguera-desktop:/opt/GNS3$ cd Dynamips/
   hnoguera@hnoguera-desktop:/opt/GNS3/Dynamips$ wget http://www.ipflow.utc.fr/dynamips/dynamips-0.2.8-RC2-x86.bin
   hnoguera@hnoguera-desktop:/opt/GNS3/Dynamips$ sudo chmod +x ./dynamips-0.2.8-RC2-x86.bin

   
   Versión de 64 bits:
   

   hnoguera@hnoguera-desktop:/opt/GNS3$ cd Dynamips/
   hnoguera@hnoguera-desktop:/opt/GNS3/Dynamips$ wget http://www.ipflow.utc.fr/dynamips/dynamips-0.2.8-RC2-amd64.bin
   hnoguera@hnoguera-desktop:/opt/GNS3/Dynamips$ sudo chmod +x ./dynamips-0.2.8-RC2-amd64.bin

   
   
   

5. Descargamos la versión 0.11 de qemu, la parcheamos y la instalamos (por ahora la versión 0.14 de qemu no funciona con GNS3 0.8.2, devuelve error “You’re running an old AND unpatched version of qemu, wich won’t work”):
   

   hnoguera@hnoguera-desktop:/opt/GNS3/Dynamips$ cd /opt/GNS3/qemu/
   hnoguera@hnoguera-desktop:/opt/GNS3/qemu$ wget http://download.savannah.gnu.org/releases/qemu/qemu-0.11.0.tar.gz
   hnoguera@hnoguera-desktop:/opt/GNS3/qemu$ tar -zxvf qemu-0.11.0.tar.gz
   hnoguera@hnoguera-desktop:/opt/GNS3/qemu$ cd qemu-0.11.0/
   hnoguera@hnoguera-desktop:/opt/GNS3/qemu/qemu-0.11.0$ wget http://sourceforge.net/projects/gns-3/files/Qemu/qemu-0.11.0-olive.patch/download
   hnoguera@hnoguera-desktop:/opt/GNS3/qemu/qemu-0.11.0$ sudo mv download qemu-0.11.0-olive.patch
   hnoguera@hnoguera-desktop:/opt/GNS3/qemu/qemu-0.11.0$ patch -p1 -i qemu-0.11.0-olive.patch
   hnoguera@hnoguera-desktop:/opt/GNS3/qemu/qemu-0.11.0$ ./configure --target-list=i386-softmmu
   hnoguera@hnoguera-desktop:/opt/GNS3/qemu/qemu-0.11.0$ sudo make
   hnoguera@hnoguera-desktop:/opt/GNS3/qemu/qemu-0.11.0$ sudo make install
   

   
   
   

6. Descomprimimos e iniciamos GNS3:
   

   hnoguera@hnoguera-desktop:/opt/GNS3/qemu/qemu-0.14.1$ cd ../../
   hnoguera@hnoguera-desktop:/opt/GNS3$ unzip GNS3-0.8.2-src.zip
   hnoguera@hnoguera-desktop:/opt/GNS3$ cd GNS3-0.8.2-src/
   hnoguera@hnoguera-desktop:/opt/GNS3/GNS3-0.8.2-src$ sudo chmod +x ./gns3
   hnoguera@hnoguera-desktop:/opt/GNS3/GNS3-0.8.2-src$ sudo chmod +x ./qemuwrapper/qemuwrapper.py
   hnoguera@hnoguera-desktop:/opt/GNS3/GNS3-0.8.2-src$ ./gns3
   

   
   

7. Configuramos GNS3:
   

   
   Clic en el paso 1 del Wizard
   
   
   
   
   
   
   
   
   Cambiamos la ruta del ejecutable de Dynamips a /opt/GNS3/Dynamips/dynamips-0.2.8-RC2-x86.bin, el directorio de trabajo a /opt/GNS3/tmp y comprobamos su correcto funcionamiento con “Test Settings”:
   
   
   
   
   
   
   
   
   
   En el apartado “General” bajo “Paths” especificamos las rutas /opt/GNS3/Project para “Project directory” y /opt/GNS3/IOS para “OS image”:
   
   
   
   
   
   
   
   
   
   En la pestaña “Terminal Settings” cambiamos el comando que aparece en “Terminal command” a:
   
   

   gnome-terminal -t %d -e 'telnet %h %p' >/dev/null 2>&1 &

   
   
   
   
   
   
   
   
   
   En el apartado “Capture” cambiamos el “Working directory for capture files” a /opt/GNS3/Project:
   
   
   
   
   
   
   
   
   
   En el apartado “Qemu” cambiamos los “Paths” según corresponda con el destino de los binarios de qemu:

   
   
   

   hnoguera@hnoguera-desktop:/opt/GNS3/qemu/qemu-0.11.0$ which qemu
   /usr/local/bin/qemu
   hnoguera@hnoguera-desktop:/opt/GNS3/qemu/qemu-0.11.0$ which qemu-img
   /usr/local/bin/qemu-img

   
   
   Cambiamos “Path to qemu” a /usr/local/bin/qemu, “Path to qemu-img” a /usr/local/bin/qemu-img y testeamos la configuración:
   
   
   
   
   
   
   
   
   

   Aplicamos cambios, cargamos alguna imagen ISO y a funcionar.

Fuentes:

• http://forum.gns3.net/topic4690.html
• http://forum.gns3.net/topic4692-20.html
• http://www.kartook.com/2012/04/how-to-install-and-configure-gns3-v0-8-2-ubuntu-11-10-x64/

yo@midebian:$ wget -i urls-descargas

También tenemos la posibilidad de que wget consulte cada uno de los ficheros a descargar en el destino y en el origen y los descargue solo si no existe o si el remoto es mas actual que el fichero almacenado en disco:

yo@midebian:$ wget -Ni urls-descargas

yo@midebian:$ sed -n -e '1x;1!H;${x;s-\n- -gp}' fichero_fuente > fichero_destino

o

yo@midebian:$ sed -n -e '1x;1!H;${x;s-\n- -gp}' fichero > foo
yo@midebian:$ mv foo > fichero

Este recurso lo encontré googleando hace un tiempo, pero no recuerdo la fuente…

Vyatta lleva tiempo demostrando su potencia y amplia funcionalidad, su competitividad, su capacidad de remplazar a otros equipos de red mucho mas caros y cerrados, su innovación en administración de redes y gestión de seguridad de entornos virtuales.
Quizás ahora es el momento de hacer todo esto bonito, de sacarle mas partido, mediante un interfaz grafico (GUI) mucho mas potente y con el que poder ampliar y encandilar mercado.

Hablamos por ahora únicamente de la versión VSE 6.4 (Vyatta Subscription Edition 6.4), nuestra querida versión Vyatta Core 6.4 estará disponible para descarga en unas semanas. Como sabéis el GUI ha sido eliminado de la versión Vyatta Core desde que, en Julio del pasado 2011, saliera a la luz la versión Vyatta Core 6.3.

Entonces, ¿cuales son las novedades introducidas en la versión Vyatta Network OS 6.4?

Tal y como hemos adelantado en los párrafos anteriores y como nos cuenta Lisa Pavey, Vicepresidenta de ingeniería de producto de Vyatta en esta entrada del blog de Vyatta, uno de los cambios de mas peso en la nueva versión liberada de Vyatta es la ampliación en su GUI o interfaz gráfica que ahora cuenta con dos pestañas nuevas – Dashboard y Statistics.







El dashboard permite identificar rápidamente problemas y anomalías, mientras que la pantalla statistics muestra gráficos estadísticos que se actualizan constantemente.
Ambas características permiten al usuario el examen profundo de datos y la exploración de todo el subsistema en detalle.












En resumen, el nuevo GUI facilita la búsqueda y actualización de datos de configuración y operación, ya sea para administración de temas de routing, seguridad, servicios o administración de red, con un par de clics.
Con lo que nos gusta en openredes el CLI…

El resto de mejoras son significativas para equipos Vyatta desplegados tanto en entornos físicos como virtualizados:

• Mejoras para la actualización de equipos físicos (solo disponible en VSE6.4):
  
  Ahora Vyatta VSE provee de un solo comando para actualización del sistema – “upgrade system image“. Este comando se añade además del existente “add system image“, el cual requiere un conocimiento por parte del usuario de la URL en la que está disponible la imagen ISO de Vyatta desde la que actualizar, así como el usuario y password de la suscripción con Vyatta (el nuevo comando conectará de forma automática siempre que estas credenciales ya estén almacenadas en la configuración actual de la máquina).
  El nuevo comando “upgrade system image” solo aplicará para actualizaciones futuras desde la versión 6.4 a una versión superior o mas actual. Una vez lanzado el comando, el sistema se conecta automáticamente al repositorio de Vyatta para buscar e instalar la última imagen ISO disponible para el entorno actual.
  
  

• Mejoras en la actualización de equipos virtualizados (solo disponible en VSE6.4):
  
  Vyatta ha mejorado la eficiencia del proceso de actualización de los despliegues de máquinas Vyatta en entornos virtualizados. Estas mejoras incluyen:
  

  • Se provee al usuario con la opción de realizar una actualización de la imagen Vyatta del sistema sin la necesidad de reinstalar completamente cada vez que decida actualizar. Si el usuario desea usar una plantilla virtual mas nueva entonces se mantiene la necesidad de reinstalar.
    

  • Ahora la actualización del sistema ahora puede hacerse con único comando.
    

  • El comando “upgrade system image” conecta automáticamente con el repositorio de Vyatta y busca e instala la última imagen disponible para el hipervisor en uso.
    

  • Dichas actualizaciones se refieren y son aplicables solo para actualizaciones futuras mediante las que actualizar una imagen 6.4 en uso a una versión nueva.
    

  • Lista de hipervisores soportados
    

    • ESX4.1

    • ESX5.0

    • XenServer 5.6

    • XenServer 6.0

    • RHEL 6.1

    • Amazon VPC Cloud via Vyatta AMI
      
      

• Soporte para VMware vSphere 5 (solo disponible en VSE6.4):
  
  Vyatta Network OS ahora incluye soporte para la última versión del hipervisor de VMware.
  Se han incluido en Vyatta Network OS plantillas pre-empaquetadas para usar con VMware vSphere 5.
  Soporte Multi-Queue disponible para driver VMXNET3, este soporte también estará disponible para la versión VC6.4 (también incluirán las open-vmtools) con la diferencia de que no se proveerá en VC6.4 de una plantilla exclusiva por hipervisor como ocurre en VSE6.4 (en este caso una plantilla OVA/OVF) si no que se ofrecerá solo una virt iso.
  Posibilidad de aumentar el rendimiento (throughput) de asignando múltiples cores a VMs Vyatta en entornos VMware vSphere 5.
  

• Soporte para XenServer 6.0 (solo disponible en VSE6.4).
  

• Cambio de comportamiento global de firewall a stateful:
  
  Lectura recomendada: el stateful firewall de Vyatta. Estados del firewall. Vyatta Firewall Guide VC6.4.
  El funcionamiento por defecto del firewall es sin chequeo de estados (stateless) por defecto (aunque se puede convertir el firewall de Vyatta fácilmente a stateful o con chequeo de estados).
  Este comportamiento ahora cambia ya que desde Vyatta Network OS 6.4 se añade un parámetro que permite habilitar de forma global la naturaleza stateful del firewall de Vyatta en vez de tener que hacerlo manualmente en cada una de los grupos de reglas como hacíamos hasta ahora.
  

  • Vyatta Network OS cuenta ahora con un “interruptor” que habilita en el flujo la respuesta con chequeo de estados para el firewall.

  • El nuevo comando de modo configuración global de firewall:
    

  • Permite cualquier tráfico con estados ESTABLECIDO y RELACIONADO (Allows any ESTABLISHED and RELATED traffic).

  • Desecha cualquier tráfico con estado marcado como INVALIDO (Drops any INVALID traffic).

  • Elimina la necesidad de configurar el stateful firewall por grupo de reglas.
    

• Mejoras en el módulo de seguimiento de conexiones (Connection Tracking – conntrack):
  
  Lectura recomendada: Máquina de estados de conexiones.
  El módulo conntrack se ha mejorado para hacer frente al control granular y los requerimientos de auditoria de los proveedores de servicios cloud. Se incluye:
  

  • Administración avanzada del subsistema conntrack.

  • Posibilidad de borrado de conexiones por entrada.

  • Logueo de creación y supresión de conexiones.

  • Timeouts globales.

  • Timeouts configurables en base a conexiones según criterio de origen/destino.

  • El módulo conntrack ya no es una sub rama del firewall.
    

• Mejoras en la Funcionalidad de Sincronismo de Conexión – Soporte para failover continuo de conexiones FTP, SIP y H.323:
  
  En escenarios de alta disponibilidad, la tabla de seguimiento de conexiones se sincroniza por medio de sistemas redundantes por lo que si el sistema maestro falla otro sistema redundante puede tomar el control sin tener que restablecer las conexiones existentes. Sin embargo, el seguimiento de ciertos tipos de conexiones (por ejemplo FTP, SIP y H.323) se lleva a cabo mediante la tabla Expect con lo que se eliminaba la posibilidad de redundancia.
  En esta nueva versión ahora es posible configurar el sistema para sincronizar la tabla Expect en modo failover usando el servicio conntrack-sync. Para descripción de mecanismo de seguimiento de conexiones soportados ver la guia de referencia de Vyatta Connection Tracking.
  

• Mejoras en NAT:
  
  El soporte NAT en Vyatta Network OS ha sido mejorado con un diseño más intuitivo del proceso NAT. Estas mejoras incluyen:
  

  • En 6.4 NAT ha sido dividido en sub ramas “source” y “destination”.

  • El ordenamiento de reglas es mas fácil de definir y de solucionar problemas.

  • NAT ya no es un sub nodo de “service” – ahora es un nodo de nivel principal.
    

• Mejoras de interfaz de línea de comandos CLI:
  
  La interfaz de línea de comandos de Vyatta Network OS se ha hecho más sencilla y eficiente con la incorporación de comandos cortos inequívocos. También se han añadido asistentes de ruta de configuración que indican el tipo de nodo.
  Este punto hay que extenderlo claramente, hasta ahora es la info que tengo.
  

• Rediseño del modo de operación:
  
  Se ha rediseñado el modo operacional (esto me suena a electrónica básica…) de Vyatta Network OS 6.4 para un funcionamiento mas eficiente para usabilidad de categoría profesional.
  La estructura de comandos ha sido mejorada y se ha hecho más intuitiva. Se han añadido nuevos comandos monitor para simplificar la administración del sistema y para una depuración sencilla.
  

• Se ha eliminado el módulo de prevención de intrusión IPS (Snort):
  
  Por motivos de estabilidad y rendimiento Vyatta ha decidido anunciar el fin de la vida del módulo IPS incorporado (Snort) y del servicio Vyatta PLUS IPS desde el 31 de Marzo del 2012.
  Desde ese día Vyatta no acepta la actualización de reglas IPS desde su repositorio.
  
  Leer mas en esta entrada dedicada a la eliminación de Snort en Vyatta.
  
  

En cuanto estén disponibles las descargas de la versión VC6.4 lo anunciaré y ampliaré la información de mejoras y nuevos comandos una vez pruebe el nuevo VC6.4 y esté disponible la nueva documentación.

Fuentes y enlaces de interés:

• Noticia en vyatta.com: Introducing Vyatta Network OS 6.4 .

• Entrada de blog: What’s New In Vyatta Network OS 6.4?.

• Video: Get trained on what’s new in 6.4.

• Documentación: Download the latest documents – registro requerido.

• FAQ 6.4: Answers to questions around Vyatta Network OS 6.4.

• Debate sobre Snort en el grupo Vyatta Users de Linkedin: Introducing Vyatta Network OS 6.4 – our 14th major release.

• Debates sobre VC6.4 en el foro de la comunidad Vyatta.org: Vyatta Core 6.4 ? IPS.

• Publicación en openredes: Vyatta dice adiós a Snort.
  
  

¿Quieres probar la versión VC6.4 – oxnard? Aquí tienes una iso construida desde las versión de desarrollo o unstable.
También puedes construir tu propia iso desde código fuente.

Según explican en Vyatta, esta medida se ha tomado debido a que Snort influía mucho en el rendimiento del sistema y también en su estabilidad ya que el mantenimiento asociado con el motor actual ha requerido numerosas y frecuentes actualizaciones de software, lo que redunda en la estabilidad del sistema.
Por lo que según Vyatta lo que debemos hacer los usuarios que tenemos corriendo en alguna de nuestras máquinas el módulo “content-inspection” es borrar la configuración de este módulo antes o después de actualizar a la versión 6.4.

En este FAQ sobre Vyatta 6.4 podemos leer todo lo anterior.

Mas allá de las menciones oficiales respecto al abandono de Snort por parte de Vyatta, sabemos que la forma en la que Snort influye en la estabilidad de todo el sistema Vyatta es debido a que el análisis que Snort lleva a cabo se hace operando en una sola CPU y que por ahora no es posible hacer que Snort trabaje de forma linear con varias CPUs. Estas datos fueron publicados por Joel Esler de Snort en el grupo de usuario Vyatta de Linkedin en un debate muy interesante.

Mas info en este hilo del foro de la comunidad vyatta.org.

Nota: Puede probarse en otros hipervisores, en tal caso se ruega comentar resultados y/o posibles problemas.
La información que se ve en las imágenes puede muy distinta dependiendo del sistema operativo y el hipervisor usado.

• Descargar la imagen del VMDK de vyBuddy aquí y descomprimirla.
  Crear una nueva máquina virtual en VMware usando la imagen VMDK descargada como un disco virtual existente. Usar bridged networking (Workstation) para esta nueva máquina virtual si es posible.
  
  

  
  

  
  
  

• Elegir VM tipo custom para realizar ajustes avanzados.
  
  

  
  

  
  
  

• Ejecutaremos vyBuddy directamente desde la imagen VMDK de disco descargada, por lo que no es necesario instalar un SO.
  Elegimos por tanto la opción “I will install the operative system later.”
  
  

  

  
  
  

• Elegimos los parámetros del SO guest. Ubuntu Linux de 64-bit.
  
  

  
  

  
  
  

• En la siguiente pantalla elegimos “Use an existing virtual disk” ya que usaremos como disco virtual el VMDK descargado.
  
  

  
  

  
  
  

• Por último indicamos la ubicación de la imagen VMDK y creamos la nueva VM vyBuddy.
  
  

  

• Encender la nueva VM y acceder usando estas credenciales:
  
  Username: vybuddy / Password: vybuddy

  
  
  

• La NIC está configurada para arrancar con DHCP. Examinar la IP usando ifconfig o el comando ip address show, si no tenemos server DHCP en la red modificar la IP y DNS:
  
  

  vybuddy@vybuddy:~$ sudo vim /etc/network/interfaces:
  …
  …
  iface eth0 inet static
  	address x.x.x.x
  	netmask x.x.x.x
  	network x.x.x.x
  	broadcast x.x.x.x
  	gateway x.x.x.x
  …
  …
  vybuddy@vybuddy:~$ sudo echo nameserver x.x.x.x > /etc/resolv.conf
  vybuddy@vybuddy:~$ sudo echo nameserver x.x.x.x >> /etc/resolv.conf
  vybuddy@vybuddy:~$ sudo /etc/init.d/networking restart

  
  
  Nota: El teclado no está en Español, el carácter “/” lo encontramos en “-”, el carácter “-” en “‘”, el carácter “:” en “Ñ”.
  
  

• Accedemos a la máquina a través de SSH y ejecutamos el script update-vybuddy para actualizar el software del vyBuddy a la última versión:
  
  

  vybuddy@vybuddy:~$ update-vybuddy

Importante: Las credenciales del usuario vybuddy pueden usarse para accesos de consola, SSH y WWW UI. Sin embargo el cambio de contraseñas desde la WWW UI no afecta a la consola ni a SSH y viceversa.

Ya está todo listo para acceder a la máquina a través de HTTPS y configurar las claves SSH, los hosts Vyatta y las tareas!
Ahora toca familiarizarse con la interface GUI de vyBuddy.

• Acceder a la IP de vyBuddy desde el navegador e iniciar sesión con el usuario vybuddy.
  

• Lo siguiente es añadir nuestros host Vyatta a la interfaz de vyBuddy, para ello es necesario crear en las máquinas remotas Vyatta un par de claves SSH y un usuario llamado vybuddy que usará dichas claves para acceder por SSH de forma automática. Por seguridad se recomienda no usar las claves SSH existentes.
  

• En la máquina vyBuddy generar el par de claves rsa:
  
  

  vybuddy@vybuddy:~$ cd .ssh/
  vybuddy@vybuddy:~/.ssh$ ssh-keygen -t rsa -C vybuddy@192.168.1.21 -f vybuddy
  Generating public/private rsa key pair.
  Enter passphrase (empty for no passphrase):
  Enter same passphrase again:
  Your identification has been saved in vybuddy.
  Your public key has been saved in vybuddy.pub.
  The key fingerprint is:
  xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx vybuddy@10.0.0.21

  
  
  

• En la máquina Vyatta a monitorizar crear un usuario llamado vybuddy:
  
  

  root@R1:~# configure
  [edit]
  root@R1# set system login user vybuddy authentication plaintext-password mipass
  [edit]
  root@R1# commit
  [edit]
  root@R1# save
  [edit]

  
  
  

• Desde la máquina vyBuddy copiar la clave pública generada vybuddy.pub al directorio .ssh del usuario vybuddy creado en la máquina Vyatta remota:
  
  

  vybuddy@vybuddy:~/.ssh$ scp vybuddy.pub vybuddy@10.0.0.20:.ssh/vybuddy.pub
  Welcome to Vyatta
  vybuddy@10.0.0.20's password:
  vybuddy.pub                                                                              100%  399     0.4KB/s   00:00

• Vamos nuevamente a la máquina Vyatta remota y configuramos el usuario vybuddy para que pueda loguearse por SSH mediante la clave pública recién copiada:
  
  

  root@R1# loadkey vybuddy /home/vybuddy/.ssh/vybuddy.pub
  Done
  [edit]
  root@R1# show system login user vybuddy
   authentication {
       encrypted-password *******.
       plaintext-password ""
       public-keys vybuddy@10.0.0.21 {
           key ************************************************************************************
  ************************************************************************************
  ************************************************************************************
  **************************
           type ssh-rsa
       }
   }
  [edit]

  
  
  

• Vamos a la máquina vyBuddy y ejecutamos un cat para ver el contenido de la clave privada vybuddy generada:
  
  

  vybuddy@vybuddy:~/.ssh$ cat vybuddy
  -----BEGIN RSA PRIVATE KEY-----
  ***************************************************
  ***************************************************
  ***************************************************
  ***************************************************
  ***************************************************
  ***********************
  -----END RSA PRIVATE KEY-----

  
  
  

• Copiamos la clave mostrada desde consola y vamos a vyBuddy GUI para agregar la clave rsa del host remoto Vyatta:
  
  

  

  
  
  

• El paso siguiente es añadir el host Vyatta remoto al inventario de vyBuddy.
  Una vez añadido el nuevo host Vyatta, vyBuddy establece conexión SSH con el, le lanza los comandos especificados en la lista de comandos “Manage task” y muestra el resultado en el panel de control de vyBuddy:
  
  

  

  
  
  

• Podremos añadir como hosts a vyBuddy cualquier versión de Vyatta pero cuando añadimos un host anterior a la versión VC6.3 se establece correctamente la conexión SSH entre vyBuddy y Vyatta y vyBuddy nos devuelve un error al tratar de ejecutar comandos de modo operación en el host Vyatta:
  
  

  

  
  
  Es el error que Vyatta devuelve a vyBuddy cuando éste le pasa un comando de operación. Esto es debido a que vyBuddy trata de usar el script vyatta-op-cmd-wrapper alojado en /opt/Vyatta/bin pero que hasta la versión VC6.3 no se ha añadido.
  En versiones anteriores de Vyatta podemos solucionarlo simplemente descargando el archivo vyatta-op-cmd-wrapper, introduciéndolo dentro de la ruta especificada y dándole permisos 755.
  O podemos crearlo a mano:
  
  

  root@R1# echo -e "#!/bin/vbash -l\nshopt -s expand_aliases\nsource /etc/default/vyatta\nsource /etc/bash_completion.d/vyatta-op\n_vyatta_op_init\n_vyatta_op_run "$@"\n" > /opt/vyatta/bin/vyatta-op-cmd-wrapper
  [edit]
  root@R1# chmod 755 /opt/vyatta/bin/vyatta-op-cmd-wrapper
  [edit]

El desarrollo de vyBuddy está totalmente activo, por lo que debe ejecutarse el comando update-vybuddy cada poco tiempo y siempre antes de informar de un fallo o solicitar actuación.

vybuddy@vybuddy:~$ update-vybuddy

Puedes descargar esta guía en pdf aquí o en blog de vyatta4people.


Para solución de problemas y solicitud de ayuda no dudes en publicar tu comentario aquí o en www.vyatta4people.org.

Esperamos vuestras impresiones!!

Las posibilidades de configuración en alta disponibilidad de Vyatta incluyen varias funcionalidades y por lo tanto varios módulos a configurar posibles, por lo que vamos a enumerarlos aquí en forma de índice en capítulos y dedicar un post a parte para cada uno de ellos como tutorial ejemplo de configuración de Vyatta:

1. Capítulo 1: Balanceo de Carga WAN – Wan Load Balancing o WLB en Vyatta

2. Capítulo 2: Protocolo de Redundancia de Router Virtual – Virtual Router Redundancy Protocol (VRRP) en Vyatta

3. Capítulo 3: Clustering en Vyatta

4. Capítulo 4: Stateful NAT y Firewall Failover en Vyatta

5. Capítulo 5: RAID 1 en Vyatta

El resto de entradas relativas a Vyatta están disponibles aquí.
¿Te interesa Vyatta? únete a nuestro grupo Vyatta hispano en Linkedin!!

Para llevar a cabo el ejemplo de configuración de VRRP en Vyatta vamos a partir de la siguiente topología a modo de ejemplo:

Nota: utilizamos direcciones IPv4 TEST-NET-1

Tal y como se ve en la topología ejemplo VRRP, las interfaces de los routers Vyatta (R1 y R2) que conectan con la LAN son eth0 en ambos casos, cada una de ellas ha de configurarse con una IP de la red privada (192.0.2.0/24 en este caso ejemplo) y finalmente agregar cada una de ellas al mismo grupo VRRP, dicho grupo VRRP ha de configurarse con una IP y dicha IP será la IP virtual del grupo y la que actuara en la LAN como puerta de enlace determinada o router. Con esto se consigue un enlace redundante para una única IP y en el supuesto caso de que caiga alguno de los routers Vyatta (físico o virtual) el otro se hará cargo de actuar como router de la LAN sin que se aprecien cortes o caídas de servicio de red en la LAN.

Para configurar R1 y R2 para que sus interfaces eth0 trabajen en cluster y formen una sola interfaz virtual VRRP los pasos a seguir son los siguientes:

• En R1:
  
  

  vyatta@R1:~$ configure
  [edit]
  vyatta@R1# set interfaces ethernet eth0 address 192.0.2.251/24
  [edit]
  vyatta@R1# set interfaces ethernet eth0 vrrp vrrp-group 10 priority 150
  [edit]
  vyatta@R1# set interfaces ethernet eth0 vrrp vrrp-group 10 virtual-address 192.0.2.254
  [edit]
  vyatta@R1# set interfaces ethernet eth0 vrrp vrrp-group 10 description "LAN VRRP"
  [edit]
  vyatta@R1# set interfaces ethernet eth0 vrrp vrrp-group 10 advertise-interval 1
  [edit]
  vyatta@R1# set interfaces ethernet eth0 vrrp vrrp-group 10 authentication type ah
  [edit]
  vyatta@R1# set interfaces ethernet eth0 vrrp vrrp-group 10 authentication password mipass
  [edit]
  vyatta@R1# commit
  [edit]
  vyatta@R1# save
  [edit]
  vyatta@R1# show interfaces ethernet eth0
   address 192.0.2.251/24
   duplex auto
   hw-id 1a:2b:3c:4d:5e:6f
   smp_affinity auto
   speed auto
   vrrp {
       vrrp-group 10 {
  	     advertise-interval 1
  		 authentication {
  		     password ""
  			 type ah
  		}
  		description LAN VRRP
  		priority 150
  		virtual-address 192.0.2.254
  	}
   }
  [edit]
  vyatta@R1# 

  
  
  

• En R2:
  
  

  vyatta@R2:~$ configure
  [edit]
  vyatta@R2# set interfaces ethernet eth0 address 192.0.2.252/24
  [edit]
  vyatta@R2# set interfaces ethernet eth0 vrrp vrrp-group 10 priority 100
  [edit]
  vyatta@R2# set interfaces ethernet eth0 vrrp vrrp-group 10 virtual-address 192.0.2.254
  [edit]
  vyatta@R2# set interfaces ethernet eth0 vrrp vrrp-group 10 description "LAN VRRP"
  [edit]
  vyatta@R2# set interfaces ethernet eth0 vrrp vrrp-group 10 advertise-interval 1
  [edit]
  vyatta@R2# set interfaces ethernet eth0 vrrp vrrp-group 10 authentication type ah
  [edit]
  vyatta@R2# set interfaces ethernet eth0 vrrp vrrp-group 10 authentication password mipass
  [edit]
  vyatta@R2# commit
  [edit]
  vyatta@R2# save
  [edit]
  vyatta@R2# show interfaces ethernet eth0
   address 192.0.2.252/24
   duplex auto
   hw-id a1:b2:c3:d4:e5:f6
   smp_affinity auto
   speed auto
   vrrp {
       vrrp-group 10 {
  	     advertise-interval 1
  		 authentication {
  		     password ""
  			 type ah
  		}
  		description LAN VRRP
  		priority 100
  		virtual-address 192.0.2.254
  	}
   }
  [edit]
  vyatta@R2# 

Las imágenes se irán actualizando continuamente y se irán documentando cambios realizados entre versiones. Por ahora el desarrollo está muy verde y en estado Alpha. Se recomienda que visitéis el apartado de noticias de vybuddy y vyatta4people a menudo para ver actualizaciones y bugs publicados.

• Imagen alpha VMDK de vyBuddy para VMware Workstation: descarga desde vyatta4people
• Imagen alpha VMDK RAW disk de vyBuddy: descarga desde vyatta4people
• Imagen alpha de VM de vyBuddy para VMware ESX: descarga desde vyatta4people descarga desde openredes

Si alguien prueba las VMs con otros Hipervisores se ruega comenten sobre el proceso.