VRRP

El otro día tuve la oportunidad de ver soluciones de Alta Disponibilidad, entonces fue cuando me comentaron si conocía cierto protocolo llamado VRRP: Virtual Redundance Route Protocol. Esto es algo así como una solución de alta disponibilidad por infraestructura donde todo está duplicado físicamente, aunque esto según el modelo de implantación puede cambiar, pueden estar duplicados los router, los switch, los firewall, los servidores, etc. Por ejemplo la siguiente imagen muestra como la gente de Cisco ofrece soluciones de este tipo para un router virtual (VPN 3000).

Si nos fijamos en lo que hacen los de Nokia con sus Firewall Checkpoint tenemos prácticamente lo mismo, en este caso lo que se duplica es el Firewall (cada uno con un ISP) pero después los servicios que cuelgan detrás no están redundados. ¿Cómo funciona este protocolo exactamente? Si nos vamos a la “interesante” RFC 3678 (digo Interesante por que he de confesar que necesito una fuerte necesidad y/ò aburrimiento para ponerme a leer estas cosas) podemos ver que un dispositivo maestro enviará periódicamente paquetes VRRP a todos los dispositivos del mismo nivel, es decir podemos redundar 1, 2, 3 y todas las veces que queramos. Los paquetes VRRP se encapsulan en paquetes IP (seguimos en el nivel 3 de la arquitectura OSI) que son enviados por multicast, en esa información el Master informa de que está vivo, la prioridad (máximo 255), Interfaz Virtual, tiempo entre mensajes y los campos habituales de todo paquete IP.

La teoría nos dice que, en la habitual Alta Disponibilidad con 2 dispositivos 1 estará UP (Master) y el otro Down (Slave). Si lo pensamos bien eso implicaría tener 1 máquina comprada, pagada, mantenida, etc. sin sacarle rendimiento alguno en el 99.9% del tiempo (se presupone). ¿Cómo explotar mejor este protocolo, conseguir Alta Disponibilidad y no tener máquinas ociosas? Esto es lo que en el negocio se llama como Alta Disponiblidad Activo – Activo, que viene a significar que ambos Firewall se encontrarán trabajando a unos niveles de carga estimados en un 50%, de esta forma si uno de ellos falla, se colapsa, es atacado o le ocurre cualquier mal que os podáis imaginar, el otro podrá asumir el servicio sin verse sobrepasado (50 + 50 = “100”).

Si bien esta redundancia es virtual en muchos casos (1 Firewall físico, 2 virtuales) suele venir apoyada por un balanceador que se ocupará de distribuir las peticiones a cada uno de los Firewall. Ni que decir tiene que las políticas de seguridad deben ser las mismas en ambos dispositivos, idem con el protocolo de enrutamiento (RIPv2 es una buena opción).

Ahora bien, si queremos llegar un poco más lejos y especializar estos dispositivos podemos usar el modo pasivo / activo. Esto es, por defecto ciertos servicios irán a la máquina FW1, y por ejemplo las peticiones al SQL Server irán al FW2, el balanceador estará configurado de esta forma, en caso de que la petición no esté especificada irá alternándose de uno a otro. Ahora bien, ¿y si FW2 falla?, no pasa nada, cuando FW1 se entere (que será exactamente cuando el tiempo de refresco expire sin novedad) comenzará a asumir las peticiones SQL Server y –si todo funciona como debería- asumirá la carga de ese servicio (u otros) hasta que FW2 se recupere, es lo que se llama Firewall Sync, las 2 máquinas conocerán en todo momento como está la otra, se podrán intercambiar las peticiones según el estado del tráfico, conocerán las rutas de encaminamiento, etc. etc.

Ni que decir tiene que estas soluciones, si los estudios de rendimiento / capacidad son acertados, desde el punto de vista de la seguridad pueden ser muy buenas, y del negocio podrá proporcionarnos confianza para comprometernos con SLAs del 99.9%.

Salu2!!