Recientemente me vi en la necesidad de utilizar una sola IP pública para varias VMs. La idea era ofrecer un servicio (OpenVPN en este caso) con fail over: tendría dos instancias de un mismo servicio, solamente una de ellas tendría asignada un IP público, pero si esa VM que tiene el IP público presenta algun problema (se apaga, pierde la red, etc) la otra asumiría el IP público y continuaría brindando el servicio.

En el escenario que mostraré tendré 3 VMs. Los detalles se muestran a continuación:

	VM1	VM1	VM1
Hostname	KA1	KA2	KA3
OS	Ubuntu 20.04	Ubuntu 20.04	Ubuntu 20.04
CPU/MEM	2vCPU/2GB	2vCPU/2GB	2vCPU/2GB
enp0s3 (Clientes)	192.168.43.101/24	192.168.43.102/24	192.168.43.103/24
enp0s8 (FloatingIP)	192.168.1.11/24	192.168.1.11/24	192.168.1.11/24
enp0s9 (Managment)	10.7.5.1/24	10.7.5.2/24	10.7.5.3/24

La interfaz enp0s8 de cada una de las VMs sera la que recibirá el «IP público». En este caso, al ser un labarotorio utilizaré el IP 192.168.1.11/24 como «IP público»

El servicio que se utilizará para la configuración del FailOver será el KeepAlive utilizando el protocolo VRRP.

---

Manos a la obra!

---

Configuraciones iniciales

Luego del archiconocido apt update y  apt upgrade de las VMs en donde vamos a trabajar lo primero será configurar las interfaces de red. Las interfaces enp0s3 y enp0s9 se utilizan para la conexión con los clientes y como red de managment respectivamente por lo que tendran un IP estático; mientras que la interfaz enp0s8 (como se mencionó anteriormente) será la que recibirá el FloatingIP de la «red pública», por lo que no se le asignará un IP, solamente se asegurará de que la interfaz está up.

A continuación se muestra el netplan de la primera VM (el resto es solo cambiar los IPs):

Si mostramos las interfaces con ip a veremos que la interfaz enp0s8 esta DOWN:

La «encederemos» (en cada VM) y comprobamos el estado de las mismas:

 

Instalando y configurando KeepAlive

En todas las VMs:

Una vez instalado tendremos que crear el archivo: /etc/keepalived/keepalived.conf en cada una de las VMs, y luego modificarlos a conveniencia. Intentaré explicar cada una de las opciones que he utilizado:

LB1:

El servicio de keepalived es muy flexible a la hora de las configuraciones que nos permite hacer, pero voy a limitarme a lo que nos interesa de momento:

• vrrp_instance KA1 {}: Identifica un bloque de definición de instancia VRRP.
• state: Especifica el estado de la instancia en uso estándar. En nuestro caso dejaremos a cada una de las VMs en el estado Master.
• interface: Especifica la interfaz de red que se utilizará para monitorear. Si esta interfaz se cae por cualquier motivo, entonces el keepalive tomará acciones. En este caso utilizaremos la interfaz de managment (enp0s9).
• virtual_router_id: Especifica a qué ID de enrutador VRRP pertenece la instancia. Se puede utilizar cualquier numero, pero tener en cuenta que este ID tiene q repetirse en los demás archivos de configuracion de las demas VMs.
• priority: Especifica la prioridad de la instancia en el enrutador VRRP. Este número varía entre las diferentes VMs. Mientras una VM tenga un numero de priority mayor será la que asuma el IP.
• advert_int: Especifica el intervalo en el cual se encuestan a las demas VMs del cluster para ver su disponibilidad. En segundos (establecido en 1 por defecto).
• notify: Especifica un script de shell que se ejecutará durante la transición al estado Master. En este momento esta comentado, pero en la ultima sección del artículo mostraré un ejemplo.
• authentication: Identificar un bloque de definición de autenticación VRRP. Es la contraseña que utilizan los diferentes integrantes del «cluster» del keepalive para comunicarse entre sí (esta configuración puede obviarse).
• virtual_ipaddress: Identifica un bloque de definición VIP VRRP. En esta sección se pueden configurar los IPs y las interfaces que tendra la VM que este actuando como Master. Nótese que se le puede asignar un IP a una interfaz que anteriormente ya estaba configurada, en el ejemplo la VM actuando como Master en su interfaz enp0s3 asumirá el IP 192.168.43.100/24.
• virtual_routes: Permite especificar la ruta por defecto del Master. En este caso la ruta por defecto será el gateway de mis VMs, o sea mi ISP.

 

