[Dr.WoW] [No.47] Descripción general de Hot Standby

75 0 0 0

1 Implementación de dispositivos duales que mejora la disponibilidad de la red

El desarrollo dinámico del trabajo móvil, las compras en línea, la mensajería instantánea, la financiación de Internet, la educación en línea y otros servicios de red similares ha sido acompañado por un aumento implacable tanto en el número como en la importancia de los servicios en las redes. Por lo tanto, la transmisión de red ininterrumpida se ha convertido en un desafío en la necesidad urgente de resolución.

En el lado izquierdo de la Figura 1-1, se ha implementado un firewall en la salida de una red empresarial para reenviar todo el tráfico entre la intranet y una externa. Si el firewall falla, esto resultaría en la separación completa del tráfico entre la intranet y la red externa. Por lo tanto, si solo se usa un dispositivo en una posición clave de la red, debemos aceptar el riesgo de una interrupción de la red debido a un solo punto de falla, independientemente de cuán confiable sea el dispositivo.

Por lo tanto, cuando diseñamos una arquitectura de red, normalmente implementamos dos (más) o más dispositivos en posiciones clave de la red para mejorar la confiabilidad de la red. En el lado derecho de la Figura 1-1, podemos ver que cuando un firewall falla, el tráfico se reenviará a través del otro firewall.

Figura 1-1 Implementación de doble dispositivo que mejora la confiabilidad de la red

014051qolo5blbtl7456dw.png?image.png

2 Solo debe considerarse la conmutación por error de enrutamiento en las implementaciones de routers dobles

Si utiliza dispositivos de red tradicionales (como routers o switches de Capa 3), todo lo que debe hacerse para garantizar un servicio confiable es configurar la conmutación por error de enrutamiento en dos dispositivos. Esto se debe a que los routers y switches ordinarios no registran el estado de intercambio de paquetes y la información a nivel de aplicación, y simplemente envían paquetes de acuerdo con sus tablas de enrutamiento. A continuación se proporciona un ejemplo para ilustrar esto.

Como se muestra en la Figura 1-2, OSPF se ejecuta en los dos routers (R1 y R2) y R3 y R4. En circunstancias normales, debido a que el costo OSPF predeterminado de la interfaz de Ethernet es 1, desde la perspectiva de R3, el costo del enlace en el que R1 está posicionado (R3 -> R1 -> R4 -> servidor FTP) es 3. Y, porque He configurado el costo OSPF como 10 para las interfaces en el enlace R2 (R3 -> R2 -> R4 -> servidor FTP), desde la perspectiva de R3, el costo del enlace en el que R2 está posicionado es 21. Como tráfico solo se reenviará a través del enlace con el menor costo, el tráfico entre el cliente FTP y el servidor solo se reenviará a través de R1.

Figura 1-2 Tráfico reenviado a través del enlace con el menor costo de enrutamiento

014103h17d0qt774qydftq.png?image.png

Como OSPF solo elegirá agregar las rutas más óptimas a la tabla de enrutamiento, solo podemos ver las rutas con un costo relativamente bajo en la tabla de enrutamiento de R3 (a continuación). Por lo tanto, los paquetes hacia/desde el servidor FTP (la dirección de destino es 1.1.1.0/24) solo se pueden reenviar a través de R1 (próximo salto: 10.1.1.2).

[R3] display ip routing-table

Route Flags: R - relay, D - download to fib

------------------------------------------------------------------------------

Routing Tables: Public

         Destinations : 11       Routes : 11      

 

