Aunque hay otras soluciones para la implementación de un firewall con capacidades de router en el mundillo del software libre y que además sea código abierto, hay pocos que presentan el HA de clase empresarial como opción. Debido a que pfSense es una de las soluciones más expandidas en nuestro territorio se presenta el siguiente tutorial para configurar su HA.
La High Availability (HA) o alta disponibilidad en pfSense se hace con la idea de tener un hardware de respaldo, ya que en caso de el firewall primario o alguno de sus enlaces falle pues el firewall secundario asume el role del primario, eliminando en nuestras empresas a los firewalls como punto único de fallo en la red.
Vamos a lo interesante entonces?
1- Laboratorio virtual
Para comprobar la configuración se realizará el siguiente laboratorio con el software GNS3:
2- Configuraciones de red
Configuración de red fw-romeo:
El objetivo del laboratorio es comprobar que en caso de que fw-romeo presente dificultades (pérdida de un enlace, sistema apagado por problemas de hardware…) fw-julieta asuma el role de hombre de la casa…
| NOTA: Este tutorial no abarca las configuraciones iniciales en pfSense. Se supone que ya fueron configuradas las direcciones IP de cada interfaz de red, así como las puertas de enlaces y la ruta predeterminada o rutas estáticas. También debe haberse creado una regla que permita todo le tráfico de entrada en la interfaz LAN y WAN, sólo para las pruebas del laboratorio. |
3- Reglas para HASYNC
Se crean las reglas recomendadas por pfSense en la interfaz de sincronización. A continuación, en fw1-romeo (para llegar: Firewall -> Rules -> HASYNC):
Ahora necesitamos crear un usuario que se va a encargar únicamente de la sincronización. En fw-romeo creamos el usuario “hasync” sin agregarle ninguna otra configuración, más allá de la por defecto. En el “fw1-primario” (para llegar: System -> Users manager-> Users):
5- Sincronización para la Alta Disponibilidad:
En el fw-romeo, se habilita la sincronización de estados, se especifica la interfaz de red por la cual se sincronizarán romeo y julieta, y se especifica la dirección IP de julieta (para llegar: System -> High Avail. Sync):
La siguiente sección de configuración para alta disponibilidad, sólo se hace en el “master” (fw-romeo). En ella se especifican nuevamente la dirección IP del cortafuego secundario (fw-julieta), así como el usuario y la contraseña que se usará para la sincronización (el usuario que previamente creamos: “hasync”). Se marcan todas las casillas disponibles, como opciones de sincronización:
Al dar Save se puede comprobar inmediatamente en los logs del sistema si se realizó con éxito la configuración (para llegar: Status –> System Logs):
Regla creada en fw-romeo solo para comprobar:
| Pequeña introducción teórica
Common Address Redundancy Protocol (CARP) fue creado por los desarrolladores de OpenBSD como una solución de redundancia abierta y gratuita para compartir direcciones IP entre un grupo de dispositivos de red. Ya existían soluciones similares, principalmente el estándar IETF para el Protocolo de redundancia de enrutador virtual (VRRP). Sin embargo, Cisco afirma que VRRP está cubierto por su patente sobre su Hot Standby Router Protocol (HSRP), y les dijo (¿o amenazó con?) a los desarrolladores de OpenBSD que haría cumplir su patente. Por lo tanto, los desarrolladores de OpenBSD crearon un nuevo protocolo abierto y gratuito para lograr esencialmente el mismo resultado sin infringir la patente de Cisco. CARP estuvo disponible en octubre de 2003 en OpenBSD, y más tarde también se agregó a FreeBSD. Una dirección IP virtual (VIP) de tipo CARP se comparte entre los nodos de un clúster. Un nodo es maestro y recibe tráfico para la dirección IP, y los otros nodos mantienen el estado de respaldo y monitorean los latidos (beats) para ver si necesitan asumir el rol de maestro si el maestro anterior falla. Dado que solo un miembro del clúster a la vez usa la dirección IP, no hay conflicto de direcciones IP para los VIP de CARP. Para que la conmutación por error funcione correctamente, es importante que el tráfico entrante que llega al clúster, como el tráfico ascendente enrutado, VPN, NAT, puerta de enlace de cliente local, solicitudes de DNS, etc., se envíe a un CARP VIP y para el tráfico saliente, como NAT saliente que se enviará desde un CARP VIP. Si el tráfico se dirige a un nodo directamente y no a un CARP VIP, otros nodos no captarán ese tráfico. CARP funciona de manera similar a VRRP y HSRP, e incluso puede entrar en conflicto en algunos casos. Los latidos se envían en cada interfaz que contiene un CARP VIP, un latido por VIP por interfaz. En los valores predeterminados de skew y base, un VIP envía latidos aproximadamente una vez por segundo. El skew determina qué nodo es el maestro en un momento dado. El nodo que transmita latidos más rápido asume el rol de maestro. Un valor de skew más alto hace que los latidos se transmitan con más retraso, por lo que un nodo con un skew más bajo será el maestro a menos que una red u otro problema provoque que los latidos se retrasen o se pierdan. Un clúster de alta disponibilidad que usa CARP necesita tres direcciones IP en cada subred junto con una subred separada sin usar para la interfaz de sincronización. Para las WAN, esto significa que se requiere una subred /29 o más grande para una configuración óptima. Cada nodo utiliza una dirección IP, más una dirección VIP CARP compartida para la conmutación por error. La interfaz de sincronización solo requiere una dirección IP por nodo. |
La idea básica es que ambos firewalls compartan una misma IP (virtual), así que el esquema de nuestra red se modifica un tanto:
Se crean las direcciones IP virtuales en fw-romeo para el protocolo CARP (para llegar: Firewall -> Virtual IPs):
Configuración de la WAN CARP VIP:
Status > CARP (failover) de fw-romeo en operación normal:
Si desconectamos el cable de red de la interfaz WAN del fw-romeo, fw-julieta debe de asumir el role de Master:
Si ambos firewalls presentan problemas de conectividad con el ISP, ambos asumen el role de master reanudando su role usual una vez alguno de los enlaces retorne.
8- Listo!!!
Y es todo! Ya tienen su firewall de backup por si el master se rompe!!!
Autores:
Me complace anunciar la creación de esta útil herramienta (SquidStats), para el análisis y monitoreo…
La inteligencia artificial está revolucionando las industrias al automatizar tareas, predecir patrones y permitiendo tomar…
Uno de los grandes retos al que nos podemos enfrentar cuando una aplicación crece, es…
Percona Monitoring and Management (PMM) es una herramienta de código abierto para la supervisión y…
Qué es lo que deseo hacer en este capítulo? Básicamente un sonoff, quiero encender/apagar las…
Hace algunos meses estoy escuchando hablar del proyecto Home Assistant (HA). En palabras literales del…
View Comments
Muy buen material me encuentro en proceso de aplicarlo en este instante muchas gracias.