Entradas Mensuales

Síguenos en:

Canal Oficial Telegram de elhacker.NET Grupo Facebook elhacker.NET Twitter elhacker.NET Canal Youtube elhacker.NET Comunidad Steam: Grupo elhacker.NET Mastodon

Entradas populares

PostHeaderIcon Establecer un clúster OPNsense HA (Alta Disponibilidad)

jueves, 9 de enero de 2025 | Publicado por el-brujo | Editar entrada

El cortafuegos gratuito de código abierto OPNsense puede configurarse como un cortafuegos redundante con conmutación automática por error. Este artículo muestra cómo configurar un clúster HA.


 ¿Qué es la alta disponibilidad?


La capacidad de un sistema para funcionar de forma continua sin experimentar una avería durante un tiempo determinado se conoce como alta disponibilidad (HA). La alta disponibilidad garantiza que un sistema cumple un nivel de rendimiento operativo predeterminado. Una referencia de disponibilidad popular, aunque difícil, en tecnología de la información (TI) es la llamada disponibilidad cinco-nueve, que denota que el sistema o producto es accesible el 99,999% del tiempo.

Los sistemas con alta disponibilidad (HA) se emplean en sectores y circunstancias en los que el tiempo de actividad del sistema es crucial. Los vehículos autónomos, los sistemas de control industrial, sanitario y militar son ejemplos de sistemas de alta disponibilidad en la práctica. Estos sistemas deben estar siempre operativos y listos para proteger la vida de las personas. Por ejemplo, el mal funcionamiento del sistema operativo de un vehículo autónomo durante su funcionamiento puede provocar un accidente que ponga en peligro la vida de sus ocupantes, de otros conductores, de peatones y de la propiedad.

Los sistemas de alta disponibilidad deben estar bien desarrollados y evaluados antes de ser utilizados. Es necesario que todos los componentes alcancen los criterios de disponibilidad especificados para planificar uno de estos sistemas. La capacidad de realizar copias de seguridad y conmutación por error de los datos es crucial para garantizar que los sistemas de alta disponibilidad alcancen sus objetivos de disponibilidad. Las tecnologías que elijan los diseñadores de sistemas para el acceso y almacenamiento de datos deben considerarse cuidadosamente.

Diferencias: ¿Alta disponibilidad frente a tolerancia a fallos?


La tolerancia a fallos contribuye a la alta disponibilidad, al igual que la RD. La capacidad de un sistema para resistir, predecir y reaccionar automáticamente ante fallos en su funcionamiento se conoce como tolerancia a fallos. La redundancia es necesaria para que un sistema tolerante a fallos reduzca las perturbaciones en caso de avería del hardware.

Las empresas de TI deben utilizar un enfoque N+1, N+2, 2N o 2N+1 para lograr la redundancia. Sea N el número de servidores, por ejemplo, necesarios para mantener la funcionalidad del sistema. En un modelo N+1 se necesita un servidor adicional además de todos los servidores necesarios para ejecutar el sistema. En un modelo 2N se necesitarían dos veces más servidores de los que suele requerir el sistema. Utilizar una estrategia 2N + 1 implica utilizar el doble de servidores de los necesarios más uno adicional. Gracias a estas medidas, los componentes de misión crítica tienen garantizada una copia de seguridad como mínimo.

Un sistema puede estar altamente disponible y, al mismo tiempo, no ser tolerante a fallos. Por ejemplo, el hipervisor puede intentar reiniciar la máquina virtual en el mismo clúster de hosts si un sistema de alta disponibilidad tiene dificultades para alojar la máquina virtual en un servidor de un clúster de nodos, pero el sistema no es tolerante a fallos. Esto probablemente funcionará si el problema está relacionado con el software. Sin embargo, reiniciar el clúster en el mismo clúster no resolverá el problema si el problema es el hardware del clúster, ya que la máquina virtual se aloja en el mismo clúster que funciona mal.

En el mismo escenario, un método tolerante a fallos probablemente implementaría una estrategia N+1 y reiniciaría la máquina virtual en un nuevo servidor en un clúster separado. Es más probable que se garantice un tiempo de inactividad cero con la tolerancia a fallos. Para garantizar que haya un duplicado del sistema completo en otro lugar para utilizarlo en caso de desastre, una estrategia de DR iría un paso más allá.

 Requisitos

 En este ejemplo, se utilizan dos LES compact 4L (cuatro puertos de red cada una en la parte posterior) para el clúster OPNsense HA.

