Dispositivos de red centralizados en Google Cloud

Este documento está dirigido a los administradores de red, arquitectos de soluciones y profesionales de operaciones que ejecutan dispositivos de red centralizados en Google Cloud. Se requieren conocimientos de Compute Engine y las redes de nube privada virtual (VPC) en Google Cloud.

A menudo, los entornos corporativos necesitan enrutar el tráfico a Internet, a una red local, a otras nubes o incluso a otras partes del mismo entorno de nube mediante dispositivos virtuales basados en VM que supervisan, transforman o bloquear el tráfico.

En este documento, se revisan varias opciones de diseño que segmentan las redes de VPC y las interconectan con un dispositivo de red centralizado y virtualizado. Toda comunicación entre redes de VPC, redes locales e Internet se enruta a través del dispositivo centralizado. Puedes implementar un grupo de dispositivos redundantes para obtener una configuración de alta disponibilidad. Si no necesitas una disponibilidad alta, puedes implementar un solo dispositivo de red.

Enrutar el tráfico a través de dispositivos virtualizados puede ser un desafío. Por ejemplo, en Google Cloud, puedes reemplazar la ruta que dirige a Internet y redireccionar el tráfico a un conjunto de dispositivos virtualizados, pero no es posible cambiar el comportamiento de enrutamiento entre subredes dentro de una red de VCP. El enrutamiento entre subredes es automático y esas rutas no se pueden borrar ni anular.

Además, debido a la función fundamental de los dispositivos virtualizados, deben implementarse en configuraciones de alta disponibilidad. Esto es un desafío porque debe asegurarse de que todo el tráfico se enrute a través de uno de los dispositivos virtuales y que la conmutación por error entre estos dispositivos sea automática.

En el siguiente diagrama, se muestra un caso práctico típico de varias opciones de diseño que presentan un dispositivo de red centralizado y virtualizado.

Opciones de diseño con un dispositivo de red centralizado y virtualizado

En el diagrama anterior, se muestran las rutas de comunicación entre redes de VPC segmentadas, redes locales y la Internet, y cómo se enrutan a través del dispositivo de red centralizado y virtualizado.

Casos prácticos principales de esta arquitectura

Puedes usar esta arquitectura para varios casos prácticos que involucran dispositivos de red virtualizados a los que se enruta el tráfico. Ten en cuenta las siguientes consideraciones:

  • Muchos dispositivos de diferentes proveedores se pueden encontrar en Google Cloud Marketplace.
  • Algunos proveedores de dispositivos también ofrecen imágenes de Compute Engine personalizadas para Google Cloud en su sitio web o páginas de asistencia.
  • Puedes crear tus propios dispositivos virtualizados con software de red de código abierto. También puedes crear tus propias imágenes.

Los proveedores suelen proporcionar sus propias arquitecturas de referencia o guías de implementación para ejecutar sus dispositivos virtualizados en una configuración de alta disponibilidad. Para obtener más información, consulta el sitio web del proveedor.

Es posible que las arquitecturas de referencia del proveedor no abarquen todas las opciones que se presentan en este documento.

Es importante comprender las ventajas y desventajas de cada enfoque. Los casos prácticos típicos para dispositivos virtuales a los que se enruta el tráfico incluyen los siguientes:

Requisitos típicos

Los requisitos para enrutar el tráfico a través de dispositivos virtuales centralizados varían según el caso práctico específico. Sin embargo, los siguientes requisitos se suelen aplicar:

  • Todo el tráfico entre diferentes segmentos de red (por ejemplo, entornos administrados por equipos distintos, con requisitos de seguridad separados o entre diferentes módulos de una aplicación) deben pasar a través de un dispositivo virtual centralizado.
  • Todo el tráfico hacia o desde Internet hasta entornos seguros debe pasar mediante un dispositivo virtual centralizado.
  • Todo el tráfico hacia o desde sistemas locales conectados a Google Cloud a través de Cloud VPN, interconexión dedicada o interconexión de socio debe pasar por un dispositivo virtual centralizado.
  • Varios dispositivos virtuales centralizados se configuran en una configuración de alta disponibilidad en una configuración activa/activa o activa/pasiva. La conmutación por error ocurre automáticamente si surgen problemas de software o hardware en uno de los dispositivos virtualizados.
  • Todo el tráfico se enruta con estado, por lo que un flujo de tráfico entre dos máquinas virtuales siempre pasa por el mismo dispositivo virtual.
  • La capacidad de procesamiento del sistema de dispositivos virtuales centralizados es escalable mediante una de las dos opciones siguientes:
    • Escalar los dispositivos virtuales de forma vertical: aumentar la cantidad de núcleos o la cantidad de memoria en cada máquina virtual
    • Escalar los dispositivos virtuales de forma horizontal: aumentar la cantidad de dispositivos virtuales que se usan para distribuir el tráfico

