Objetivos

• Comprenda los conceptos detrás de un concentrador basado en VPC y un modelo de radio para gestionar todo el tráfico de VPC a VPC.
• Comprender el direccionamiento de entrada y salida de VPC.
• Identifique y, opcionalmente, resuelva problemas de direccionamiento asimétrico.
• Comprenda el uso de un equilibrador de carga de red para un direccionador de cortafuegos escalable y de alta disponibilidad.
• Utilice las reglas de direccionamiento y reenvío de servicios DNS para crear un sistema de resolución de nombres de sonido arquitectónico.

Antes de empezar

Esta guía de aprendizaje requiere:

• terraform para utilizar la infraestructura como código para suministrar recursos,
• python para ejecutar opcionalmente los mandatos pytest,
• La implementación de un direccionador de cortafuegos requerirá que habilite las comprobaciones de suplantación de IP,

Consulte los requisitos previos para ver algunas opciones que incluyen un Dockerfile para crear fácilmente el entorno de requisito previo.

Además:

• Compruebe los permisos de usuario. Asegúrese de que la cuenta de usuario tiene permisos suficientes para crear y gestionar todos los recursos de esta guía de aprendizaje. Consulte la lista de:
  • permisos necesarios para VPC.
  • permisos necesarios para crear Transit Gateway.
  • permisos necesarios para comprobaciones de suplantación de IP.
  • permisos necesarios para gestionar autorizaciones.

Resumen de la primera parte

En la parte uno de esta guía de aprendizaje planificamos cuidadosamente el espacio de direcciones de las VPC de tránsito y de radio. La arquitectura basada en zonas se muestra a continuación:

Este diagrama muestra el flujo de tráfico. Solo el radio de la empresa <-> pasa a través del cortafuegos:

Esto se ha conseguido con el direccionamiento Direct Link, Transit Gateway y VPC. Todas las zonas se configuran de forma similar y el diagrama siguiente muestra los detalles de la zona 1:

El CIDR 10.1.0.0/16 cubre el tránsito y los radios y se pasa a través de Direct Link a la empresa como una ruta anunciada. De forma similar, el CIDR 192.168.0.0/24 cubre la empresa y se pasa a través de Transit Gateway a los radios como una ruta anunciada.

Las rutas de salida en los radios direccionan el tráfico al cortafuegos-direccionador. Rutas de entrada en la empresa de ruta de tránsito <-> tráfico de radio a través del direccionador de cortafuegos.

Suministrar recursos de VPC iniciales que direccionen todo el tráfico interno de VPC a través del cortafuegos-direccionador

A menudo, una empresa utiliza una VPC de tránsito para supervisar el tráfico con el direccionador de cortafuegos. En la primera parte, solo el tráfico de radio <-> de la empresa fluía a través del cortafuegos-direccionador de tránsito. Esta sección trata sobre el direccionamiento de todo el tráfico de VPC a VPC a través del direccionador de cortafuegos.

Este diagrama muestra el flujo de tráfico implementado en este paso:

Todo el tráfico entre VPC fluirá a través del cortafuegos-direccionador:

• enterprise <->.
• empresa <-> tránsito.
• transit <-> spoke.
• spoke <-> en una VPC diferente.

El tráfico dentro de una VPC no fluirá a través del cortafuegos.

Si continúa desde la parte uno, tome nota de la configuración en terraform.tfvars: all_firewall = true.

Arreglar direccionamiento entre zonas

Como se mencionó anteriormente para que un sistema sea resistente a las anomalías zonales, lo mejor es eliminar el tráfico entre zonas. Si el soporte de zonas cruzadas es necesario, se pueden añadir rutas de salida adicionales. El problema para el tráfico de radio 0 a radio 1 se muestra en este diagrama:

La vía de acceso verde es un ejemplo de direccionamiento de la zona 0 de radio originador 2 10.2.0.4 a la zona 1 de radio 1 10.1.1.4. La ruta de salida coincidente es:

Zone	Destino	Siguiente salto
Dallas10.0.0.0/810.2.15.196