Destination/Mask       Proto   Pre  Cost    Flags NextHop         Interface

 

        1.1.1.0/24  OSPF    10   3           D   10.1.1.2        Ethernet0/0/0

       10.1.1.0/24    Direct  0    0           D   10.1.1.1        Ethernet0/0/0

       10.1.1.1/32    Direct  0    0           D   127.0.0.1       Ethernet0/0/0

       10.1.2.0/24    Direct  0    0           D   10.1.2.1        Ethernet0/0/1

       10.1.2.1/32    Direct  0    0           D   127.0.0.1       Ethernet0/0/1

       10.1.3.0/24    OSPF    10   2           D   10.1.1.2        Ethernet0/0/0

       10.1.4.0/24    OSPF    10   12          D   10.1.1.2        Ethernet0/0/0

      127.0.0.0/8     Direct  0    0           D   127.0.0.1       InLoopBack0

      127.0.0.1/32    Direct  0    0           D   127.0.0.1       InLoopBack0

    192.168.1.0/24    Direct  0    0           D   192.168.1.1     GigabitEthernet0/0/0

    192.168.1.1/32    Direct  0    0           D   127.0.0.1       GigabitEthernet0/0/0

 

Como se muestra en la Figura 1-3, cuando R1 falla, el costo del enlace en el que R1 está posicionado se vuelve infinitamente grande, mientras que para R3 el costo del enlace de R2 sigue siendo 21. En este momento, las rutas de la red serán convergentes, y el tráfico se reenviará a R2. El tiempo requerido para que el tráfico cambie de R1 a R2 es el tiempo de convergencia de enrutamiento de la red. Si el tiempo de convergencia de enrutamiento es relativamente corto, las transmisiones de tráfico no se interrumpirán.

Figura 1-3 Conmutación por error de enrutamiento que garantiza servicios ininterrumpidos

014118l5jbhmj99grl3428.png?image.png

De la tabla de enrutamiento en R3 a continuación, podemos aprender que cuando ocurre una falla en la interfaz Eth0/0/1 de R1, los paquetes hacia/desde el servidor FTP (la dirección de destino es 1.1.1.0/24) solo pueden reenviarse a través de R2 (siguiente salto: 10.1.2.2).

  [R3] display ip routing-table

Route Flags: R - relay, D - download to fib

------------------------------------------------------------------------------

Routing Tables: Public

         Destinations : 10       Routes : 10      

 

Destination/Mask       Proto   Pre  Cost    Flags NextHop         Interface

 

1.1.1.0/24      OSPF    10   21          D   10.1.2.2        Ethernet0/0/1

       10.1.1.0/24    Direct  0    0           D   10.1.1.1        Ethernet0/0/0

       10.1.1.1/32    Direct  0    0           D   127.0.0.1       Ethernet0/0/0

       10.1.2.0/24    Direct  0    0           D   10.1.2.1        Ethernet0/0/1

       10.1.2.1/32    Direct  0    0           D   127.0.0.1       Ethernet0/0/1

       10.1.4.0/24    OSPF    10   20          D   10.1.2.2        Ethernet0/0/1

      127.0.0.0/8     Direct  0    0           D   127.0.0.1       InLoopBack0

      127.0.0.1/32    Direct  0    0           D   127.0.0.1       InLoopBack0

    192.168.1.0/24    Direct  0    0           D   192.168.1.1     GigabitEthernet0/0/0

    192.168.1.1/32    Direct  0    0           D   127.0.0.1       GigabitEthernet0/0/0

3 La conmutación por error de sesión también debe considerarse en implementaciones de firewall dual

Todo cambia cuando reemplazamos un dispositivo de red tradicional con un firewall de inspección de estado. Revisemos el contenido que analizamos en "Inspección de estado y mecanismo de sesión": los firewalls de inspección de estado inspeccionan solo el primer paquete de un flujo y establecemos una sesión para registrar la información de estado de los paquetes (incluida la dirección IP de origen, el puerto de origen, la dirección IP de destino, puerto de destino, protocolo, etc.). Los paquetes subsiguientes en este flujo de datos deben coincidir con una sesión que reenviará el firewall.

A continuación, daremos un ejemplo para ilustrar esto: dos servidores de seguridad (FW1 y FW2) están implementados en una red. OSPF se ejecuta en los dos firewalls y R1 y R2. Como se muestra en el lado izquierdo de la Figura 1-4, en circunstancias normales, como el costo OSPF del enlace en el que se encuentra FW1 es relativamente bajo, los paquetes se reenviarán a través de FW1. Se establecerá una sesión en FW1, y todos los paquetes subsiguientes coincidirán con la sesión y se reenviarán.