Opciones de arquitectura

Existen varias opciones para lograr una alta disponibilidad entre dispositivos virtuales. También hay varias opciones para adjuntar segmentos de red a los dispositivos virtuales.

Puedes combinar cualquier opción para alta disponibilidad con cualquier opción a fin de adjuntar segmentos de red. Una opción común que se describe más adelante en este documento es una arquitectura que usa el intercambio de tráfico entre redes de VPC y el balanceador de cargas TCP/UDP interno como siguiente salto.

Elige una opción de alta disponibilidad

Puedes crear una arquitectura para lograr una alta disponibilidad del dispositivo central mediante el uso de varias instancias de las siguientes dos maneras:

  • Usa un balanceador de cargas TCP/UDP interno como el siguiente salto. En este enfoque, debes colocar varios dispositivos virtuales en un grupo de instancias administrado detrás de un balanceador de cargas TCP/UDP interno. Este balanceador de cargas se usa como el siguiente salto para una ruta predeterminada que reemplaza la ruta predeterminada en las redes de VPC conectadas a los dispositivos. Puedes usar dispositivos en una configuración activa/activa, que es la configuración estándar, o en una configuración activa/pasiva si usas la conmutación por error para el balanceo de cargas TCP/UDP interno. Las verificaciones de estado dirigen el tráfico a instancias en buen estado. Si deseas volver a crear dispositivos de forma automática por error, puedes usar la reparación automática. Si tu dispositivo usa interfaces de red múltiples, un balanceador de cargas TCP/UDP interno como siguiente salto puede tener backends en cualquier interfaz de red.

    En el siguiente diagrama, se muestra la topología del uso de un balanceador de cargas TCP/UDP interno como siguiente salto.

    La topología en la que se usa un balanceador de cargas TCP/UDP interno como el siguiente salto.

    En el diagrama anterior, se muestra un grupo de instancias administrado en una red de VPC, incluidos varios dispositivos virtuales que están detrás de un balanceador de cargas TCP/UDP interno, que actúa como el siguiente salto.

  • Usa el enrutamiento. En este enfoque, Google Cloud enruta el tráfico a los dispositivos virtuales desde las redes de VPC conectadas. Puedes usar dispositivos en una configuración activa/pasiva con rutas de prioridad diferentes, o en una configuración activa/activa cuando las rutas se configuran con la misma prioridad, en cuyo caso usas el enrutamiento de múltiples rutas de igual costo (ECMP) para distribuir el tráfico. Puedes usar la reparación automática para asegurarte de que los dispositivos se reinicien cuando estén en mal estado.

    En el siguiente diagrama, se muestra la topología del uso del enrutamiento.

    La topología del uso del enrutamiento

    En el diagrama anterior, se muestra un grupo de instancias administrado en una red de VPC con rutas de Google Cloud que dirigen el tráfico a los dispositivos virtuales desde la red de VPC conectada.

Para ambos enfoques, en una configuración activa/activa, el tráfico de retorno se puede enrutar a una máquina virtual diferente a la del tráfico saliente, a menos que uses NAT de origen para todo el tráfico. La asistencia para la sincronización de sesiones depende de la asistencia que ofrece el dispositivo virtual.

El uso de un balanceador de cargas TCP/UDP interno como el siguiente salto tiene las siguientes ventajas en comparación con el uso del enrutamiento de Google Cloud para una alta disponibilidad:

  • Las verificaciones de estado deciden dónde se reenvía el tráfico, lo que ayuda a garantizar que el tráfico se reenvíe solo a instancias en buen estado. Puedes exponer las verificaciones de estado para que se verifique la instancia local o se verifique una ruta de extremo a extremo.
  • Puedes ajustar los temporizadores de verificación de estado para una conmutación por error más rápida. Este enfoque proporciona los tiempos de conmutación por error más rápidos en caso de instancias en mal estado.