Moviendo de izquierda a derecha se selecciona el firewall-router en la zona media, zona 2, del diagrama. En la vía de acceso de retorno, se selecciona la zona 1.

Para arreglar esto, es necesario añadir algunas rutas más específicas para forzar a las zonas de número más alto a direccionar a los cortafuegos de número de zona más bajo cuando se especifica un destino de número de zona más bajo. Cuando se hace referencia a una zona de número igual o superior, se sigue direccionando al cortafuegos en la misma zona.

Rutas en la tabla de enrutamiento de salida por defecto de cada radio (mostrada para Dallas/us-sur):

Zone	Destino	Siguiente salto
Dallas10.1.0.0/1610.1.15.196
Dallas10.1.0.0/1610.1.15.196
Dallas10.2.0.0/1610.2.15.196

Estas rutas también van a corregir un problema de direccionamiento asimétrico de zona cruzada de radio < -- > de tránsito similar. Considere el trabajador de tránsito 10.1.15.4-> trabajador de radio 10.2.0.4. El tráfico del trabajador de tránsito en la zona 1 elegirá el cortafuegos-direccionador en la zona 1 (misma zona). En el viaje de vuelta en lugar de firewall-router en la zona 2 (misma zona) ahora se utilizará firewall-router en la zona 1.

1. Aplique la capa all_firewall_asym:

   ./apply.sh all_firewall_asym_tf
   

2. Ejecute la suite de pruebas.

   Sus resultados esperados son: todas las pruebas PASADAS, ejecútelas en paralelo (-n 10):

   pytest -n 10 -m curl
   

Todo el tráfico entre VPC se direcciona ahora a través de los direccionadores de cortafuegos.

Cortafuegos de alta disponibilidad (HA) de alto rendimiento-Direccionador

Para evitar que un direccionador de cortafuegos se convierta en el cuello de botella de rendimiento o en un único punto de anomalía, es posible añadir un equilibrador de carga de red de VPC para distribuir el tráfico a los direccionadores de cortafuegos zonales para crear un direccionador de cortafuegos de alta disponibilidad. Compruebe la documentación del direccionador de cortafuegos para verificar que da soporte a esta arquitectura.

Este diagrama muestra una sola zona con un equilibrador de carga de red (NLB) configurado en modalidad de ruta frente a dos direccionadores de cortafuegos. Para ver esta construcción es necesario cambiar la configuración y aplicar de nuevo.

1. Cambie estas dos variables en config_tf/terraform.tfvars:

   firewall_nlb                 = true
   number_of_firewalls_per_zone = 2
   

   Este cambio hace que la dirección IP del direccionador de cortafuegos cambie de la instancia de direccionador de cortafuegos utilizada anteriormente a la dirección IP del NLB. El cambio de dirección IP debe aplicarse a una serie de rutas de tabla de rutas de VPC en las VPC de tránsito y de radio. Es mejor aplicar todas las capas aplicadas anteriormente:

2. Aplique todas las capas a través de la capa all_firewall_asym_tf:

   ./apply.sh : all_firewall_asym_tf
   

Observe los cambios que se han realizado:

1. Abra los Equilibradores de carga para VPC.
2. Seleccione el equilibrador de carga de la zona 1 (Dallas 1/us-south-1) que tiene el sufijo fw-z1-s3.
3. Anote las IP privadas.

Compare las IP privadas con las de la tabla de rutas de entrada de VPC de tránsito:

1. Abra las Nubes privadas virtuales.
2. Seleccione la VPC de tránsito.
3. Pulse Gestionar tablas de direccionamiento.
4. Pulse la tabla de direccionamiento tgw-ingress. Observe que la dirección IP del salto siguiente coincide con una de las IP privadas del NLB

Verifique la resiliencia:

1. Ejecute las pruebas de la zona 1 de radio 0:

   pytest -k r-spoke0-z1 -m curl
   

