Ejemplos y tutoriales de configuración de Vyatta
Colección de ejemplos y tutoriales de configuación de las diferentes herramientas de Vyatta. Router, firewall, IPS, balanceo de carga, NAT, VPNs, SSH, etc.
Enviar una lista de comandos a Vyatta de forma remota usando un fichero
1Cuando tenemos varias máquinas Vyatta con una configuración homogénea y necesitamos modificar la configuración de estas de la misma forma en cada una tenemos dos opciones, conectarnos por SSH a cada una de nuestras máquinas Vyatta y modificar la configuración una por una o crear un fichero de texto que contenga todos los comandos a ejecutar en cada máquina y enviarlo a cada una de las máquinas para que se ejecute por SSH y así no haya que escribir los mismos comandos en cada una de las máquinas Vyatta.
Por supuesto la segunda opción es mucho mas rápida y agiliza mucho el proceso de crear la misma configuración en diferentes máquinas Vyatta pero lleva consigo riesgos añadidos ya que los comandos se ejecutarán directamente y se pondrán en funcionamiento si posibilidad previa de prueba y error, por lo que recomiendo este método solo para usuarios expertos en Vyatta y que sepan muy bien lo que hacen y lo que van a configurar.
Vamos con un ejemplo de demostración:
Imaginemos que queremos implementar una nueva regla de firewall idéntica en cada una de nuestras máquinas Vyatta remotas, dicha regla permitirá el acceso SSH desde la LAN hacia el exterior, sabemos que la interfaz LAN de Más >
Alta disponibilidad (HA), redundancia y tolerancia a fallos en Vyatta – teoría y práctica de configuración HA en Vyatta
2Otra de las posibilidades más interesantes (difícil decir cual no lo es) es la de poder crear infraestructuras de alta disponibilidad (HA), redundantes y tolerantes a fallos con Vyatta Core con solo tener el recurso de una segunda maquina x86 que poder dedicar a Vyatta. De esta forma, con algo tan al alcance de la mano como dos equipos con hardware x86 con capacidades hardware adaptadas a las necesidades de la red concreta, con Vyatta Core instalado en ellas y con una buena configuración, se puede conseguir una infraestructura redundante, tolerante a fallos y altamente disponible gracias a Vyatta, quien da más?
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:
-
Capítulo 1: Balanceo de Carga WAN – Wan Load Balancing o WLB en Vyatta
-
Capítulo 2: Protocolo de Redundancia de Router Virtual – Virtual Router Redundancy Protocol (VRRP) en Vyatta
-
Capítulo 3: Clustering en Vyatta
-
Capítulo 4: Stateful NAT y Firewall
Más >
Ejemplo de configuración de VRRP en Vyatta – HA con Vyatta
10Tras el manual, tutorial o guía de configuración de VRRP en Vyatta vamos a pasar a la acción y vamos a configurar un entorno ejemplo redundante con VRRP entre dos máquinas Vyatta. En el ejemplo de configuración de VRRP en Vyatta vamos a crear un cluster entre las interfaces de dos routers Vyatta conectadas a una LAN , así, ante cualquier fallo HW (un switch, la NIC de un router Vyatta, un cable, etc), la red LAN seguirá siendo operativa, con lo que conseguimos failover o tolerancia a fallos con Vyatta. En entornos virtuales VRRP con Vyatta también tiene sentido ya que si por algún motivo cae una de las VMs que contienen Vyatta y no levanta, la otra del cluster se hará cargo de ser la puerta de enlace o router de nuestra LAN.
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 Más >
Actualización controlada de Vyatta
1Ahora que llevamos un tiempo usando Vyatta vemos que van saliendo actualizaciones y nuevas versiones de este magnífico Sistema Operativo de redes, tanto si lo tenemos instalado en un laboratorio casero para hacer pruebas, en una máquina física en producción o gestionando las redes en un entorno virtualizado, siempre llega el momento en el que se hace necesario actualizar Vyatta o instalar una versión de Vyatta mas actual, bien porque se corrigen algunos bugs de sistema, bien porque la nueva versión de Vyatta tenga nuevos comandos que resultan interesantes o bien porque nos gusta tener nuestros equipos al día. También es una opción interesante la de tener varias versiones de Vyatta en una misma máquina y arrancar con la que queramos. Pero, ¿cómo se actualiza Vyatta? ¿cuáles son los riesgos? ¿me guarda la configuración actual? ¿puedo actualizar Vyatta de forma remota? ¿qué pasa si algo no termina de ir bien y quiero volver atrás?
Vamos primero con las posibles dudas:
-
A saber:
-
Una vez descargada la nueva versión a la que queremos actualizar se queda todo instalado pero la versión antigua seguirá en funcionamiento hasta que no reiniciemos la máquina .
-
La configuración en
-
Configuración del módulo firewall de Vyatta. Parte 12 – Configuración de firewall en las interfaces VPN de acceso remoto vtun0 y vtun1 (VPN RA) de openredesR1.
1La última parte (por fin!) de los ejemplos, tutoriales de configuración del firewall de Vyatta según nuestra topología ejemplo es la creación de los grupos de reglas que gestionaran las conexiones para las interfaces de acceso remoto VPN de openredesR1, estas son vun0 y vtun1, si vemos la política general de conexiones establecida el resumen para estas interfaces es: Por las VPNs de acceso remoto vtun0 y vtun1 vamos a permitir solamente el trafico destinado a los servicios ofrecidos por los servidores corporativos.
Vamos entonces a crear las reglas necesarias.
-
Creamos primero el grupo de puertos necesario:
openredes@openredesR1# edit firewall group port-group puertos-vpnra [edit firewall group port-group puertos-vpnra] openredes@openredesR1# set port www [edit firewall group port-group puertos-vpnra] openredes@openredesR1# set port https [edit firewall group port-group puertos-vpnra] openredes@openredesR1# set port ms-sql-s [edit firewall group port-group puertos-vpnra] openredes@openredesR1# set port mysql [edit firewall group port-group puertos-vpnra] openredes@openredesR1# commit [edit firewall group port-group puertos-vpnra] openredes@openredesR1# -
Como las
Más >
Configuración del módulo firewall de Vyatta. Parte 11 – Configuración de firewall en la interfaz vtun10 (VPN STS) de openredesR2
4En la configuración de firewall Vyatta para openredesR2 quedan por hacer los grupos de reglas que gestionan las conexiones para la interfaz VPN, concretamente vtun10 (VPN STS), vamos a crear ahora el grupo de reglas de firewall para vtun10 según la política establecida para nuestra topología ejemplo.
A modo de resumen, la política de firewall establece para la interfaz VPN de openredesR2 que conecta ambas sedes que: Por vtun10 de openredesR2 permitiremos como tráfico local solo el tráfico OSPF (en caso de haberlo configurado) proveniente del otro extremo de la VPN. Como tráfico de entrada, permitiremos la respuesta a las conexiones de administración que los departamentos I+D y Desarrollo hagan a los equipos de la DMZ, así como el trafico entrante con destino a los servidores corporativos destinado a servicios permitidos.
-
Comenzamos creando las reglas para tráfico local:
openredes@openredesR2# edit firewall name vpnsts-local rule 2 [edit firewall name vpnsts-local rule 2] openredes@openredesR2# set action reject [edit firewall name vpnsts-local rule 2] openredes@openredesR2# set state invalid enable [edit firewall name vpnsts-local rule 2] openredes@openredesR2# set logMás >
Configuración del módulo firewall de Vyatta. Parte 10 – Configuración de firewall en la interfaz vtun10 (VPN STS) de openredesR1
2En la configuración de firewall Vyatta para openredesR1 quedan por hacer los grupos de reglas que gestionan las conexiones para las interfaces VPN, concretamente vtun10 (VPN STS), vtun0 (VPN RA) y vtun1 (VPN RA), vamos a crear ahora el grupo de reglas de firewall para vtun10 según la política establecida para nuestra topología ejemplo.
A modo de resumen, la política de firewall establece para la interfaz VPN de openredesR1 que conecta ambas sedes que: Por vtun10 de openredesR1 permitiremos como tráfico local el trafico OSPF (en caso de haberlo configurado) proveniente del otro extremo de la VPN y el tráfico de administración generado por el departamento de I+D. Como tráfico de entrada, permitiremos las respuestas a las peticiones que se hagan a los servidores corporativos iniciadas en el extremo de openredesR1.
-
Comenzamos creando las reglas para tráfico local:
openredes@openredesR1:~$ configure [edit] openredes@openredesR1# edit firewall name vpnsts-local rule 2 [edit firewall name vpnsts-local rule 2] openredes@openredesR1# set action reject [edit firewall name vpnsts-local rule 2] openredes@openredesR1# set state invalid enable [edit firewall name vpnsts-local ruleMás >
Configurar un cliente OpenVPN en Windows con OpenVPN GUI para conectar a una VPN RA en Vyatta
3Tras haber configurado en nuestras máquinas Vyatta una o varias interfaces VPN de acceso remoto con OpenVPN que funcionan como servidor según esta guía, necesitamos configurar los clientes que se conectaran a la VPN y que podrán acceder a la red corporativa de forma remota desde cualquier lugar en el que se encuentren. De igual forma los pasos de este manual son válidos para configurar un cliente OpenVPN GUI en Windows y poder conectar a cualquier servidor creado con OpenVPN. En este manual de configuración vamos a configurar un cliente con SO Windows XP. Suponemos que ya tenemos creados los certificados necesarios y que tenemos también nuestras máquinas Vyatta configuradas para que actúen como servidor VPN y permitan el acceso remoto a los clientes.
OpenVPN puede correr como daemon, como servicio o desde la línea de comandos, pero también es posible controlar OpenVPN por medio de un front-end grafico o interfaz gráfico de usuario, conocido también como GUI por sus siglas en inglés.
Configurar un cliente VPN de acceso remoto a Vyatta con OpenVPN GUI en GNU/Linux
1Tras haber configurado en nuestras máquinas Vyatta una o varias interfaces VPN de acceso remoto con OpenVPN que funcionan como servidor según esta guía, necesitamos configurar los clientes que se conectaran a la VPN y que podrán acceder a la red corporativa de forma remota desde cualquier lugar en el que se encuentren. En este manual de configuración vamos a configurar un cliente con SO Ubuntu 11.04. Suponemos que ya tenemos creados los certificados necesarios y que tenemos también nuestras máquinas Vyatta configuradas para que actúen como servidor VPN y permitan el acceso remoto a los clientes.
OpenVPN puede correr como daemon, como servicio o desde la línea de comandos, pero también es posible controlar OpenVPN por medio de un front-end grafico o interfaz gráfico de usuario, conocido también como GUI por sus siglas en ingles. En esta wiki de OpenVPN tenemos la lista más reciente de OpenVPN GUIs disponibles.
De la lista he elegido en este caso “OAST” un interfaz GUI para clientes OpenVPN escrito en Java, así que vamos primero a instalarlo en nuestro Ubuntu.
-
Vamos a la pagina de descargas, elegimos la versión adecuada, en mi caso la version 2.4 para un Linux x86 (en los foros
Más >
Significado de los parametros de configuracion del archivo .ovpn en un cliente remoto de OpenVPN
3En esta entrada explicamos el significado de los parámetros más comunes a usar en el archivo de configuración de un cliente OpenVPN .ovpn para cualquier sistema operativo.
client/server: especifica el tipo de nodo que queremos configurar. dev tap/tun: tipo de interfaz a usar, hay que elegir la misma tanto en la parte del cliente como en la del servidor. La opción "tun" es la opción por defecto y la recomendada. La diferencia entre ambas es que la interfaz "tun" es una interfaz enrutada y la interfaz "tap" es para crear un bridge ethernet (capa 2), necesario en caso de usar protocolos no IP como IPX. proto tcp/udp: protocolo de transporte a usar, la opción por defecto y lo normal es "udp". Hay que elegir lo mismo en los dos extremos. remote IP-servidor/cliente puerto: en esta línea se pone la IP publica en la que está el extremo opuesto y el puerto en el que se espera la conexión. El puerto por defecto es el 1194. resolv-retry infinite/n: opción de cliente, trata de resolver infinitas o n veces la conexión con el servidor. nobind: opción de cliente, si se configura especifica que no es necesario usar siempre el mismo puerto local de origen para iniciar la conexión Más >











Comentarios recientes