Objetivos

• Comprenda los conceptos detrás de una red Power Virtual Server.
• Utilice IBM Cloud Transit Gateway para conectar Power Virtual Server a VPC.
• Direccionar el tráfico Power Virtual Server a local a través de una VPN de sitio a sitio de VPC.
• Conecte las instancias de Power Virtual Server a través de pasarelas de punto final privado virtual de VPC a los servicios.
• Utilice las reglas de direccionamiento y reenvío de servicios DNS para crear un sistema de resolución de nombres de sonido arquitectónico.
• Utilice las pasarelas de punto final privado virtual de VPC para acceder de forma segura a los servicios de nube.

Antes de empezar

Esta guía de aprendizaje requiere Power Virtual Server centros de datos que den soporte a Power Edge Routing (PER). Consulte Iniciación a Power Edge Router para obtener más información, incluida la lista de centros de datos donde está disponible la solución.

Esta guía de aprendizaje requiere:

• Terraform para utilizar la Infraestructura como Código para aprovisionar recursos

• Python para ejecutar opcionalmente los mandatos pytest

• Requisitos previos en el repositorio GitHub complementario

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

Además, compruebe los permisos de usuario. Asegúrese de que la cuenta de usuario tenga 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 Power Virtual Server.

Suministrar recursos

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 requiere un archivo terraform.tfvars. El archivo template.power.terraform.tfvars es el punto de partida de esta guía de aprendizaje.

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

3. Edite config_tf/terraform.tfvars. Utilice los comentarios de ese archivo como guía. Cambie los valores de resource_group_name y basename existentes. La serie $BASENAME en el texto siguiente hace referencia al nombre base proporcionado aquí.

4. Es posible suministrar a la arquitectura una capa a la vez. Se proporciona un mandato de shell ./apply.sh para instalar las capas en orden. A continuación se muestra la ayuda:

   ./apply.sh
   

5. 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
   

6. Instale todas las capas. Los caracteres ':' se utilizan para representar las capas primera y última.

   ./apply.sh : :
   

Puede tardar hasta 30 minutos en crear los recursos en el diagrama. La empresa se simula utilizando una VPC.

Comprobar el diseño de dirección IP no solapada

El diseño de dirección se muestra a continuación. Observe las direcciones que no se solapan.

Aviso:

• Se utiliza un espacio de direcciones de zona de disponibilidad 10.1.0.0/16 para la zona de disponibilidad de VPC 1 y los espacios de trabajo Power Virtual Server en dal10.
• El espacio de direcciones para la empresa, el tránsito y spoke0 no se solapan.
• Se utiliza un prefijo de dirección local en la VPC de tránsito para anunciar las rutas empresariales a través de Transit Gateway. No se crean subredes en la VPC de tránsito a partir del prefijo local. Esto se describe en el paso "investigar Transit Gateway" a continuación.

Explore la arquitectura en la consola de IBM Cloud:

1. Vaya a Nubes privadas virtuales.
2. Seleccione su región en el menú.
3. Seleccione la VPC de empresa y observe el prefijo de dirección: 192.168.0.0/24
4. Vaya a Nubes privadas virtuales.
5. Seleccione la VPC de tránsito y aviso:
   • El prefijo de dirección 10.1.15.0/24 define la zona 1 de VPC de tránsito.
   • on-prem address prefix, 192.168.0.0/24.

Verificar las claves SSH

1. El suministro ha creado dos archivos uno para cada miembro del par de claves necesario para SSH:
   • config_tf/id_rsa-clave privada que debe mantener a salvo.
   • config_tf/id_rsa.pub-clave pública que se puede proporcionar a terceros.
2. La clave pública se ha utilizado para crear dos claves SSH en la nube:
   • Clave SSH de alimentación.
   • Clave SSH para VPC.
3. Localizar clave SSH de VPC:
   • Vaya a Claves SSH para VPC.
   • Observe la clave SSH con $BASENAME.
