Objetivos

• Comprenda los conceptos detrás de un modelo de radio y concentrador basado en VPC.
• Comprenda la implementación de un direccionador de cortafuegos y un entorno de VPC de tránsito.
• Comprender el direccionamiento de entrada y salida de VPC.
• Identifique y, opcionalmente, resuelva problemas de direccionamiento asimétrico.
• Conecte las VPC a través de un Transit Gateway.

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,
• Una clave SSH para conectarse a los servidores virtuales. Si no dispone de una clave SSH, siga las instrucciones para crear una clave para VPC.

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.

Dirección IP y diseño de subred

En este paso suministrará los recursos de red de VPC. Planifique cuidadosamente diseñando un plan de direccionamiento para una VPC y utilice bloques CIDR no solapados.

Es tentador dividir primero el espacio CIDR por VPC, pero esto complica el direccionamiento. En lugar de ello, piense en una zona de disponibilidad como un único bloque CIDR y cada VPC como consumiendo una porción de la misma.

Este diagrama muestra sólo la zona 1 con más detalle. Los tamaños de subred y el diseño son idénticos en las otras zonas:

Por encima de la empresa está a la izquierda y IBM Cloud a la derecha. En IBM Cloud para simplictiy, se representa una sola zona para la VPC de tránsito y Spoke 0. Observe que los bloques CIDR no se solapan y que todas las VPC consumen un bloque CIDR en cada zona:

• El CIDR local es 192.168.0.0/16.
• Las zonas de esta región multizona son 10.*.0.0/16. El segundo dígito: 1, 2, 3 es el número de zona (mostrado para Dallas/us-sur):
  • 10.10.1.0.0/16, zona 1, Dallas 1, us-south-1.
  • 10.10.2.0.0/16, zona 2, Dallas 2, us-south-2.
  • 10.10.3.0.0/16, zona 3, Dallas 3, us-south-3.
• La VPC de tránsito consume CIDR 10.*.15.0/24:
  • 10.1.15.0/24, zona 1.
  • 10.2.15.0/24, zona 2.
  • 10.3.15.0/24, zona 3.
• Spoke 0 consume 10.*.0.0/24 o CIDR:
  • 10.1.0.0/24, zona 1.
  • 10.2.0.0/24, zona 2.
  • 10.3.0.0/24, zona 3.
• Los CIDR de subred dividen además el /24 en /26.

Las subredes en tránsito y radio son para los distintos tipos de recursos:

• recursos de cálculo accesibles de red de trabajo, instancias de VPC, equilibradores de carga, Red Hat OpenShift, etc. Las instancias de VPC se muestran en esta guía de aprendizaje.
• dns-Dispositivos de ubicación DNS Services utilizados en la segunda parte.
• vpe- VPE for VPC utilizado en la segunda parte.
• Instancias de VPC fw-firewall-router (sólo en tránsito).

Suministrar recursos de red de VPC

1. El Repositorio deGitHub complementario tiene los archivos de origen para implementar la arquitectura. En un shell de escritorio, clone el repositorio:

   git clone https://github.com/IBM-Cloud/vpc-transit
   cd vpc-transit
   

2. El directorio config_tf contiene variables de configuración que debe configurar.

   cp config_tf/template.terraform.tfvars config_tf/terraform.tfvars
   

3. Edite config_tf/terraform.tfvars y utilice los comentarios de ese archivo como guía.

4. Puesto que es importante que cada capa se instale en el orden correcto y algunos pasos de esta guía de aprendizaje instalarán varias capas, se proporciona un mandato de shell ./apply.sh. Lo siguiente mostrará ayuda:

   ./apply.sh
   

5. Puede aplicar todas las capas configuradas ejecutando ./apply.sh : :. Los dos puntos son abreviados para first (o config_tf) y last (power_tf). -p imprime las capas:

   ./apply.sh -p : :
   

   Tendrá un aspecto similar al siguiente:

   directories: config_tf enterprise_tf transit_tf spokes_tf transit_spoke_tgw_tf test_instances_tf test_lbs_tf enterprise_link_tf firewall_tf transit_ingress_tf spokes_egress_tf all_firewall_tf all_firewall_asym_tf dns_tf vpe_transit_tf vpe_spokes_tf power_tf
   

6. Si aún no dispone de una, obtenga una clave de API de plataforma y expórtela para que Terraform pueda utilizarla:

   export IBMCLOUD_API_KEY=YourAPIKEy
   

