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.
Arquitectura
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.
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:
- Firewalls de última generación (NGFW) Un conjunto centralizado de firewalls se ejecutan como máquinas virtuales que entregan funciones que no están disponibles si usas las reglas de firewall de VPC. Este es el caso de uso más común. Las características típicas de los productos NGFW son la inspección profunda de paquetes (DPI) y los firewalls en la capa de la aplicación. Algunos firewalls NGFW también proporcionan una inspección de tráfico de TLS/SSL y otras funciones de red descritas en los casos de uso en los siguientes elementos con viñetas.
- Sistema de detección de intrusiones/sistema de prevención de intrusiones (IDS/IPS). Un IDS basado en la red requiere la visibilidad de todo el tráfico potencialmente malicioso. Para evitar intrusiones, el tráfico suele estar bloqueado directamente por un IPS en la ruta de tráfico.
- Proxy transparente. A menudo, se usa un proxy transparente para supervisar el tráfico HTTP(S) y aplicar restricciones al acceso web.
- Puerta de enlace de traducción de dirección de red (NAT). Una puerta de enlace NAT traduce direcciones IP y puertos. Esto ayuda, por ejemplo, para evitar la superposición de direcciones IP. Google Cloud ofrece Cloud NAT como un servicio administrado, pero este servicio solo está disponible para el tráfico que va a Internet, no el tráfico local o para otras redes de VPC en Google Cloud.
- Firewall de aplicación web (WAF) Un WAF bloquea el tráfico HTTP malicioso a una aplicación web. Google Cloud ofrece la funcionalidad de WAF a través de las políticas de seguridad de Google Cloud Armor. La funcionalidad exacta difiere entre los proveedores de WAF, por lo que es importante determinar exactamente lo que necesitas.
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 de red de transferencia interno como próximo 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 de red de transferencia interno como próximo salto. En este enfoque, debes colocar varios dispositivos virtuales en un grupo de instancias administrado detrás de un balanceador de cargas de red de transferencia 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 balanceadores de cargas de red de transferencia 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 de red de transferencia interno como próximo salto puede tener backends en cualquier interfaz de red.
En el siguiente diagrama, se muestra la topología para usar un balanceador de cargas de red de transferencia interno como el próximo 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 de red de transferencia interno, que actúa como el próximo 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.
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.
El uso de un balanceador de cargas de red de transferencia interno como el próximo 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.
- Con el hash simétrico, puedes asegurarte de que el tráfico de retorno se enrute a la misma máquina virtual que el tráfico saliente.
Usar el enrutamiento de Google Cloud tiene las siguientes ventajas:
- El hash simétrico y coherente garantiza que la misma VM de backend procese los paquetes para una conexión determinada, para solicitudes y respuestas, según la selección de afinidad de sesión y protocolo. La selección de afinidad de sesión y protocolo determinan si se usa o no el seguimiento de la conexión. Ten en cuenta que algunos casos de uso podrían beneficiarse de tener una configuración de NAT de origen (SNAT) en las instancias de backend. Por ejemplo, si una conexión de respuesta de una red a otra debe coincidir con una conexión de solicitud distinta en la misma dirección entre las mismas dos redes.
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.
Ya sea que uses un balanceador de cargas de red de transferencia interno como el próximo salto o el enrutamiento de Google Cloud, se admite todo el tráfico de protocolo. Para obtener información detallada sobre esta compatibilidad, consulta Procesamiento de TCP, UDP y otro tráfico de protocolo.
Del mismo modo, ambas soluciones admiten la limitación de rutas a determinadas etiquetas de red. Por ejemplo, las instancias de VM se pueden segmentar por región para usar diferentes conjuntos de dispositivos.
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.
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 de red de transferencia interno como el próximo 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.
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.
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.
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:
- Puedes escalar verticalmente hasta el límite de las conexiones de intercambio de tráfico de red de VPC desde una sola red de VPC. Comunícate con el equipo de ventas de Google Cloud si tienes preguntas sobre cómo aumentar este límite.
- Es fácil agregar o quitar redes de VPC de esta arquitectura si configuras el intercambio de tráfico entre redes de VPC.
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 de red de transferencia 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.
Arquitectura de ejemplo que usa el intercambio de tráfico entre redes de VPC y el balanceador de cargas de red de transferencia interno como próximo salto
Esta arquitectura es un caso de uso típico de entornos empresariales, mediante el balanceador de cargas de red de transferencia 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.
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 de red de transferencia interno. Una ruta estática predeterminada apunta al balanceador de cargas de red de transferencia interno como el próximo 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 balanceadores de cargas de red de transferencia internos. 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 TCP/UDP o algún otro tráfico de protocolo. 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 una red de concentrador y radio mediante un balanceador de cargas 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.
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 obtener información sobre el uso del intercambio de tráfico entre redes de VPC entre segmentos y un balanceador de cargas de red de transferencia interno como una opción de alta disponibilidad, consulta Implementa una red de concentrador y radio mediante un balanceador de cargas como próximo salto.
Si quieres implementar un dispositivo de un socio de Google Cloud desde Cloud Marketplace, comunícate con tu proveedor de dispositivos o busca en el sitio web del proveedor los lineamientos sobre cómo implementar sus dispositivos en Google Cloud.
¿Qué sigue?
- Prácticas recomendadas y arquitecturas de referencia para el diseño de VPC.
- Topologías de red para nube híbrida y múltiples nubes.
- Prácticas recomendadas para el diseño de redes en el framework de arquitectura de Google Cloud.
- Documentación de la VPC.
- Documentación del balanceador de cargas de red de transferencia interno.
- Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.