4. Localice la clave Power SSH:
   • Vaya a Claves SSH de alimentación.
   • En el panel de navegación de la izquierda, seleccione el espacio de trabajo en el desplegable debajo de la palabra Espacios de trabajo con $BASENAME.
   • Observe la clave SSH con $BASENAME.

Opcionalmente, verifique que el contenido de la clave SSH en la nube coincide con el contenido del archivo de claves públicas.

Abrir el espacio de trabajo Power® Virtual Server

Junto con las claves SSH, el suministro ha creado un espacio de trabajo, subredes y una instancia de Power® Virtual Server.

• Abra la página Subredes de Power Virtual Server.
• En el panel de navegación de la izquierda, seleccione el espacio de trabajo en el desplegable debajo de la palabra Espacios de trabajo con $BASENAME.
• Pulse Subredes en el menú Redes de la izquierda (si es necesario) y observe las subredes públicas y privadas que se han creado.
• Pulse el nombre de la subred privada y observe la dirección Gateway a la que se hará referencia más adelante en la configuración de la tabla ip de la instancia.
• Pulse el nombre de la subred pública y observe la dirección Gateway a la que se hará referencia más adelante en la configuración de la tabla ip de la instancia.
• Pulse las Instancias de servidor virtual de la izquierda y observe la instancia que se ha suministrado junto con las direcciones IP pública y privada.

Configurar el servidor virtual

La configuración de Terraform ha creado una instancia de servidor virtual Power Virtual Server Linux, pero no se ha podido configurar completamente. Ahora es posible configurar las tablas de direccionamiento IP e instalar un servidor NGINX para dar soporte a las pruebas.

cd power_tf; # should be in the .../vpc-transit/power_tf directory
terraform output fixpower

Esta experiencia se parece a la siguiente:

% cd power_tf
% terraform output fixpower
[
  {
    "abc-spoke1" = <<-EOT
    # ssh -J root@52.116.131.48 root@10.1.2.31
    ssh -oProxyCommand="ssh -W %h:%p -i ../config_tf/id_rsa root@52.116.131.48" -i ../config_tf/id_rsa root@10.1.2.31
    ip route add 10.0.0.0/8 via 10.1.2.1 dev eth0
    ip route add 172.16.0.0/12 via 10.1.2.1 dev eth0
    ip route add 192.168.0.0/16 via 10.1.2.1 dev eth0
    ip route change default via 192.168.232.1 dev eth1
    exit
    # it is now possible to ssh directly to the public IP address
    ssh -i ../config_tf/id_rsa root@150.240.147.36
    # execute the rest of these commands to install nginx for testing
    zypper install -y nginx
    systemctl start nginx
    echo abc-spoke1 > /srv/www/htdocs/name
    sleep 10
    curl localhost/name


    EOT
  },
]

En una nueva ventana de terminal, copie y pegue los mandatos una línea a la vez. Esto es lo que está sucediendo:

• El mandato SSH inicia sesión en la instancia de servidor virtual utilizando la clave SSH privada creada anteriormente. Es necesario saltar a través de un servidor virtual de VPC de tránsito intermedio. El -oProxyCommand configura el servidor de salto.
• Los mandatos ip route se ejecutan en el servidor PowerLinux direccionan todos los bloques CIDR de red privada a través de la subred privada (eth0). Tenga en cuenta que estos incluyen el bloque CIDR de nube de 10.0.0.0 y el bloque CIDR de empresa de 192.168.0.0.
• El valor predeterminado direcciona el resto de las direcciones, incluida la dirección IP de la estación de trabajo a través de la subred pública (eth1). Esto permite que la automatización de pruebas ejecute SSH directamente en la dirección IP pública de la instancia de servidor virtual en el futuro y evitar el servidor de salto.
• Salga de la sesión SSH.
• Utilice SSH para iniciar sesión directamente en la instancia utilizando la dirección IP pública. Esto verifica que la configuración de iptable es correcta.
• El paso final es instalar NGINX. NGINX es un servidor HTTP que aloja una página web que se verifica mediante un comando curl.