7. En este primer paso se aplican en config_tf, enterprise_tf, transit_tf, voc_tf y transit_spoke_tgw_tf:

   ./apply.sh : transit_spoke_tgw_tf
   

Se han creado las VPC y subredes. Las VPC de tránsito y las VPC de radio se han conectado a través de un Transit Gatewaysuministrado. Abra las Nubes privadas virtuales en el navegador. Abra la VPC de tránsito y anote los bloques CIDR para prefijos de dirección y subredes. Examine también las VPC empresariales y de radio. Abra Transit Gateway y pulse la pasarela de tránsito para ver la conexión entre las VPC de tránsito y de radio.

Crear instancias de prueba

Las instancias de servidor virtual de VPC, VSI, se suministran para probar la conectividad de red. Se añadirá una instancia de prueba a cada una de las subredes de trabajador (una por zona) en la empresa, el tránsito y cada uno de los radios. Si se utiliza la configuración predeterminada de 3 zonas y 2 radios, se suministrarán 12 instancias.

1. Crear las instancias de prueba

   ./apply.sh test_instances_tf
   

Puede ser ilustrativo explorar los recursos creados en cada paso en la consola de IBM Cloud. Opcionalmente, abra las Nubes privadas virtuales. En la izquierda, pulse Instancias de servidor virtual y observe las instancias que se han creado.

Pruebas

Esta guía de aprendizaje añadirá vías de acceso de comunicación de una capa a la vez. Se utilizará una suite de pruebas pytest para probar exhaustivamente las vías de acceso de comunicación. Al final de la guía de aprendizaje se espera que pasen todas las pruebas.

No es necesario que el lector utilice pytest para verificar los resultados. Siga en la guía de aprendizaje, aplique las capas y confíe en los resultados descritos en la guía de aprendizaje. El lector puede seguir explorando los recursos de VPC como, por ejemplo, las VSI, las subredes y las tablas de direccionamiento después de que se hayan creado.

Cada prueba pytest ejecutará SSH en una de las instancias y realizará un tipo de prueba de conectividad, como ejecutar un mandato curl en una de las otras instancias. El entorno SSH predeterminado se utiliza para iniciar sesión en las instancias. Si ve resultados de prueba inesperados, pruebe la sección resolución de problemas de pytest.

1. Ejecute las pruebas de la zona 1 curl en la suite utilizando el distintivo -m (marcadores). Elija las pruebas marcadas con curl, lz1 (zona izquierda 1) y rz1 (zona derecha 1).

   Los resultados esperados son: La conectividad dentro de una VPC, como la empresa <-> empresarial, se PASARÁ. La conectividad entre el tránsito y los radios se pasará. La VPC cruzada de la empresa-> tránsito o radios será FAILED.

   pytest -m "curl and lz1 and rz1"
   

   A continuación se muestra un ejemplo:

   root@ea28970e0897:/usr/src/app# pytest -m "curl and lz1 and rz1"
   ===================================================== test session starts ======================================================
   platform linux -- Python 3.12.3, pytest-8.1.1, pluggy-1.4.0 -- /usr/local/bin/python
   cachedir: .pytest_cache
   rootdir: /usr/src/app
   configfile: pytest.ini
   testpaths: py
   plugins: xdist-3.5.0
   collected 36 items / 20 deselected / 16 selected
   
   py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-enterprise-z1-worker] PASSED                                   [  6%]
   py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-transit-z1-worker] FAILED                                      [ 12%]
   py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke0-z1-worker] FAILED                                       [ 18%]
   py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke1-z1-worker] FAILED                                       [ 25%]
   py/test_transit.py::test_curl[l-transit-z1-worker -> r-enterprise-z1-worker] FAILED                                      [ 31%]
   py/test_transit.py::test_curl[l-transit-z1-worker -> r-transit-z1-worker] PASSED                                         [ 37%]
   py/test_transit.py::test_curl[l-transit-z1-worker -> r-spoke0-z1-worker] PASSED                                          [ 43%]
   py/test_transit.py::test_curl[l-transit-z1-worker -> r-spoke1-z1-worker] PASSED                                          [ 50%]
   py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-enterprise-z1-worker] FAILED                                       [ 56%]
   py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-transit-z1-worker] PASSED                                          [ 62%]
   py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-spoke0-z1-worker] PASSED                                           [ 68%]
   py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-spoke1-z1-worker] PASSED                                           [ 75%]
   py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-enterprise-z1-worker] FAILED                                       [ 81%]
   py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-transit-z1-worker] PASSED                                          [ 87%]
   py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-spoke0-z1-worker] PASSED                                           [ 93%]
   py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-spoke1-z1-worker] PASSED                                           [100%]
   
   =================================================== short test summary info ====================================================
   FAILED py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-transit-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke0-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke1-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-transit-z1-worker -> r-enterprise-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-enterprise-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-enterprise-z1-worker] - assert False
   ========================================= 6 failed, 10 passed, 20 deselected in 38.76s =========================================
   