Un cortafuegos OPNsense redundante requiere:

  • Dos máquinas cortafuegos, cada una con al menos tres puertos de red.
  • WAN: enlace ascendente con al menos tres direcciones IP disponibles (una dirección IP fija cada una para el cortafuegos 1 y el cortafuegos 2, así como una dirección IP virtual adicional para el maestro del cortafuegos).
  •  LAN: tres direcciones IP libres en la LAN (una dirección IP fija cada una para el Cortafuegos 1 y el Cortafuegos 2, así como una dirección IP virtual adicional para el Maestro del Cortafuegos).


Si los dos nodos de clúster OPNsense se ejecutan en máquinas virtuales, se debe permitir que las máquinas virtuales cambien las direcciones MAC. Esto es necesario para el uso del Protocolo Común de Redundancia de Direcciones (CARP).

 




Fundamentos

Las siguientes tecnologías se utilizan para un firewall de OPNsense redundante:

  • Protocolo de Redundancia de la Dirección Común (CARP):[4] Protocolo para proporcionar direcciones IP muy disponibles
    • Utiliza el protocolo IP 112 como VRRP.
    • Utilre paquetes multicast para proporcionar información estatal actualizada a otros equipos participantes en la red de clústeres.
  • pfsync:[5] Protocolo para replicar la información sobre el estado de las conexiones individuales de la red (sincronización de la Mesa Estatal).
    • Nota: Para que la información de estado se utilice correctamente en ambos cortafuegos, ambos cortafuegos deben utilizar las designaciones de interfaz idénticas para las redes configuradas. Por ejemplo, si la red interna (LAN) está conectada al cortafuegos 1 a través de la interfaz igb0, igb0 también debe asignarse a la LAN en el firewall 2. Si hay dos cortafuegos diferentes con diferentes tarjetas de red (y por lo tanto nombres de interfaz), se puede configurar como un GAL de trabajo.
    • Para pfSync, se recomienda utilizar una interfaz dedicada en ambos cortafuegos. Esto aumenta la inyección y el rendimiento del estado.
  • XMLRPC sincronizado : Sincronización de la configuración del cortafut omparas.

Configuración

Recomendación: Al establecer un nuevo cortafuegos, primero configure la red de clúster. Después de configurar el cúmulo HA, comience por configurar nuevas configuraciones de cortafuegos (reglas de firewall, servicios, ...). Este procedimiento reduce posibles fuentes de error.