2. Abra las Instancias de servidor virtual para VPC
3. Detenga el tráfico a la instancia de cortafuegos 0 especificando un grupo de seguridad que no permitirá el puerto de entrada 80. Localice la instancia con el sufijo fw-z1-s3-0 y abra la vista de detalles:
   1. Desplácese hacia abajo y pulse la edición de lápiz junto a la Interfaz de red
   2. Desmarque la opción x-fw-inall-outall
   3. Compruebe el x-fw-in22-outall
   4. Pulse Guardar
4. Vuelva a ejecutar el pytest. Indicará anomalías. El NLB tardará unos minutos en detener el direccionamiento del tráfico a la instancia que no responde, momento en el que pasarán todas las pruebas. Continúe esperando y ejecutando pytest hasta que pasen todas las pruebas.

El cortafuegos de NLB ya no es necesario. Elimine el cortafuegos de NLB:

1. Cambie estas dos variables en config_tf/terraform.tfvars:

   firewall_nlb                 = false
   number_of_firewalls_per_zone = 1
   

2. Aplique todas las capas a través de la capa all_firewall_asym_tf:

   ./apply.sh : all_firewall_asym_tf
   

Nota sobre NLB configurado en modalidad de direccionamiento

La modalidad de ruta de NLB reescribirá las entradas de tabla de ruta-siempre manteniendo la dirección IP de dispositivo de NLB activa en la tabla de ruta durante una migración tras error. Pero esto sólo se hace para las rutas en la VPC de tránsito que contiene el NLB. El radio tiene rutas de salida que se han inicializado con una de las IP de dispositivo de NLB. El salto siguiente de radio no se actualizará en la migración tras error del dispositivo NLB.

Será necesario mantener una ruta de entrada en la VPC de tránsito que será reescrita por el NLB para reflejar el dispositivo activo. La ruta de salida de radio entregará paquetes a la zona correcta de la VPC de tránsito. El direccionamiento dentro de la zona de VPC de tránsito encontrará la regla de entrada coincidente que contendrá el dispositivo activo.

A continuación se muestra la tabla de rutas de entrada de VPC de tránsito que se ha tratado anteriormente. El salto siguiente se mantendrá actualizado con el dispositivo de NLB activo. Observe que Dallas 3 tiene un cambio escrito por el servicio de modo de ruta NLB para reflejar el dispositivo activo.

El NLB requiere que se cree una autorización de IAM que permita al NLB grabar en la VPC. Esta autorización ha sido creada por el script apply.sh. Consulte Creación de un equilibrador de carga de red con modalidad de direccionamiento para obtener más detalles sobre la configuración que ha realizado el script.

La agrupación de NLB de modalidad de ruta debe estar configurada con Tipo de persistencia de sesión establecido en nulo.

DNS

El servicio IBM Cloud DNS Services se utiliza para convertir nombres en direcciones IP. En este ejemplo, se crea un servicio DNS en la nube. Se crea la zona DNS cloud.example.com y se añade la VPC de tránsito como una red permitida. Los registros DNS para las instancias de nube se añaden a cloud.example.com. Por ejemplo, se crea un registro A para el trabajador de radio 0 en la zona 1 que tendría el nombre completo spoke0-z1-worker.cloud.example.com.

Consulte sobre el uso compartido de DNS para pasarelas VPE. La VPC de tránsito está habilitada como concentrador DNS. Cada VPC de radio se configura con el enlace de resolución DNS al concentrador de VPC de tránsito. Esto configurará los valores DHCP de la VPC de radio para que los servidores DNS sean los solucionadores personalizados de la VPC de tránsito.

./apply.sh dns_tf

pytest -n 10 -m dns

pasarelas de punto final privado virtual

VPC permite el acceso privado a IBM Cloud Services a través de Virtual Private Endpoint (VPE) for VPC. Las pasarelas VPE permiten un control de acceso de red de grano fino a través de controles IBM Cloud VPC estándar:

• Security Groups.
• Listas de control de acceso de red de VPC.
• Direccionamiento de tablas y rutas.