Sin embargo, usar un balanceador de cargas TCP/UDP interno como el siguiente salto tiene las siguientes desventajas:

  • Solo el tráfico de TCP y UDP puede pasar a través de un balanceador de cargas TCP/UDP interno. No se admiten otros protocolos, incluido el Protocolo de mensajes de control de Internet (ICMP).
  • El balanceador de cargas TCP/UDP interno como siguiente salto no admite etiquetas de red.

El uso de enrutamiento de Google Cloud tiene las siguientes ventajas:

  • Se admiten todos los protocolos, excepto el tráfico siempre bloqueado. No estás limitado a protocolos específicos.
  • Las rutas de Google Cloud se pueden limitar a ciertas etiquetas de red. Por ejemplo, las instancias de VM se pueden segmentar por región para usar diferentes conjuntos de dispositivos.

Usar el enrutamiento de Google Cloud tiene las siguientes desventajas:

  • Las verificaciones de estado borran y vuelven a crear instancias en mal estado del grupo de instancias. Sin embargo, el flujo de tráfico no cambia de inmediato en respuesta a las verificaciones de estado fallidas, ya que lleva tiempo borrar las instancias en mal estado y crear nuevas en buen estado. Esto genera tiempos de conmutación por error más lentos.
  • Si configuras temporizadores de verificación de estado para evitar la eliminación innecesaria y la recreación de instancias, esto provocará tiempos de conmutación por error más lentos.

Elige una opción para adjuntar segmentos de red

Debido a que no se puede anular el enrutamiento entre las subredes, los segmentos de red se implementan mediante redes de VPC independientes. El tráfico entre estas redes de VPC, a un entorno local y a Internet, se debe enrutar a través de los dispositivos centralizados. Ten en cuenta que todos estos segmentos de red pueden ser redes de VPC independientes o redes de VPC compartidas.

Existen varias opciones para adjuntar segmentos de red:

  • Interfaces de red múltiple. La forma más sencilla de conectar varias redes de VPC a través de un dispositivo virtual es mediante interfaces de red múltiples, con cada interfaz conectada a una de las redes de VPC. La conectividad local y de Internet se proporciona a través de una o dos interfaces de red separadas. Gracias a muchos productos NGFW, la conectividad a Internet se conecta a través de una interfaz marcada como no confiable en el software de NGFW.

    En el siguiente diagrama, se muestra esta topología.

    Topología de varias redes de VPC que se conectan a través de un dispositivo virtual mediante interfaces de red múltiples.

    En el diagrama anterior, se muestran varias redes de VPC que se conectan a través de un dispositivo virtual mediante varias interfaces de red. Cada interfaz se conecta a una de las redes de VPC. En el diagrama también se muestran las conexiones de Internet y locales a través de interfaces de red separadas, incluida una conexión a Internet a través de una interfaz no confiable.

  • Intercambio de tráfico entre redes de VPC. Esta topología usa el concepto de concentrador y radio junto con el intercambio de tráfico entre redes de VPC. Los segmentos de red se implementan como un conjunto de redes de VPC de radio que se intercambian con intercambio de tráfico entre redes de VPC con una red de VPC central, en la que el tráfico se enruta a través del grupo centralizado de dispositivos virtualizados. La ruta o rutas predeterminadas que apuntan al balanceador de cargas TCP/UDP interno como el siguiente salto, o los dispositivos virtuales directamente, se exportan como rutas personalizadas. a través del intercambio de tráfico entre redes de VPC. La conectividad local y de Internet se proporciona a través de una o dos interfaces de red separadas.

    En el siguiente diagrama, se muestra esta topología.

    Topología de la combinación de interfaces de red múltiples con el intercambio de tráfico entre redes de VPC

    En el diagrama anterior, se muestra un grupo centralizado de dispositivos virtualizados con interfaces de red múltiples conectadas a varias redes de VPC central. Cada red de VPC central se conecta a varias redes de VPC a través del intercambio de tráfico entre redes de VPC. El tráfico entre dos redes de VPC se enruta a través del grupo centralizado de dispositivos virtualizados.

  • Combinación de interfaces de red múltiples e intercambio de tráfico entre redes de VPC. Este enfoque combina las dos opciones anteriores para la escalabilidad adicional. Varias interfaces de red están conectadas a varias redes de VPC del concentrador, cada una de las cuales están conectadas a varias redes de VPC de radio a través del intercambio de tráfico entre redes de VPC. Para cada red de VPC de concentrador y radio, debes usar el mismo enfoque que se describe en el caso de intercambio de tráfico de red de VPC.

    En el siguiente diagrama, se muestra esta topología.

    Topología del enfoque de concentrador y radio combinado con el intercambio de tráfico entre redes de VPC.

    En el diagrama anterior, se muestra una red de VPC central adjunta a varias redes de VPC a través del intercambio de tráfico entre redes de VPC. El tráfico se enruta a través del grupo centralizado de dispositivos virtualizados con una interfaz de red en la red del concentrador.