Puede mantener este shell disponible para utilizarlo en pasos futuros.

Probar conectividad de red

Una suite de pruebas pytest se utiliza para probar exhaustivamente las vías de acceso de comunicación.

No es necesario que el lector utilice pytest para verificar los resultados. Es directo reproducir los resultados de la prueba que se muestran a continuación a mano, pero tedioso. Para cada línea de la salida de ejemplo, busque el recurso en la vista Recursos de la consola de IBM Cloud, vaya al recurso izquierdo y localice las direcciones IP públicas para una sesión SSH. Utilizando el shell de la instancia de nube, ejecute un mandato curl en la dirección IP privada de la instancia de la derecha: curl A.B.C.D/name.

Hay un par de formas de instalar y utilizar python tal como se describe en README.md.

Cada pytest prueba SSH a una instancia de la izquierda y realiza una prueba de conectividad, como ejecutar un mandato curl a la instancia de la derecha. El entorno SSH predeterminado se utiliza para iniciar sesión en las instancias de la izquierda. Si ve resultados de prueba inesperados, pruebe la sección Resolución de problemas de pytest.

Asegúrese de que el directorio actual es vpc-transit.

cd ..
pwd; # .../vpc-transit

Pruebe la conectividad de red utilizando pytest:

pytest

Salida de ejemplo:

(vpc-transit) IBM-Cloud/vpc-transit % pytest
============================================ test session starts =============================================
platform darwin -- Python 3.11.5, pytest-7.4.4, pluggy-1.3.0 -- /Users/powellquiring/github.com/IBM-Cloud/vpc-transit/venv/bin/python
cachedir: .pytest_cache
rootdir: /Users/powellquiring/github.com/IBM-Cloud/vpc-transit
configfile: pytest.ini
testpaths: py
plugins: xdist-3.5.0
collected 31 items

py/test_transit.py::test_ping[l-spoke0        -> r-spoke0] PASSED                                      [  3%]
py/test_transit.py::test_ping[l-spoke0        -> r-enterprise-z1-worker] PASSED                        [  6%]
py/test_transit.py::test_ping[l-spoke0        -> r-transit-z1-worker] PASSED                           [  9%]
py/test_transit.py::test_ping[l-enterprise-z1-worker -> r-spoke0] PASSED                               [ 12%]
py/test_transit.py::test_ping[l-enterprise-z1-worker -> r-enterprise-z1-worker] PASSED                 [ 16%]
py/test_transit.py::test_ping[l-enterprise-z1-worker -> r-transit-z1-worker] PASSED                    [ 19%]
py/test_transit.py::test_ping[l-transit-z1-worker -> r-spoke0] PASSED                                  [ 22%]
py/test_transit.py::test_ping[l-transit-z1-worker -> r-enterprise-z1-worker] PASSED                    [ 25%]
py/test_transit.py::test_ping[l-transit-z1-worker -> r-transit-z1-worker] PASSED                       [ 29%]
py/test_transit.py::test_curl[l-spoke0        -> r-spoke0] PASSED                                      [ 32%]
py/test_transit.py::test_curl[l-spoke0        -> r-enterprise-z1-worker] PASSED                        [ 35%]
py/test_transit.py::test_curl[l-spoke0        -> r-transit-z1-worker] PASSED                           [ 38%]
py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke0] PASSED                               [ 41%]
py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-enterprise-z1-worker] PASSED                 [ 45%]
py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-transit-z1-worker] PASSED                    [ 48%]
py/test_transit.py::test_curl[l-transit-z1-worker -> r-spoke0] PASSED                                  [ 51%]
py/test_transit.py::test_curl[l-transit-z1-worker -> r-enterprise-z1-worker] PASSED                    [ 54%]
py/test_transit.py::test_curl[l-transit-z1-worker -> r-transit-z1-worker] PASSED                       [ 58%]
py/test_transit.py::test_curl_dns[l-spoke0        -> r-abc-enterprise-z1-worker.abc-enterprise.example.com] PASSED [ 61%]
py/test_transit.py::test_curl_dns[l-spoke0        -> r-abc-transit-z1-worker.abc-transit.example.com] PASSED [ 64%]
py/test_transit.py::test_curl_dns[l-enterprise-z1-worker -> r-abc-enterprise-z1-worker.abc-enterprise.example.com] PASSED [ 67%]
py/test_transit.py::test_curl_dns[l-enterprise-z1-worker -> r-abc-transit-z1-worker.abc-transit.example.com] PASSED [ 70%]
py/test_transit.py::test_curl_dns[l-transit-z1-worker -> r-abc-enterprise-z1-worker.abc-enterprise.example.com] PASSED [ 74%]
py/test_transit.py::test_curl_dns[l-transit-z1-worker -> r-abc-transit-z1-worker.abc-transit.example.com] PASSED [ 77%]
py/test_transit.py::test_vpe_dns_resolution[cos spoke0 -> transit s3.direct.us-south.cloud-object-storage.appdomain.cloud] PASSED [ 80%]
py/test_transit.py::test_vpe_dns_resolution[cos enterprise-z1-worker -> transit s3.direct.us-south.cloud-object-storage.appdomain.cloud] PASSED [ 83%]
py/test_transit.py::test_vpe_dns_resolution[cos transit-z1-worker -> transit s3.direct.us-south.cloud-object-storage.appdomain.cloud] PASSED [ 87%]
py/test_transit.py::test_vpe[cos spoke0 -> transit s3.direct.us-south.cloud-object-storage.appdomain.cloud] PASSED [ 90%]
py/test_transit.py::test_vpe[cos enterprise-z1-worker -> transit s3.direct.us-south.cloud-object-storage.appdomain.cloud] PASSED [ 93%]
py/test_transit.py::test_vpe[cos transit-z1-worker -> transit s3.direct.us-south.cloud-object-storage.appdomain.cloud] PASSED [ 96%]
py/test_transit.py::test_lb[lb0] SKIPPED (got empty parameter set ['lb'], function test_lb at /Use...) [100%]