Un cambio en la configuración de red puede tardar un par de ejecuciones de prueba para que el sistema de red VPC subyacente sea coherente. Si no ve los resultados esperados inicialmente, esté preparado para volver a ejecutar la prueba un par de veces.

r- y l- representan r ight y l eft. La parte central del nombre identifica la empresa, el tránsito, spoke0, spoke1, ... Los z1, z2, ... identifican la zona. La prueba realizará SSH en la instancia izquierda. En la instancia izquierda se intenta la conectividad con la instancia derecha. test_curl realiza una conectividad curl en la instancia izquierda a la instancia derecha.

En resumen, la prueba test_curl[l-enterprise-z1 -> r-transit-z1] :

1. SSH a una instancia de prueba en la zona de empresa 1.
2. Ejecute un curl en la zona de tránsito 1.
3. Certificar que la serie de retorno contiene el ID de la zona de tránsito 1 para marcar como correcta o anómala.

El archivo README.md del repositorio GitHub complementario tiene más detalles y el código fuente.

Conecte Enterprise to Transit a través de Direct Link y Transit Gateway

Suministre un IBM Cloud® Direct Link utilizando Transit Gateway.

IBM Cloud® Direct Link es una vía de acceso de datos segura de alta velocidad para conectar una empresa a IBM Cloud. En esta guía de aprendizaje se utiliza Transit Gateway para la distribución. El uso de Transit Gateway es opcional para una conexión local.

La empresa de esta guía de aprendizaje se simula con otra VPC. La conexión de esta empresa simulada (en realidad otra VPC) a través de Transit Gateway asegurará una experiencia muy cercana a la que experimentaría con un Direct Link.

1. Aplique la capa enterprise_link_tf:

   ./apply.sh enterprise_link_tf
   

2. Ejecute las pruebas curl de zona 1 en la suite utilizando el distintivo -m (marcadores). Elija las pruebas marcadas con curl, lz1 (zona izquierda 1) y rz1 (zona derecha 1).

   Sus resultados esperados son: Conectividad dentro de una VPC, tránsito <-> radio (s), empresa <-> tránsito, radio (s) <-> radio (s) pasa (n) pero la empresa <-> radio (s) falla.

   pytest -m "curl and lz1 and rz1"
   

Conectar Enterprise a Spoke (s) a través de Transit NFV Firewall-Router

El incentivo para una VPC de tránsito para el tráfico de nube <-> de empresa suele ser direccionar, inspeccionar, supervisar y registrar el tráfico de red. En este paso se instalará un dispositivo de direccionador de cortafuegos en cada zona de la VPC de tránsito.

Direccionador NFV

Suministre los dispositivos de direccionador de cortafuegos. Se ha añadido una tabla de direccionamiento de entrada para Transit Gateway a la VPC de tránsito tal como indican las líneas de puntos. Se ha creado una subred en cada una de las zonas de la VPC de tránsito para contener el direccionador de cortafuegos.

La conectividad de la empresa a un radio se consigue a través de una virtualización de función de red, NFV, instancia de direccionador de cortafuegos en la VPC de tránsito. En producción puede elegir uno del catálogo o traer el suyo propio. Esta demostración utilizará una imagen en stock de Ubuntu con iptables de kernel configurados para reenviar todos los paquetes del origen al destino. En esta guía de aprendizaje, no se realiza ninguna inspección de cortafuegos.

La configuración de Terraform configurará la instancia de direccionador de cortafuegos con allow_ip_spoofing. Debe habilitar las comprobaciones de suplantación de IP antes de continuar.

1. Aplique la capa firewall_tf:

   ./apply.sh firewall_tf
   