El siguiente árbol de decisión puede ayudarlo a decidir cuál es el mejor enfoque para adjuntar segmentos de red.

Árbol de decisión para elegir el mejor enfoque a fin de adjuntar segmentos de red

El uso de interfaces de red múltiples (el primer enfoque que se presenta en los casos anteriores) es el enfoque más fácil de implementar.

Sin embargo, el uso de interfaces de red múltiples tiene las siguientes desventajas:

  • Tienes un límite de 8 interfaces de red por instancia de máquina virtual. Si usas una interfaz de red para la conectividad a Internet y otra para la conectividad local, puedes conectar solo 6 segmentos de redes en Google Cloud. Algunos dispositivos requieren una interfaz de administración adicional, lo que te limita a 5 segmentos de red.
  • No puedes agregar o quitar interfaces de red después de crear una instancia.

El uso del intercambio de tráfico entre redes de VPC tiene las siguientes ventajas:

Sin embargo, el uso del intercambio de tráfico entre redes de VPC tiene las siguientes desventajas:

  • Este enfoque es un poco más complejo que el enfoque que usa interfaces de red múltiples.
  • La cantidad de VPC que pueden conectarse aún está limitada en comparación con el enfoque combinado.

El uso del enfoque combinado (interfaces de red múltiples e intercambio de tráfico entre redes de VPC) tiene la siguiente ventaja:

  • Es el enfoque más escalable porque el límite es un producto del límite de las interfaces de red y el límite de conexiones de intercambio de tráfico de VPC. Por ejemplo, puedes conectar 6 redes de VPC de concentrador para separar interfaces de red, y cada interfaz tiene 25 redes de VPC de voz conectadas. Esto te da un límite de 150 redes de VPC que intercambian tráfico a través de un conjunto de dispositivos virtuales.

Sin embargo, este enfoque tiene la siguiente desventaja:

  • Es el enfoque más complejo de implementar.

Arquitecturas de ejemplo

A continuación, se presentan dos arquitecturas de ejemplo. En la primera arquitectura de ejemplo, se muestra cómo usar el balanceador de cargas TCP/UDP interno para una alta disponibilidad, combinado con el intercambio de tráfico entre redes de VPC para adjuntar segmentos de red. En el segundo ejemplo de arquitectura, un caso práctico especial, se muestra cómo enrutar el tráfico desde una sola red de VPC compartida en Google Cloud hacia un entorno local y hacia la Internet.

Arquitectura de ejemplo con intercambio de tráfico entre redes de VPC y balanceador de cargas TCP/UDP interno como siguiente salto

Esta arquitectura es un caso práctico típico para entornos empresariales, ya que usa el balanceador de cargas TCP/UDP interno para una alta disponibilidad, combinado con el intercambio de tráfico entre redes de VPC.

En el siguiente diagrama, se muestra la topología de esta arquitectura.

Topología para usar el intercambio de tráfico entre redes de VPC y el balanceador de cargas TCP/UDP interno como siguiente salto.