Para establecer un firewall de OPNense redundante, hay que tomar las siguientes medidas:[6]

  1. Instalación de OPNsense en ambos equipos del firewall
  2. Configuración de las direcciones IP estáticas en firewall 1 y firewall 2. Si solo se usa IPv4, le recomendamos Desactivar IPv6 en ambos cortafuegos. En este ejemplo, utilizamos las siguientes direcciones IP:
    • igb0 (LAN): 192.168.1.251/24 (Firewall 1); 192.168.1.252/24 (Firewall 2)
    • igb1 (WAN): 192.168.0.251/24 (Firewall 1); 192.168.0.252/24 (Firewall 2)
    • igb2 (Sync): 10.0.0.1/24 (Firewall 1); 10.0.0.2/24 (Firewall 2). Los detalles sobre la configuración de esta interfaz de red adicional se documentan en Agregar artículo OPNsense Interface.
  3. Desactivar el servidor DHCP en ambos cortafuegos (bajo Servicios DHCPv4 - [LAN]).
  4. Crear reglas de cortafuegos en ambos cortafuegos. En la Reglas del cortafuegos Se requieren las siguientes reglas para las tres interfaces:
    • LAN: Permitir paquetes CARP (Protocolo de selección: CARP)Protocol: CARP
    • WAN: Permitir paquetes CARP (Protocolo de selección: CARP)
    • PFSYNC: porque es una conexión directa por cable, permitiendo todo tráfico de red.


     Configurar IPs virtuales:

    • En Firewall 1 (Maestro) en Interfaces - Configuración de IP virtual haciendo clic en Añadir Crear una nueva IP WAN virtual con los siguientes parámetros:
      • Moda: CARP
      • Interfaz: WAN
      • Dirección: 192.168.0.253/24
      • Contraseña virtual: Utilice una contraseña aletoria con 30 caracteres. Por ejemplo, puede crear esto en una máquina Linux o FreeBSD usando el siguiente comando en la línea de comandos:[7]
        cat /dev/random | hexdump -n 30| cut -d \  -f 2-| head -n 1 | tr -d " "
      • Grupo VHID: 3
      • Frecuencia de la publicidad: Base 1 / Skew 0
      • Descripción: Virtual WAN IP
    • En Firewall 1 (Master) haciendo clic en Añadir crear una nueva IP virtual LAN con los siguientes parámetros:
      • Moda: CARP
      • Interfaz: LAN
      • Dirección: 192.168.1.1/24
      • Contraseña virtual: Utilice la contraseña aleatoria con 30 caracteres.
      • VHID Group: 1 (este número se utiliza como último octeto de la dirección MAC para la dirección IP virtual, en este ejemplo la dirección MAC es 00:00:5e:00:01:03)[8]
      • Frecuencia de la publicidad: Base 1 / Skew 0


       

      • Descripción: IP virtual de LAN
      1. Configurando NAT saliente. En la  NAT - Outbound la opción Generación de reglas de NAT salientes manuales y haciendo clic en Añadir Crear una nueva regla:
        • Interfaz: WAN
        • Dirección de la Fuente: LAN net
        • Traducción / objetivo: 192.168.0.253 (Virtual WAN IP)
      2. Configuración opcional Servidor DHCP. En ambos cortafuegos Servicios DHCPv4 Seleccione los siguientes parámetros:
        • Servidor DNS: 192.168.1.1 (corresponde a la IP virtual LAN)
        • Gateway: 192.168.1.1 (corresponde a la IP virtual LAN)
        • Fallilover peer IP: 192.168.1.252 (IP del otro cortafumelos), cita en firewall 2 aquí 192.168.1.251 (IP del primer cortafuneros)

       Configura pfSync y HA sincronización (xmlrpc) a Firewall 1. En la Sistema de alta disponibilidad. Configuración Seleccione la configuración siguiente: 

       

      • Estados sincronizar:
      • Interfaz sincronizar: PFSYNC
      • Sincronizar Peer IP: 10.0.0.2 (cite la dirección IP de la interfaz PFSYNC de Firewall 2 aquí)
      • Sincronizar Config a IP: 10.0.0.2
      • Sistema remoto Nombre de usuario: root
      • Contraseña del sistema remoto: (Contactar contraseña de Firewall 2)
      • Seleccione qué servicios a sincronizar. En este ejemplo:
        • Dashboard:
        • Reglas de cortafuegos:
        • Aliases:
        • NAT:
        • DHCPD:
        • IPs virtuales:
        1. Configur pfSync al cortafuegos 2. En la Sistema de alta disponibilidad. Configuración Seleccione la configuración siguiente:
          • Estados sincronizar:
          • Desactivar el pretención: esta opción deja desactivada (esto significa que preemt permanece activo). Esto asegura que si una sola conexión de red falla (por ejemplo, se trata de una conexión única (por ejemplo. La conexión WAN del cortafuego 1) todas las direcciones IP (WAN y LAN en este ejemplo) se trasladan al segundo cortafuegos.[9]
          • Interfaz sincronizar: PFSYNC
          • Sincronizar Peer IP: 10.0.0.1 (cite la dirección IP de la interfaz PFSYNC de Firewall 1 aquí)
          • Nota: En Firewall 2 no configur la sincronización de HA (xmlrpc). La configuración posterior (por ejemplo, las reglas del cortafuegos, etc.) se lleva a cabo exclusivamente en el cortafuegos 1 y por lo tanto sincronizados con el cortafuegos 2.
        2. En Firewall 1 en el salpicadero, agregue el widget CARP haciendo clic en el widget, seleccionando CARP y luego haciendo clic en Guardar configuración.
        3. Finalmente, llevar a cabo un reinicio de ambos sistemas.

        Nota: Si otros servicios (por ejemplo. OpenVPN) debe configurarse primero para permitir la sincronización de la configuración en System - Alta Disponibilidad - Ajustes. Al configurar el servicio, la IP WAN Virtual debe ser seleccionada como la interfaz para el servicio.


Prueba de fallo


Un cliente Linux conectado en la LAN de prueba muestra la dirección MAC virtual 00:00:5e:00:01:03 para la puerta de enlace predeterminada 192.168.1.1 al consultar la caché ARP mediante «ip n»:

wfischer@ubuntu:~$ ip n
192.168.1.1 dev eth0 lladdr 00:00:5e:00:01:03 REACHABLE


Ahora, para realizar pruebas en el cortafuegos 1 (maestro anterior), se desconecta el cable de red del puerto WAN (igb1). Las conexiones del cliente Linux a Internet (por ejemplo, una conexión SSH o una conexión de escritorio virtual) se mantienen.

La siguiente salida muestra las entradas de registro en /var/log/system.log, así como los valores de sysctl de net.inet.carp al cortafuegos 1. La interfaz igb1 cambia al estado «interfaz inactiva» y, a continuación, el «Contador de demora» se establece en 240:
 
root@fw1:~ # clog -f /var/log/system.log
Aug 26 11:39:17 fw1 kernel: carp: 1@igb1: MASTER -> INIT (hardware interface down)
Aug 26 11:39:17 fw1 kernel: carp: demoted by 240 to 240 (interface down)
Aug 26 11:39:17 fw1 kernel: igb1: link state changed to DOWN
Aug 26 11:39:17 fw1 kernel: carp: 3@igb0: MASTER -> BACKUP (more frequent advertisement received)
Aug 26 11:39:17 fw1 kernel: ifa_maintain_loopback_route: deletion failed for interface igb0: 3
Aug 26 11:39:18 fw1 opnsense: /usr/local/etc/rc.linkup: DEVD Ethernet detached event for wan
Aug 26 11:39:18 fw1 opnsense: /usr/local/etc/rc.syshook.d/carp/20-openvpn:
                    Carp cluster member "192.168.1.1 - Virtual LAN IP (3@igb0)" has resumed the state "BACKUP" for vhid 3
[Ctrl]+[c]

root@fw1:~ # sysctl net.inet.carp
net.inet.carp.ifdown_demotion_factor: 240
net.inet.carp.senderr_demotion_factor: 240
net.inet.carp.demotion: 240
net.inet.carp.log: 1
net.inet.carp.preempt: 1
net.inet.carp.allow: 1

La siguiente salida muestra las entradas de registro en /var/log/system.log y los valores sysctl de net.inet.carp en el cortafuegos 2:
root@fw2:~ # clog -f /var/log/system.log
Aug 26 11:39:17 fw2 kernel: carp: 3@igb0: BACKUP -> MASTER (preempting a slower master)
Aug 26 11:39:18 fw2 opnsense: /usr/local/etc/rc.syshook.d/carp/20-openvpn:
                    Carp cluster member "192.168.1.1 - Virtual LAN IP (3@igb0)" has resumed the state "MASTER" for vhid 3
Aug 26 11:39:19 fw2 kernel: carp: 1@igb1: BACKUP -> MASTER (master timed out)
Aug 26 11:39:20 fw2 opnsense: /usr/local/etc/rc.syshook.d/carp/20-openvpn:
                    Carp cluster member "10.1.102.253 - Virtual WAN IP (1@igb1)" has resumed the state "MASTER" for vhid 1
[Ctrl]+[c]

root@fw2:~ # sysctl net.inet.carp
net.inet.carp.ifdown_demotion_factor: 240
net.inet.carp.senderr_demotion_factor: 240
net.inet.carp.demotion: 0
net.inet.carp.log: 1
net.inet.carp.preempt: 1
net.inet.carp.allow: 1

 

 

Actualización de cortafuegos

Con un clúster HA de cortafuegos activo/pasivo redundante, el tiempo de inactividad del cortafuegos en una actualización de cortafuegos puede minimizarse drásticamente:

  1. Actualiza el firewall de respaldo (Firewall 2) y espera hasta que esté de vuelta en línea.
  2. Seleccione el elemento Introduzca el modo de mantenimiento de CARP persistente en el cortafuegos primario bajo Firewall.
  3. Una vez que Firewall 2 se haya convertido en MASTER, compruebe si todos los servicios como DHCP, VPN, NAT continúan funcionando correctamente después de la actualización. En el improbable caso de que la actualización del cortafuegos causara problemas con ciertos servicios, puede volver al cortafuegos original antes de instalar la actualización allí.
  4. Si todos los servicios funcionan como se desea después de la actualización, actualice Firewall 1 y seleccione entonces Deja la moda de mantenimiento de CARP persistente.
    • Nota para OPNsense 19.7.3: Si se ha reiniciado un reinicio automático del Firewall 1 durante la actualización, se debe realizar un reinicio de Firewall 1 después de hacer clic en el modo de mantenimiento de CARP Persistente, de modo que los valores de advskew a Firewall 1 se configuran de nuevo a 0.[10] Este fallo se fijó con OPNsense versión 19.7.4.[11][12]

FAQs y análisis de errores

  • Pregunta: Cuando una conexión de red única es fallida por el Firewall 1 (por ejemplo, la conexión WAN), sólo la IP WAN se mueve al Firewall 2, pero no a la IP LAN. Cómo puedo arreglar este problema?
    1. Comaccionar si la opción Disable prevant está deshabilitada en ambos cortafuegos en Ajustes de Disponibilidad Alta del Sistema.
    2. Comae los valores de advbase y advskew en la línea de comandos en ambos firewall ifconfig y grep carp carp
      • advbase: debe tener el valor "1" en todas las interfaces CARP en Firewall 1 y Firewall 2
      • advskew: debe tener el valor "0" en todas las interfaces CARP en firewall 1 y el valor "100" en todas las interfaces CARP en Firewall 2.

 

Fuentes:

https://www.thomas-krenn.com/en/wiki/OPNsense_HA_Cluster_configuration


Etiquetas: , , , , , ,

0 comentarios :

Publicar un comentario

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.