El lado derecho de la Figura 1-4 muestra que cuando FW1 falla, el tráfico se dirigirá a FW2 según la información de enrutamiento de los dispositivos ascendentes y descendentes. Sin embargo, como no hay sesión en FW2, los paquetes serán descartados por FW2, lo que provocará la interrupción del servicio. En este momento, el usuario debe reiniciar su solicitud de acceso (por ejemplo, mediante la descarga del FTP) y activar FW2 para restablecer una sesión antes de que el servicio del usuario pueda continuar.

Figura 1-4 La conmutación por error de sesión también debe considerarse en la implementación de firewall dual

014131q299qn3y922iol8y.png?image.png

Existe una sesión en FW1, como se muestra a continuación:

[FW1] display firewall session table

 Current Total Sessions : 1

  ftp  VPN:public --> public 192.168.1.10:2050-->1.1.1.10:21

No existe sesión en FW2, como se muestra a continuación:

[FW2] display firewall session table

 Current Total Sessions :0

 

4 Hot Standby resolviendo el problema con la conmutación por error de sesión de Firewall

Entonces, ¿cómo podemos resolver este problema logrando la conmutación por error de sesión para garantizar la continuidad del servicio después de la conmutación activa/en espera entre los dos firewalls? Aquí, la función de hot standby del firewall ¡te da una mano!

Como se muestra en el lado izquierdo de la Figura 1-5, la característica más importante de la función de  hot standby del firewall es negociar estados activos/en espera y sincronizar información importante de estado y configuración, incluida la sesión y la tabla de mapa de servidor, entre los dos firewalls a través del canal de failover (enlace heartbeat). Después de habilitar la función de espera activa, uno de los dos firewalls se convertirá en el dispositivo principal y el otro en el dispositivo de respaldo según la configuración del administrador. El firewall que se convierte en el dispositivo principal (FW1) manejará el tráfico y sincronizará la información importante de configuración y estado, incluida la información de la sesión y la tabla de mapa del servidor con el dispositivo de respaldo (FW2) a través del enlace de latido. El firewall que se convierte en el dispositivo de respaldo (FW2) no manejará el tráfico y solo recibe la información de estado y configuración del dispositivo primario (FW1) a través del canal de conmutación por error.

Como se muestra en el lado derecho de la Figura 1-5, cuando falla el enlace donde reside el dispositivo principal FW1, los dos firewalls usarán el canal de conmutación por error para intercambiar paquetes y renegociar sus estados activos/en espera. En este momento, FW2 negociará para convertirse en el nuevo dispositivo primario y manejará el tráfico, mientras que FW1 negociará para convertirse en el dispositivo de respaldo y no manejará el tráfico. Al mismo tiempo, el tráfico de servicio será redirigido al nuevo dispositivo primario (FW2) por los dispositivos ascendentes y descendentes. Como FW2 ya recibió la información de respaldo del dispositivo principal (como la información de sesión y configuración) cuando sirvió como dispositivo de respaldo, los paquetes de servicio coincidirán con la sesión y se reenviarán.

La copia de seguridad de la información de enrutamiento, sesión y configuración garantiza que el dispositivo de copia de seguridad FW2 reemplazará con éxito al dispositivo primario original FW1, evitando así la interrupción del servicio.

Figura 1-5 Modo de espera en caliente que garantiza la continuidad del servicio

014144i9j8226v2q4q2k0x.png?image.png

Hay una sesión en FW1, como se muestra a continuación:

[FW1]display firewall session table

 Current Total Sessions : 1

  ftp  VPN:public --> public 192.168.1.10:2050-->1.1.1.10:21

 

También hay una sesión en FW2, como se muestra a continuación:

[FW2]display firewall session table

 Current Total Sessions : 1

  ftp  VPN:public --> public 192.168.1.10:2050-->1.1.1.10:21

 

El método introducido anteriormente es el método de conmutación por error activo/en espera de hot standby. En los escenarios típicos de conmutación por error activo/en espera, el dispositivo de respaldo no maneja el tráfico de servicio y se encuentra en estado inactivo. Si no desea que el dispositivo que ha comprado esté inactivo, o si hay demasiado tráfico para que lo maneje un dispositivo, podemos usar el método de carga compartida de hot standby.

