- \n
- Hacer un despliegue automatizado de la configuraci\u00f3n inicial de cortafuegos vyatta en cl\u00faster a partir de cortafuegos individuales.<\/li>\n
- Automatizar el desploegue y borrado de m\u00faltiples reglas en diferentes cortafuegos<\/li>\n<\/ul>\n
Para ello, lo primero ha sido preparar un entorno de demo, que ha tenido casi m\u00e1s chicha que la propia configuracion con Ansible:<\/p>\n
![\"Diagrama](\"http:\/\/bitacora.eniac2000.com\/wp-content\/uploads\/2015\/12\/pic26060-400x249.gif\" "\\"Diagrama")
<\/a>Diagrama del entorno de despliegue<\/figcaption><\/figure>
\n…que se compone de los siguientes elementos:<\/p>\n- \n
- Port\u00e1til:<\/strong> Mi propio port\u00e1til de trabajo. Act\u00faa como entorno de virtualizaci\u00f3n basado en KVM. Su funci\u00f3n como entorno de virtualizaci\u00f3n no es relevante en s\u00ed como elemento de testeo, pero sin \u00e9l no ser\u00eda posible realizar el despliegue del entorno. S\u00ed es relevante su funci\u00f3n como cliente de los servicios desplegados por el servidor CirrOS. Se le ha configurado una ruta est\u00e1tica para enrutar el tr\u00e1fico a trav\u00e9s de la IP .254 de la subred externa, que ser\u00e1 la IP flotante del cl\u00faster de cortafuegos.<\/li>\n
- Servidor CirrOS:<\/strong> Servidor extremadamente ligero (en torno a 32 MB de RAM y un procesador) que levanta servicios SSH y HTTP, este \u00faltimo mediante una simulaci\u00f3n con NetCat, lo que tambi\u00e9n tiene su miga. En cuanto al servidor CirrOS, a los conocedores de entornos cloud como Openstack les sonar\u00e1 bastante, pero he conseguido hacer un despliegue en un entorno KVM convencional.<\/li>\n
- Cl\u00faster de cortafuegos Vyatta:<\/strong> El cl\u00faster de cortafuegos Vyatta (bueno, en realidad VyOS, el fork software libre surgido cuando Brocade compr\u00f3 el proyecto original) act\u00faa como cortafuegos entre las subredes interna y externa. En la fase inicial consiste en dos cortafuegos independientes, como una configuraci\u00f3n b\u00e1sica de sus interfaces de red y poco m\u00e1s, con direcci\u00f3namiento .252 y .253. En esta fase, por lo tanto, el port\u00e1til no es capaz de conectar con el servidor CirrOS. El equipo vyatta1<\/strong> actuar\u00e1 como maestro en la configuraci\u00f3n VRRP, y el equipo vyatta2<\/strong> actuar\u00e1 como esclavo.<\/li>\n
- Ansible:<\/strong> Este servidor act\u00faa como servidor de Ansible, como su propio nombre indica. Conecta con los dispositivos vyatta haciendo uso de clave SSH, por lo que -y esto es de lo mejor de Ansible- no necesita de ning\u00fan tipo de agente o plugin para realizar los despliegues de configuraci\u00f3n o recogida de informaci\u00f3n desde los dispositivos.<\/li>\n<\/ul>\n
Ansible -y esto no pretente ser una descripci\u00f3n exhaustiva de sus caracter\u00edsticas, por lo que ruego se me perdone cualquier incorrecci\u00f3n que pueda perpetrar- puede actuar bien enviando comandos \u00fanicos a los equipos administrados, bien haciendo uso de recetas (playbooks). Estas recetas consisten en un grupo de tareas<\/strong>, plantillas <\/strong>y par\u00e1metros <\/strong>que se combinan para realizar las labores de automatizaci\u00f3n de configuraci\u00f3n y labores de gesti\u00f3n en los dispositivos<\/strong>:<\/p>\n
- \n
- Tareas (task):<\/strong> Comando o grupo de comandos que realizan alguna acci\u00f3n en el dispositivo. \u00c9stas pueden ser creadas en base a m\u00f3dulos predefinidos para simplificar su proceso de creaci\u00f3n<\/li>\n
- Plantillas (templates):<\/strong> Las tareas pueden hacer uso de plantillas para simplificar el proceso de configuraci\u00f3n o gesti\u00f3n de los dispositivos. Estas plantillas, cuyas variables se completan haciendo uso de los valores asignados a los par\u00e1metros, se usan para crear al vuelo los scripts (o cualquier comando) que se quieran aplicar al dispositivo. Lo m\u00e1s interesante del asunto es que estas plantillas se pueden crear de manera bastante sencilla en base a scripts convencionales que ya se estuvieran utilizando para gestionar el dispositivo, simplemente reemplazando las variables del scripts por las variables propias de j2, que posteriormente, en tiempo de ejecuci\u00f3n, ser\u00e1n sustituidas por los par\u00e1metros definidos en Ansible.<\/li>\n
- Par\u00e1metros:<\/strong> Valores concretos de la configuraci\u00f3n de los dispositivos a gestionar con Ansible, como por ejemplo el nombre del cortafuegos, la IP de una interfaz, o los valores de la VPN. Estos par\u00e1metros pueden ser definidos de m\u00faltiples maneras: usando un fichero de configuraci\u00f3n global de par\u00e1metros, usando ficheros espec\u00edficos para cada dispositivo (algo especialmente interesante para este caso), almacenando valores en tiempo de ejecuci\u00f3n de los propios dispositivos gestionados o del entorno, o una combinaci\u00f3n de estos m\u00e9todos. Posteriormente, estos par\u00e1metros se usan para configurar los dispositivos, bien mediante tareas individuales o mediante plantillas.<\/li>\n
- Dispositivos (hosts):<\/strong> Conjunto de servidores que queremos administrar. Pueden ser etiquetados para aplicarle s\u00f3lo ciertas tareas (por ejemplo, los dispositivos individuales de las parejas de vyattas pueden ser etiquetados como maestro <\/em>y esclavo <\/em>para s\u00f3lo aplicar a cada uno de ellos la configuraci\u00f3n que corresponda) que sean de aplicaci\u00f3n para el tipo de disposito gestionado.<\/li>\n<\/ul>\n
Una vez configurado el entorno, el recetario, las plantillas y par\u00e1metros, la configuraci\u00f3n qued\u00f3 lista para ser aplicada a los dispositivos. Las tareas de un recetario pueden ser ejecutadas de manera secuencial o en una sucesi\u00f3n espec\u00edfica, usando para ello las oportunas etiquetas. En mi entorno, y hasta el momento, he definido tres tipos de tareas:<\/p>\n
- \n
- Despliegue inicial:<\/strong> Realiza el despligue inicial de la configuraci\u00f3n a la pareja de vyattas para convertirlos en un cl\u00faster y realizar las configuraciones b\u00e1sicas de seguridad y gesti\u00f3n requeridas. En el entorno de demo, una vez realizada esta tarea, queda configurada la interfaz flotante en ambas subredes, realizado NAT y el enmascaramiento del tr\u00e1fico de la interfaz interna a la externa, y permitido el tr\u00e1fico ICMP entrante de la interfaz externa a la interna. Todo ello permite que el port\u00e1til haga ping al servidor, pero no pueda acceder a los servicios.<\/li>\n
- A\u00f1adir reglas:<\/strong> Esta tarea realiza un despliegue de pol\u00edtica a los cortafuegos. En concreto, permite el tr\u00e1fico por los puertos 22 y 80 TCP al servidor CirrOS.<\/li>\n
- Borrado de reglas:<\/strong> Permite eliminar las reglas anteriormente definidas<\/li>\n<\/ul>\n
Un ejemplo de ejecuci\u00f3n de Ansible para este entorno ser\u00eda el siguiente:<\/p>\n
i82hisaj@debian:~\/ansible\/vyos# ansible-playbook main.yml -t initial<\/p>\nPLAY [all] ******************************************************************** <\/p>\n
GATHERING FACTS ***************************************************************
\nok: [192.168.122.252]
\nok: [192.168.122.253]<\/p>\nTASK: [initial-config | upload script for configuring description] ************
\nchanged: [192.168.122.252]
\nchanged: [192.168.122.253]<\/p>\nTASK: [initial-config | run script for configuring description] ***************
\nchanged: [192.168.122.252]
\nchanged: [192.168.122.253]<\/p>\nTASK: [initial-config | debug var=desc_value.stdout_lines] ********************
\nok: [192.168.122.253] => {
\n \"desc_value.stdout_lines\": \"{{ desc_value.stdout_lines }}\",
\n \"item\": \"\"
\n}
\nok: [192.168.122.252] => {
\n \"desc_value.stdout_lines\": \"{{ desc_value.stdout_lines }}\",
\n \"item\": \"\"
\n}<\/p>\nPLAY RECAP ********************************************************************
\n192.168.122.252 : ok=4 changed=2 unreachable=0 failed=0
\n192.168.122.253 : ok=4 changed=2 unreachable=0 failed=0 <\/p>\ni82hisaj@debian:~\/ansible\/vyos# ansible-playbook main.yml -t add<\/p>\n
PLAY [all] ******************************************************************** <\/p>\n
GATHERING FACTS ***************************************************************
\nok: [192.168.122.253]
\nok: [192.168.122.252]<\/p>\nTASK: [rules | retrieve Description for a firewall] ***************************
\nchanged: [192.168.122.252]
\nchanged: [192.168.122.253]<\/p>\nTASK: [rules | upload script for configuring description] *********************
\nchanged: [192.168.122.252]
\nchanged: [192.168.122.253]<\/p>\nTASK: [rules | run script for configuring description] ************************
\nchanged: [192.168.122.252]
\nchanged: [192.168.122.253]<\/p>\nTASK: [rules | debug var=desc_value.stdout_lines] *****************************
\nok: [192.168.122.252] => {
\n \"desc_value.stdout_lines\": [
\n \"Outside In\"
\n ],
\n \"item\": \"\"
\n}
\nok: [192.168.122.253] => {
\n \"desc_value.stdout_lines\": [
\n \"Outside In\"
\n ],
\n \"item\": \"\"
\n}<\/p>\nPLAY RECAP ********************************************************************
\n192.168.122.252 : ok=5 changed=3 unreachable=0 failed=0
\n192.168.122.253 : ok=5 changed=3 unreachable=0 failed=0 <\/p>\ni82hisaj@debian:~\/ansible\/vyos# ansible-playbook main.yml -t delete<\/p>\n
PLAY [all] ******************************************************************** <\/p>\n
GATHERING FACTS ***************************************************************
\nok: [192.168.122.252]
\nok: [192.168.122.253]<\/p>\nTASK: [initial-config | debug var=desc_value.stdout_lines] ********************
\nok: [192.168.122.252] => {
\n \"desc_value.stdout_lines\": \"{{ desc_value.stdout_lines }}\",
\n \"item\": \"\"
\n}
\nok: [192.168.122.253] => {
\n \"desc_value.stdout_lines\": \"{{ desc_value.stdout_lines }}\",
\n \"item\": \"\"
\n}<\/p>\nTASK: [rules | upload script for deleting rule] *******************************
\nchanged: [192.168.122.252]
\nchanged: [192.168.122.253]<\/p>\nTASK: [rules | run script for configuring description] ************************
\nchanged: [192.168.122.253]
\nchanged: [192.168.122.252]<\/p>\nTASK: [rules | debug var=desc_value.stdout_lines] *****************************
\nok: [192.168.122.253] => {
\n \"desc_value.stdout_lines\": \"{{ desc_value.stdout_lines }}\",
\n \"item\": \"\"
\n}
\nok: [192.168.122.252] => {
\n \"desc_value.stdout_lines\": \"{{ desc_value.stdout_lines }}\",
\n \"item\": \"\"
\n}<\/p>\nPLAY RECAP ********************************************************************
\n192.168.122.252 : ok=5 changed=2 unreachable=0 failed=0
\n192.168.122.253 : ok=5 changed=2 unreachable=0 failed=0
\n<\/code><\/p>\nAlgunas ideas hasta el momento:<\/p>\n
- \n
- Desafortunadamente no existe ning\u00fan m\u00f3dulo oficial que permita hacer la administraci\u00f3n simplificada de cortafuegos vyatta, lo que significa que todo el trabajo de definir la automatizaci\u00f3n de tareas ha de realizarse desde cero, en base a scripts y configuraciones b\u00e1sicas de Ansible.<\/li>\n
- Afortunadamente, el sistema de interacci\u00f3n de Ansible es lo suficientemente flexible para permitir la conversi\u00f3n sencilla de scripts previamente existentes a plantillas J2, lo que permite -en mi caso- aprovechar bastante trabajo previo ya existente.<\/li>\n
- Existen interesantes posibilidades de conectar Ansible con sistemas de gesti\u00f3n v\u00eda web, como es el caso del proyecto Semaphore<\/a>.<\/li>\n<\/ul>\n
En resumen, si bien Ansible este caso requiere de bastante trabajo para poder realizar de manera efectiva la automatizaci\u00f3n del despliegue y gesti\u00f3n de cortafuegos (vyatta, en este caso), las ventajas que proporciona y el trabajo final que ahorra hacen que valga la pena. Como dir\u00eda nuestro amigo Barney, en este caso nos encontramos claramente por encima de la diagonal Vicky Mendoza:<\/p>\n
- A\u00f1adir reglas:<\/strong> Esta tarea realiza un despliegue de pol\u00edtica a los cortafuegos. En concreto, permite el tr\u00e1fico por los puertos 22 y 80 TCP al servidor CirrOS.<\/li>\n
- Plantillas (templates):<\/strong> Las tareas pueden hacer uso de plantillas para simplificar el proceso de configuraci\u00f3n o gesti\u00f3n de los dispositivos. Estas plantillas, cuyas variables se completan haciendo uso de los valores asignados a los par\u00e1metros, se usan para crear al vuelo los scripts (o cualquier comando) que se quieran aplicar al dispositivo. Lo m\u00e1s interesante del asunto es que estas plantillas se pueden crear de manera bastante sencilla en base a scripts convencionales que ya se estuvieran utilizando para gestionar el dispositivo, simplemente reemplazando las variables del scripts por las variables propias de j2, que posteriormente, en tiempo de ejecuci\u00f3n, ser\u00e1n sustituidas por los par\u00e1metros definidos en Ansible.<\/li>\n
- Servidor CirrOS:<\/strong> Servidor extremadamente ligero (en torno a 32 MB de RAM y un procesador) que levanta servicios SSH y HTTP, este \u00faltimo mediante una simulaci\u00f3n con NetCat, lo que tambi\u00e9n tiene su miga. En cuanto al servidor CirrOS, a los conocedores de entornos cloud como Openstack les sonar\u00e1 bastante, pero he conseguido hacer un despliegue en un entorno KVM convencional.<\/li>\n
- Port\u00e1til:<\/strong> Mi propio port\u00e1til de trabajo. Act\u00faa como entorno de virtualizaci\u00f3n basado en KVM. Su funci\u00f3n como entorno de virtualizaci\u00f3n no es relevante en s\u00ed como elemento de testeo, pero sin \u00e9l no ser\u00eda posible realizar el despliegue del entorno. S\u00ed es relevante su funci\u00f3n como cliente de los servicios desplegados por el servidor CirrOS. Se le ha configurado una ruta est\u00e1tica para enrutar el tr\u00e1fico a trav\u00e9s de la IP .254 de la subred externa, que ser\u00e1 la IP flotante del cl\u00faster de cortafuegos.<\/li>\n
![\"\"](\"http:\/\/bitacora.eniac2000.com\/wp-content\/uploads\/2015\/12\/vlcsnap-00012.jpg\" "\\"Escala")
<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"