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.

Los entornos corporativos a menudo necesitan enrutar el tráfico a Internet, a una red local, a otras nubes o incluso a otras partes del mismo entorno de nube a través de dispositivos virtualizados basados en VM que supervisan, transforman, o bloquear el tráfico.

En este documento, se analizarán varias opciones de diseño que segmentan las redes de VPC y las interconectan con un dispositivo de red virtualizado y centralizado. Todas las comunicaciones entre redes de VPC, redes locales e Internet se enrutan 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 alta disponibilidad, puedes implementar un solo dispositivo de red.

Enrutar de tráfico a través de dispositivos virtualizados puede ser un desafío. En Google Cloud, por ejemplo, puedes reemplazar la ruta que apunta a Internet y redireccionar el tráfico a un conjunto de dispositivos virtualizados, pero no es posible cambiar el comportamiento de enrutamiento entre las subredes dentro de una red de VPC. 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 con 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 de uso típico de varias opciones de diseño que presentan un dispositivo de red centralizado y virtualizado.

Opciones de diseño que cuentan 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.

Principales casos de uso de esta arquitectura

Puedes usar esta arquitectura para varios casos de uso 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 de uso 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 de uso específico. Sin embargo, se suelen aplicar los siguientes requisitos:

  • 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 a través de 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 establecen 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 los dispositivos virtuales. También existen varias opciones para adjuntar segmentos de red a los dispositivos virtuales.

Puedes combinar cualquier opción de alta disponibilidad con cualquier opción a fin de adjuntar segmentos de red. Una opción común descrita 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 compilar una arquitectura con el fin de lograr una alta disponibilidad para el 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 las 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 para usar un balanceador de cargas TCP/UDP interno como el 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, las rutas de Google Cloud dirigen el tráfico a los dispositivos virtuales desde las redes de VPC conectadas. Puedes usar dispositivos en una configuración activa/pasiva mediante 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 garantizar 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 determinan dónde se reenvía el tráfico, lo que ayuda a garantizar que ese tráfico se reenvíe solo a las 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 cronómetros de verificación de estado para lograr una conmutación por error más rápida. En este enfoque, se proporcionan los tiempos de conmutación por error más rápidos en caso de instancias en mal estado.

Sin embargo, usar de 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 da como resultado tiempos de conmutación por error más lentos.
  • Si estableces cronómetros de verificación de estado para evitar la eliminación innecesaria y la recreación de instancias, esto generará tiempos de conmutación por error más lentos.

Elige una opción para adjuntar segmentos de red

Debido a que el enrutamiento entre subredes no se puede anular, 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, debe enrutarse 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últiples. La forma más simple de conectar varias redes de VPC a través de un dispositivo virtual es mediante interfaces de red múltiples, con cada interfaz que se conecta 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 realiza 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 conexiones locales y de Internet en 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. Las rutas predeterminadas que apuntan al balanceador de cargas TCP/UDP interno como el siguiente salto o a los dispositivos virtuales directamente se exportan como rutas personalizadas a través del intercambio de tráfico de 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 del concentrador. Cada red de VPC del concentrador se conecta a varias redes de VPC mediante el 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. En este enfoque, se combinan las dos opciones anteriores para la escalabilidad adicional. Las interfaces de red múltiples 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 entre redes de VPC.

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

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

    En el diagrama anterior, se muestra una red de VPC de concentrador adjunta a varias redes de VPC mediante el 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 central.

El siguiente árbol de decisión puede ayudarte a decidir el mejor enfoque para adjuntar segmentos de la red.

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

Usar 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, usar interfaces de red 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 ni quitar interfaces de red después de crear una instancia.

Usar el intercambio de tráfico entre redes de VPC tiene las siguientes ventajas:

Sin embargo, usar el 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 se pueden conectar sigue siendo 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 concentradores de VPC de concentrador para separar interfaces de red, y cada interfaz tiene 25 radios de redes de VPC conectadas. Esto te brinda 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 implementación.

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 a fin de adjuntar segmentos de red. En la segunda arquitectura de ejemplo, en un caso de uso especial, se muestra cómo enrutar el tráfico desde una sola red de VPC compartida en Google Cloud hacia un entorno local y a Internet.

Ejemplo de arquitectura mediante el intercambio de tráfico entre redes de VPC y el balanceador de cargas de TCP/UDP.

Esta arquitectura es un caso de uso típico de entornos empresariales, mediante el balanceador de cargas TCP/UDP interno para una alta disponibilidad, combinado con el intercambio de tráfico entre redes de VPC a fin de adjuntar segmentos de red.

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 radio 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 estática predeterminada se exporta a través del intercambio de tráfico entre redes de VPC mediante rutas personalizadas. Se borra la ruta predeterminada a la puerta de enlace de Internet en las redes de VPC del 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 forma 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 una conectividad una red de VPC 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 a través de verificaciones de estado personalizadas en el balanceador de cargas interno. Puedes configurar los dispositivos como activos/pasivo 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 solo 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 redes de VPC por red de VPC.

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

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 necesita pasar por 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 de uso mediante cualquiera de las opciones de alta disponibilidad descritas antes en este documento, combinadas con una interfaz de red cada una, para conectividad a la red de VPC compartida, de forma local y Google Cloud. Si deseas obtener visibilidad del tráfico entre subredes sin ejecutarlo a través de dispositivos centralizados, la duplicación del empaquetado puede ayudarte.

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

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

Implementación de una arquitectura con dispositivos virtuales

Para implementar una arquitectura que use dispositivos virtuales, elige la opción de alta disponibilidad y combínala con una opción a fin de 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 un caso de uso para el dispositivo, pero puedes adaptar la puerta de enlace mediante cualquiera de los otros casos de uso.

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?