Inicializando los servicios

Una vez tengamos configurado el keepalived a nuestro gusto podemos proceder a inicializar el servicio en la primera VM y checkear su estado:

Las interfaces que sean utilizadas por el servicio de keepalived tienen q estar en estado UP, sino el servicio dará error.

Nótese que la contraseña es muy larga y será truncada a solamente 8 caracteres!

 

Ahora podremos comprobar los IPs de esta VM (actualmente en el estado Master del servicio):

 

Como se puede comprobar la interfaz enp0s3 tiene dos IPs asignados, mientras que la interfaz enp0s8 (la que fungiría como IP público) tiene su único IP asignado (FloatingIP).

---

Bien, procedamos entonces a configurar la VM2 (KA2):

Nótese que la prioridad en este es más baja que en el caso de la VM1 (KA1)

Solo resta inicializar y comprobar el estado del servicio.

Comprobemos el estado de los IPs:

Como se puede apreciar la interfaz enp0s3 continúa con su único IP mientras que la interfaz enp0s3 no tiene ningun IP asignado.

 

---

Solamente queda configurar la ultima VM (KA3):

Ahora, como en los anteriores casos, procedemos a inicializar el servicio y a checkearlo:

Si checkeamos el estado de la interfaces y sus IPs asignados, podremos comprobar que ocurre lo mismo que con el caso de KA2.

---

Comprobando que el servicio funciona

Para comprobar que el servicio funciona simplemente apagaremos la interfaz de managmente enp0s9 de KA1. Recuerden q es esta la interfaz configurada para checkear.

Si ahora checkeamos el estado del servicio en KA1, y luego sus interfaces veremos los FloatingIP dejan de estar configurados:

Ahora, si checkeamos el estado de KA2 veremos como la interfaz enp0s3 asume el FloatingIP configurado, mientras que con la interfaz enp0s8 ocurre igual:

Si checkeamos el estado del servicio en KA2:

 

Lo mismo ocurrirá en el caso si apagamos la interfaz de managment de KA2, KA3 asumirá el role de Master.

---

Si encendemos la interfaz de managment de KA1, veremos como enseguida asume el role de Master, pues tiene una prioridad mayor que KA2:

 

La opcion «notify»

En el archivo de configuración hay una opción llamada notify. Esta configuración nos permite correr un script cada vez que keepalive detecte un cambio en sus estados (por ejemplo: de Backup a Master).

Como mencioné al principio en mis VMs corre un servicio de OpenVPN al cual se conectaran clientes desde alguna red pública, pero no es necesario que el servicio esté habilitado en todo momento en todas las VMs, por lo tanto, crearemos un script que, en dependencia del estado del servicio de keepalived iniciará o detendrá el servicio de OpenVPN:

El notify pasa 4 parámetros al script:

• $1: Grupo o instancia: Indicación de si la notificación la activa un grupo VRRP o una instancia VRRP en particular.
• $2: Nombre del grupo o instancia
• $3: Indica qué tipo de transición se encuentra el grupo o instancia
• $4: La prioridad

 

Si hace cualquier cambio en los archivos de configuración (descomentar la opcion del notify en este caso) del servicio keepalived recuerde reinicializar el servicio.

En el script, como parte del logueo, indiqué que en /opt/k_logs/keepalived_status me muestre los cambios, si configuramos el script en KA1, apagamos e iniciamos la interfaz de managment y luego leemos el archivo de log veremos algo como:

Y de esta forma sencilla podemos controlar el servicio de OpenVPN en depedencia del estado del servicio de keepalived

 

+++++++++++++++++++++++++++++++++++++++++++++++++++

Autores:

Frank Morales
Franco Díaz