======================================= 30 passed, 1 skipped in 42.36s =======================================

Cada SSH de prueba a la instancia en el lado izquierdo de la flecha '->' y accede al lado derecho de la flecha de la siguiente manera:

• test_ping-Dirección IP de ping.
• test_curl-Dirección IP de Curl.
• test_curl_dns- Curl el nombre DNS.
• test_vpe_dns_resolution-Verifique que el nombre DNS del punto final privado virtual (VPE) de VPC se resuelva en una dirección IP en el bloque CIDR de la nube (esta prueba no accede realmente al lado derecho).
• test_vpe-Ejercer el recurso utilizando el nombre DNS y la herramienta específica de recursos según sea necesario.

Todas las pruebas deben pasar excepto para la prueba del equilibrador de carga (lb), que se omite en esta configuración.

Investigue Transit Gateway

Este diagrama tiene una línea verde que muestra la vía de acceso de tráfico desde la instancia de Power a la instancia de empresa:

Inspeccione el tránsito Transit Gateway:

• Abra Pasarela de tránsito y seleccione $BASENAME-tgw.
• Hay dos conexiones:
  1. VPC de tránsito.
  2. Spoke0 (Power Systems Virtual Server).
• Pulse BGP y Generar informe. El CIDR de empresa, 192.168.0.0/24, es anunciado por la VPC de tránsito.

Comprenda la ruta de datos de Power a la empresa a través de la VPC de tránsito

El paso anterior ha demostrado cómo Transit Gateway ha aprendido las rutas de empresa necesarias para que la instancia de Power alcance la VPC de tránsito al enviar a una dirección IP de empresa como 192.168.0.4. El direccionamiento de entrada de VPC en la VPC de tránsito direcciona el tráfico directamente a la instancia de VPN.