2. Ejecute la suite de pruebas.

   Los resultados esperados son: Conectividad dentro de una VPC, empresa-> transit, empresa <-> spoke misma zona pass. Pero todo el tránsito-> radio, todo el tránsito-> empresa fallan debido a problemas de direccionamiento asimétrico.

   pytest -m "curl and lz1 and (rz1 or rz2)"
   

   La Parte dos de esta guía de aprendizaje direccionará todo el tráfico de VPC <-> diferente a través del direccionador de cortafuegos y resolverá estos problemas. Pero primero es importante aprender lo que está pasando.

Eliminación del cortafuegos para el tráfico de destino de tránsito

IBM Cloud VPC utiliza el direccionamiento basado en estado estándar del sector para el seguimiento de conexiones TCP seguras. Requiere que las conexiones TCP utilicen la misma vía de acceso en el camino de salida. Una excepción es Direct Server Return utilizado por direccionadores como Network Load Balancers. Permite que las conexiones entrantes de la empresa pasen a través del cortafuegos a la instancia de prueba de tránsito y, a continuación, vuelvan directamente al originador.

Esto no ayuda con el tráfico que se origina en la instancia de prueba de tránsito que pasa a través de Transit Gateway y, a continuación, vuelve a través del direccionamiento de entrada al direccionador de cortafuegos. Esta conexión se atasca en el firewall-router (3) y no se reenviará de vuelta al trabajador como se muestra en rojo a continuación. Tránsito de tráfico-> empresa y tránsito-> radio están fallando.

Una posible solución es dejar de enviar el tráfico destinado a la VPC de tránsito al firewall-router. Las rutas de entrada anchas para el tránsito están direccionando actualmente el tráfico al cortafuegos-direccionador. Se pueden añadir rutas más específicas para el tránsito a Delegar al comportamiento predeterminado-enviar directamente al destino previsto en lugar del direccionador de cortafuegos.

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

1. empresa <-> tránsito
2. spoke <-> tránsito
3. radio <-> radio
4. enterprise <--transit firewall-router--> spoke

Este direccionamiento se puede conseguir añadiendo estas rutas a la tabla de rutas de entrada de tránsito:

1. Para observar el valor actual de la tabla de ruta de entrada, visite las Tablas de direccionamiento para VPC en la consola de IBM Cloud. Seleccione la VPC de tránsito en el desplegable y, a continuación, seleccione la tabla de direccionamiento tgw-ingress.

2. Realice los cambios en la tabla de direccionamiento aplicando la capa transit_ingress:

./apply.sh transit_ingress_tf

1. Renueve la visualización del navegador de la tabla de direccionamiento para observar las nuevas rutas.

2. Ejecute la suite de pruebas.

   Los resultados esperados son: Todas las pruebas darán como resultado CORRECTO.

   pytest -m "curl and lz1 and (rz1 or rz2)"
   

Es interesante observar cómo fluye el tráfico entre zonas entre la empresa y los radios en la configuración. La empresa envía tráfico a la zona correcta y a través del cortafuegos-direccionador a través del direccionamiento de entrada en la VPC de tránsito. Transit Gateway ha aprendido que 192.168.0.0/16 está disponible en todas las zonas y se direccionará a la VPC de tránsito utilizando las rutas de empresa anunciadas en la misma zona que el radio, tal como se muestra en el diagrama siguiente:

Resumen de direccionamiento

El direccionamiento básico se ha completado:

• empresa <-> tránsito
• tránsito <-> radio (s)
• enterprise < -- (cortafuegos de tránsito-direccionador)-- > spoke

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.0.0.0/10, 10.64.0.0/10, 10.128.0.0/10 para conservar el espacio de direcciones. El espacio de direcciones para los nodos de trabajador se podría ampliar a expensas del cortafuegos, DNS y 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 identificado las zonas de disponibilidad necesarias para la arquitectura y ha creado un conjunto de subredes en las VPC. Ha creado un direccionador de cortafuegos de VPC de tránsito en cada zona para reenvío de tráfico. Se han utilizado instancias de prueba para verificar la conectividad e identificar posibles problemas. Se han utilizado rutas de tabla de direccionamiento para identificar las vías de acceso de tráfico necesarias.

Eliminación de recursos

No es necesario eliminar los recursos si tiene previsto continuar con la segunda parte de esta guía de aprendizaje.

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

./apply.sh -d : spokes_egress_tf

Ampliación de la guía de aprendizaje

Se recomienda continuar en la segunda parte de esta guía de aprendizaje donde todo el tráfico de VPC cruzado se direcciona a través del direccionador de cortafuegos, se examinan VPE for VPC y DNS.

Su arquitectura probablemente será diferente de 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 captura de registro de flujo 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