Se crea una zona DNS para cada pasarela VPE de VPC. La zona DNS se añade automáticamente al servicio DNS privado asociado con la VPC. Cada VPC de radio tiene una configuración de DNS bound para la VPC de tránsito. Esto permite que la zona DNS de VPE de radio se comparta con la VPC de tránsito.

1. Cree una instancia de IBM Cloud Databases for PostgreSQL y VPE para el tránsito y cada una de las VPC de radio, aplicando las capas vpe_transit_tf y vpe_voc_tf:

   ./apply.sh vpe_transit_tf vpe_spokes_tf
   

2. Hay un conjunto de pruebas vpe y vpedns que están disponibles en el script pytest. La prueba vpedns verificará que el nombre DNS de una instancia de Databases for PostgreSQL esté dentro del bloque CIDR privado de la VPC que la contiene. La prueba vpe ejecutará un mandato psql para acceder a la instancia de Databases for PostgreSQL de forma remota. Probar vpe y vpedns de radio 0 zona 1:

   • Resultados esperados que pasan todas las pruebas

   pytest -m 'vpe or vpedns' -k spoke0-z1
   

Todas las pruebas de esta guía de aprendizaje deben pasar ahora. Hay bastantes. Ejecútelos en paralelo:

pytest -n 10

Notas de producción y conclusiones

La arquitectura de referencia de VPC para IBM Cloud for Financial Services tiene muchos más detalles sobre la protección de cargas de trabajo en IBM Cloud.

Algunos cambios obvios a realizar:

• Los bloques CIDR fueron elegidos por claridad y facilidad de explicación. Las zonas de disponibilidad en la región multizona podrían ser 10.1.0.0/10, 10.64.0.0/10, 10.128.0.0/10 para conservar el espacio de direcciones. De forma similar, el espacio de direcciones para los nodos de trabajador se podría ampliar a expensas del cortafuegos, el DNS y el espacio de VPE.
• Los grupos de seguridad para cada una de las interfaces de red para las VSI de trabajador, las pasarelas de punto final privado virtual, las ubicaciones DNS y los cortafuegos deben considerarse cuidadosamente.
• Las listas de control de acceso de red para cada subred deben considerarse cuidadosamente.
• Las IP flotantes se han conectado a todas las instancias de prueba para dar soporte a las pruebas de conectividad a través de SSH. Esto no es necesario o deseable en la producción.
• Implementar restricciones basadas en contexto para controlar adicionalmente el acceso a todos los recursos.

En esta guía de aprendizaje ha creado una VPC concentrador y un conjunto de VPC de radio. Ha direccionado todo el tráfico entre VPC a través de un direccionador de cortafuegos de VPC de tránsito. Se ha creado un servicio DNS para el concentrador de VPC de tránsito y cada VPC de radio estaba enlazado DNS a la VPC de tránsito.

Eliminación de recursos

Ejecute terraform destroy en todos los directorios en orden inverso utilizando el mandato ./apply.sh :

./apply.sh -d : :

Ampliación de la guía de aprendizaje

Su arquitectura puede no ser la misma que la presentada, pero probablemente se construirá a partir de los componentes fundamentales discutidos aquí. Ideas para expandir esta guía de aprendizaje:

• Integre el acceso a Internet público entrante utilizando IBM Cloud® Internet Services.
• Añada Flow Logs for VPC capture en el tránsito.
• Coloque cada uno de los radios en una cuenta separada en una empresa.
• Obligue a algunos de los radios al tráfico de radio a través del cortafuegos y a otros no a través del cortafuegos.
• Sustituya las VSI de trabajador por Red Hat OpenShift on IBM Cloud y el equilibrador de carga de VPC.
• Forzar todo el tráfico enlazado a través del cortafuegos en la VPC de tránsito y a través de Pasarelas públicas.

Contenido relacionado

• IBM Cloud for Financial Services
• Cómo desplegar cargas de trabajo aisladas en varias ubicaciones y regiones
• Front end público y backend privado en una nube privada virtual,
• Virtualización de función de red
• Concentrador privado y hablado con VNF transparente y tráfico de radio a radio