En el diagrama anterior, se muestra una red de VPC central y varias redes de VPC de voz que se intercambian con la red de VPC central mediante el intercambio de tráfico entre redes de VPC. La red de VPC del concentrador tiene 2 instancias de un dispositivo virtual en un grupo de instancias administrado detrás de un balanceador de cargas TCP/UDP interno. Una ruta estática predeterminada apunta al balanceador de cargas TCP/UDP interno como el siguiente salto. Esta ruta predeterminada estática se exporta a través del intercambio de tráfico de red de VPC mediante rutas personalizadas. Se borra la ruta predeterminada a la puerta de enlace de Internet en las redes de VPC de radio.

Puedes cumplir con los requisitos de las siguientes maneras:

  • La conectividad entre los radios se enruta de forma automática a través del firewall, porque el intercambio de tráfico entre redes de VPC no es transitivo y, por lo tanto, las redes de VPC de radio no pueden intercambiar datos de manera directa. Puedes configurar los dispositivos virtuales para establecer las condiciones y políticas en las que los radios pueden intercambiar tráfico.
  • La conectividad a Internet solo es posible a través de los dispositivos virtuales, ya que la ruta predeterminada a la puerta de enlace de Internet se quitó de las redes de VPC del radio. Los dispositivos virtuales tienen una ruta predeterminada a través de una interfaz de red separada, que se puede marcar como no confiable en el caso de un NGFW.
  • La conectividad a las redes locales se logra a través de una red de VPC de conectividad conectada al dispositivo virtual en una interfaz de red separada. Una conexión de Cloud VPN o Cloud Interconnect finaliza en esta red de VPC de conectividad.
  • La alta disponibilidad se logra mediante verificaciones de estado personalizadas en el balanceador de cargas interno. Puedes configurar dispositivos como activos/pasivos mediante la conmutación por error para el balanceo de cargas TCP/UDP interno. Esto ayuda a garantizar que el tráfico siempre fluya a través de un único dispositivo virtual.

Puedes usar esta arquitectura de ejemplo si la comunicación entre las diferentes redes de VPC es solo TCP/UDP. Es escalable hasta el límite de conexiones de intercambio de tráfico de red de VPC por red de VPC.

Para una implementación de muestra de esta arquitectura con una puerta de enlace NAT como el dispositivo virtual, consulta Implementa dispositivos centralizados basados en VM con el balanceador de cargas TCP/UDP interno como siguiente salto. Puedes usar el mismo patrón para implementar otros dispositivos virtuales, como se describe en la sección anterior de casos prácticos.

Caso práctico especial con una red de VPC compartida en Google Cloud

En un uso especial, ningún tráfico entre diferentes redes de VPC debe pasar a través de los dispositivos virtuales. En cambio, solo el tráfico de una sola red de VPC compartida se enruta hacia un entorno local y a Internet. Puedes implementar este caso práctico si usas cualquiera de las opciones de alta disponibilidad descritas antes en este documento, junto con una interfaz de red cada una, para conectividad a la red de VPC compartida, local y Google Cloud para ver sus detalles. Si deseas obtener visibilidad del tráfico entre subredes sin ejecutarlo a través de dispositivos centralizados, la duplicación de paquetes puede ser útil.

En el siguiente diagrama, se muestra esta topología.

Topología de caso práctico especial con una red de VPC compartida en Google Cloud

El diagrama anterior muestra el tráfico de una sola red de VPC compartida enrutada hacia una red local y hacia Internet a través de un grupo de dispositivos virtuales.

Implementación de una arquitectura con dispositivos virtuales

Si quieres implementar una arquitectura que usa dispositivos virtuales, elige una opción para alta disponibilidad y combínala con una opción para adjuntar segmentos de red.

Para las siguientes combinaciones de opciones, hay guías de implementación disponibles:

En los instructivos anteriores, se usan puertas de enlace NAT como caso práctico para el dispositivo, pero puedes adaptar la puerta de enlace mediante cualquiera de los otros casos prácticos.

Si quieres implementar un dispositivo de un socio de Google Cloud (por ejemplo, desde Cloud Marketplace), comunícate con tu proveedor de dispositivos o busca los lineamientos sobre el sitio web del proveedor cómo implementar sus dispositivos en Google Cloud.

¿Qué sigue?