1. Vaya a la nube privada virtual.
2. Pulse VPC a la izquierda.
3. Pulse la VPC de tránsito.
4. Desplácese hacia abajo y pulse Gestionar tablas de direccionamiento.
5. Pulse la tabla de direccionamiento vpn-ingress.

En el recuadro Tráfico, Acepta rutas desde indica Pasarela VPN. Esta configuración permite a la pasarela VPN crear automáticamente una ruta en esta tabla de direccionamiento "y" ajustar la siguiente dirección de salto de la ruta según sea necesario.

El estado actual de esta ruta se puede encontrar en la tabla Rutas. Indica que el tráfico dirigido a 192.168.0.0/24 se reenviará a una dirección de salto siguiente en la VPC. Anote la dirección IP del salto siguiente. Puede encontrarlo en el servicio VPN de VPC.

1. Vaya a VPN y seleccione la pasarela VPN de tránsito.
2. Inspeccione la sección Miembros de pasarela. La IP privada de la IP activa debe coincidir con el salto siguiente indicado anteriormente.

Para garantizar la alta disponibilidad, el servicio VPN mantiene la dirección IP del salto siguiente coherente con la dirección IP activa de los recursos VPN disponibles.

Verificar resolución de Power DNS

Este diagrama tiene una línea azul que muestra la cadena de reenvío de resolución DNS utilizada por la instancia de Power® Virtual Server.

Los $BASENAME que se muestran a continuación son abc; sustituya en su propio $BASENAME. En el shell de instancia de Power® Virtual Server:

abc-spoke0:~ # BASENAME=abc
abc-spoke0:~ # dig  abc-enterprise-z1-worker.$BASENAME-enterprise.com

; <<>> DiG 9.16.44 <<>> abc-enterprise-z1-worker.abc-enterprise.com
;; global options: +cmd
;; Got answer:
...
;; ANSWER SECTION:
abc-enterprise-z1-worker.abc-enterprise.com. 2454 IN A 192.168.0.4
...

Un mandato curl devuelve datos de la empresa:

curl $BASENAME-enterprise-z1-worker.$BASENAME-enterprise.com/name

Ejemplo:

abc-spoke0:~ # curl $BASENAME-enterprise-z1-worker.$BASENAME-enterprise.com/name
abc-enterprise-z1-worker

Es posible verificar la vía de acceso de reenvío de DNS que se muestra en la línea azul. En primer lugar, busque el servidor DNS que está resolviendo la dirección:

1. Vaya a Power Systems Virtual Server y seleccione el espacio de trabajo.
2. Pulse Subredes a la izquierda.
3. Pulse la subred privada.
4. Uno de los Servidores DNS es 10.1.15.xy. Anote la IP exacta.

Esta es la dirección de un solucionador personalizado deDNS Services. Los bits iniciales de la dirección, 10.1.15 indica que está en la VPC de tránsito. Localice la instancia de DNS y el programa de resolución personalizado:

1. Vaya a la lista de recursos.
2. Abra la sección Redes y pulse la instancia de tránsito del servicio DNS.
3. En la instancia de DNS de tránsito, pulse Resolver personalizado a la izquierda.
4. Haga clic en el resolver personalizado para abrir la página de detalles.

Hacer coincidir la dirección IP del servidor DNS anotada anteriormente (que se encuentra en la subred privada de Power) con las direcciones IP de Resolver ubicaciones.

El diagrama muestra una flecha de este programa de resolución de DNS a la red de la empresa. Verifíquelo siguiendo las reglas de reenvío:

1. Pulse la pestaña Reenvío de reglas en la parte superior.
2. Tenga en cuenta que las reglas de reenvío para el subdominio $BASENAME-enterprise.com se reenvían a los programas de resolución de empresa que tienen direcciones 192.168.0.xy. Estas son las direcciones IP de los programas de resolución DNS de la empresa. Puede verificarlos localizando el servicio DNS para la empresa en la lista de recursos.

Comprender la pasarela de punto final privado virtual de VPC