Como se muestra en la Figura 1-6, en un escenario de carga compartida, ambos firewalls son dispositivos primarios, y cada uno establece sesiones y maneja el tráfico de servicio. Al mismo tiempo, los dos firewalls también sirven como dispositivos de respaldo y reciben la sesión de respaldo y la información de configuración del otro. Como se ve en el lado derecho de la Figura 1-6, cuando uno de estos firewalls falla, el otro firewall manejará todo el tráfico de servicio. Como se respalda la información de la sesión de estos dos firewalls, todos los paquetes de servicio subsiguientes pueden coincidir con una sesión en cualquiera de los firewalls y reenviarse, evitando la interrupción del servicio.

Figura 1-6 Método de carga compartida de hot standby

014157mkqxxxx19xycqrry.png?image.png

Hay sesiones FTP y HTTP en FW1, como se muestra a continuación:

[FW1]display firewall session table

 

 Current Total Sessions : 2

  ftp  VPN:public --> public 192.168.1.10:2050-->1.1.1.10:21

  http VPN:public --> public 192.168.1.20:2080-->1.1.1.20:80

También hay sesiones FTP y HTTP en FW2, como se muestra a continuación:

[FW2]display firewall session table

 

 Current Total Sessions : 2

  ftp  VPN:public --> public 192.168.1.10:2050-->1.1.1.10:21

  http VPN:public --> public 192.168.1.20:2080-->1.1.1.20:80

5 Resumen

Para mejorar la confiabilidad de la red y evitar un solo punto de fallas, necesitamos implementar dos dispositivos de red en los nodos clave de la red. Si estos dispositivos son routers o switches, simplemente podemos configurar la conmutación por error de enrutamiento. Si estos dispositivos son cortafuegos, también debemos proporcionar una conmutación por error para la información de estado (como la tabla de sesión, etc.) entre los firewalls.

La función de hot standby del firewall proporciona un canal especial de conmutación por error utilizado en la negociación de estados activos/en espera entre dos firewalls y en el suministro de información de estado de respaldo sobre sesiones, etc. La espera en caliente incluye escenarios de conmutación por error activa/en espera y uso compartido de la carga. La conmutación por error activa/en espera se refiere a que el dispositivo principal maneje el tráfico, con el dispositivo de respaldo inactivo; cuando ocurre una falla en la (s) interfaz (es) del dispositivo primario, el enlace o el dispositivo completo, el dispositivo de respaldo cambiará al dispositivo primario y reemplazará al dispositivo primario en la administración de los servicios. La carga compartida también puede denominarse "activo/en espera complementario", ya que se trata de dos dispositivos que manejan servicios simultáneamente. Cuando un dispositivo falla, el otro dispositi****sumirá inmediatamente sus servicios, garantizando que no haya interrupción de los servicios que se reenviaron originalmente a través de este dispositivo.


  • x
  • convención:

Responder

Responder
Debe iniciar sesión para responder la publicación Inicio de sesión | Registrarse

Aviso Aviso: Para garantizar sus legítimos derechos e intereses, la comunidad y los terceros no publicarán contenido que pueda generar riesgos legales a las partes, por ejemplo, pornografía, contenido político, contenido sobre juego, consumo y tráfico de drogas, así como contenido que viole los derechos de propiedad intelectual de terceros, por ejemplo, secretos comerciales, marcas, derechos de autor, patentes y privacidad personal. No comparta su cuenta ni su contraseña con terceros. Todas las operaciones realizadas usando su cuenta se considerarán como sus acciones y todas las consecuencias que estas acciones generen serán responsabilidad suya. Para obtener información detallada, consulte la “ Política de privacidad.”
Si el botón para adjuntar no está disponible, actualice Adobe Flash Player con la versión más reciente
¡Ingresa y disfruta de todos los beneficios para los miembros!

¡Ingresa y disfruta de todos los beneficios para los miembros!

Aterrizaje