IBM Cloud VPE for VPC le permite conectarse a los servicios IBM Cloud compatibles desde su red VPC utilizando las direcciones IP de su elección, que se asignan desde una subred dentro de su VPC. Se ha suministrado un Object Storage. Cuando se ha suministrado un VPE for VPC para Object Storage, se ha creado un registro DNS en el servicio DNS. Busque el nombre DNS para Object Storage en la VPC de tránsito:

1. Vaya a las pasarelas de punto final privado virtual de VPC.
2. Seleccione la pasarela de punto final privado virtual de VPC $BASENAME-transit-cos.

• Anote la dirección IP del recurso adjunto. Es 10.1.15.x en la zona de VPC de tránsito 1.
• Anote Punto final de servicio. Es específico de la región: s3.direct.us-south.cloud-object-storage.appdomain.cloud.

En el shell de instancia de Power® Virtual Server, utilice el mandato dig con el nombre DNS para buscar la dirección IP. He aquí un ejemplo (abreviado):

abc-spoke0:~ # dig s3.direct.us-south.cloud-object-storage.appdomain.cloud

; <<>> DiG 9.16.44 <<>> s3.direct.us-south.cloud-object-storage.appdomain.cloud
...
;; ANSWER SECTION:
s3.direct.us-south.cloud-object-storage.appdomain.cloud. 900 IN	A 10.1.15.132
...

En este caso, 10.1.15.132 es la dirección IP de Object Storage a través de la pasarela de punto final privado virtual.

Imponer seguridad de VPC

Las VPC tienen listas de control de acceso de red (ACL)] (/docs/vpc?topic=vpc-using-acls) para subredes y grupos de seguridad para interfaces de red que se pueden configurar para limitar el acceso a los recursos de red.

Introduzca una regla de grupo de seguridad para restringir el acceso a la pasarela de punto final privado virtual de VPC desde solo las instancias de Power Virtual Server.

En el shell de instancia de Power® Virtual Server, utilice el mandato curl para acceder a una instancia de VPC en la VPC de tránsito:

BASENAME=abc
curl $BASENAME-transit-z1-worker.$BASENAME-transit.com/name

Localice el grupo de seguridad y refuerce las reglas.

• Vaya a Instancias de servidor virtual para VPC.
• Pulse la instancia de tránsito.
• Desplácese hacia abajo hasta Interfaces de red y pulse la entrada en Grupos de seguridad.
• Pulse la pestaña Reglas en la página de propiedades Grupo de seguridad.
• Localice la fuente 10.0.0.0/8. Pulse el menú de hamburguesa de la derecha y, a continuación, pulse Editar.
• Cambie temporalmente el CIDR a 10.0.0.0/32.

De nuevo en el shell de instancia de Power® Virtual Server, repita el mandato curl. El comando no se completa:

curl $BASENAME-transit-z1-s0.$BASENAME-transit.com/name

Determine la dirección IP en el shell:

hostname -I

Ejemplo:

abc-spoke0:~ # hostname -I
10.1.0.37 192.168.230.234

El primer número 10.1.0.x es la dirección IP privada. Vuelva a la pestaña Grupo de seguridad de VPC del navegador, edite la regla de grupo de seguridad y cámbielo a address/32 (por ejemplo, 10.1.0.37/32).

Vuelva a intentar curl y debería funcionar.

curl $BASENAME-transit-z1-s0.$BASENAME-transit.com/name

De nuevo en la regla de grupo de seguridad, vuelva a cambiar el bloque CIDR al valor original 10.0.0.0/8.

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

Es posible que su arquitectura no sea 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:

• Utilice un equilibrador de carga VPC](/docs/openshift?topic=openshift-vpclb-about) para equilibrar el tráfico entre varias instancias Power Virtual Server.
• 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.

Contenido relacionado

• ¿Ya tiene un espacio de trabajo Power Virtual Server y solo necesita instalar un sitio de VPC en la VPN del sitio? Consulte Sitio a sitio dePowerVPN.
• 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,
• Concentrador privado y hablado con VNF transparente y tráfico de radio a radio