Objetivos

• Acessar um ambiente de nuvem privada virtual (VPC) a partir de um data center no local
• Acesse com segurança os serviços em nuvem usando gateways de endpoint privados
• Use DNS no local para acessar recursos em nuvem sobre VPN

O diagrama a seguir mostra os recursos criados por este tutorial

Uma configuração de Terraform criará os recursos a seguir:

1. A infraestrutura (VPC, sub-redes, grupos de segurança com regras, Network ACL e VSIs).
2. Os gateways de terminal privado Object Storage e Databases for PostgreSQL para serviços de dados.
3. O software de gateway do IPsec de software livre do strongSwan é usado no local para estabelecer a conexão de VPN com o ambiente de nuvem.
4. Um Gateway VPC/VPN é provisionado para permitir a conectividade privada entre recursos no local e recursos em nuvem.
5. O resolvedor DNS no local é conectado à localização do resolvedor DNS em nuvem para permitir o acesso TLS a recursos em nuvem, incluindo o acesso a gateways de terminal privado virtual por meio de uma VPN.

Antes de Iniciar

Este tutorial requer:

• CLI do IBM Cloud,
  • IBM Cloud Schematics plugin (schematics),
• jq para consultar arquivos JSON,
• git to optionally clone source code repository,
• Terraform CLI to optionally run Terraform on your desktop instead of the Schematics service.

Você encontrará instruções para fazer download e instalar essas ferramentas para o seu ambiente operacional no guia Introdução aos tutoriais.

O data center no local neste tutorial será simulado usando um VSI dentro de um VPC.

O mecanismo preferencial para conectar VPCs é Transit Gateway. A simulação de um ambiente no local com VPC, VSI e VPN é usada apenas para ilustração.

Além disso:

• Verifique as permissões do usuário. Certifique-se de que sua conta do usuário tenha permissões suficientes para criar e gerenciar recursos VPC. Para obter uma lista das permissões necessárias, consulte Concessão das permissões necessárias para os recursos da VPC.
• Você precisa de uma chave SSH para se conectar aos servidores virtuais. Se você não tiver uma chave SSH, consulte as instruções para criar uma chave.

Use Schematics para criar os recursos

1. Efetue login na IBM Cloud.
2. Navegue até Criar Schematics Workspaces Na seção Specify Template (Especificar modelo ), verifique:
   1. URL do repositório é https://github.com/IBM-Cloud/vpc-tutorials/tree/master/vpc-site2site-vpn
   2. A versão do Terraform é terraform_v1.2
3. Em Detalhes da área de trabalho,
   1. Forneça um nome de área de trabalho: vpnsts.
   2. Escolha um Resource Group e um Location.
   3. Clique em Avançar.
4. Verifique os detalhes e, em seguida, clique em Criar.
5. Sob a seção Variáveis, forneça os valores necessários (resource_group_name, ssh_key_name) clicando no menu overflow e selecionando Editar para cada linha. O valor para a variável manutenção deve ser configurado como true.
6. Role até a parte superior da página e clique em Aplicar plano. Verifique os logs para ver o status dos serviços criados.

Explore os recursos que foram criados clicando abaixo e selecionando a instância com prefixo correspondente. Localize todos os recursos no diagrama acima.

• IBM Cloud VPC
• Virtual Servers for VPC
• IBM® VPN
• VPE for VPC
• Databases for PostgreSQL instância em Bancos de Dados
• Object Storage

Verificar a conectividade

A saída do espaço de trabalho Schematics contém variáveis que podem ser usadas para verificar a conectividade da VPN.

1. Obtenha a lista de áreas de trabalho, anote a coluna de ID, configure a variável shell:

   ibmcloud schematics workspace list
   

2. Configure a variável WORKSPACE_ID:

   WORKSPACE_ID=YOUR_WORKSPACE_ID
   

3. Obtenha as variáveis de ambiente para os recursos em nuvem:

   ibmcloud schematics output --id $WORKSPACE_ID --output json | jq -r '.[0].output_values[].environment_variables.value'
   

4. A saída se parecerá com algo como o seguinte. Copie / cole estes resultados em sua casca, a fim de configurá-los no ambiente:

   IP_FIP_ONPREM=169.48.x.x
   IP_PRIVATE_ONPREM=10.0.0.4
   IP_PRIVATE_CLOUD=10.1.1.4
   IP_FIP_BASTION=52.118.x.x
   IP_PRIVATE_BASTION=10.1.0.4
   IP_DNS_SERVER_0=10.1.0.5
   IP_DNS_SERVER_1=10.1.1.6
   IP_ENDPOINT_GATEWAY_POSTGRESQL=10.1.1.9
   IP_ENDPOINT_GATEWAY_COS=10.1.1.5
   HOSTNAME_POSTGRESQL=a43ddb63-dcb1-430a-a2e4-5d87a0dd12a6.6131b73286f34215871dfad7254b4f7d.private.databases.appdomain.cloud
   HOSTNAME_COS=s3.direct.us-south.cloud-object-storage.appdomain.cloud
   PORT_POSTGRESQL=32525
   

5. Agora é possível efetuar SSH em cada uma das instâncias seguindo caminhos diferentes, incluindo saltando pela VPN. O diagrama mostra os caminhos de comunicação executados pelas etapas.

   Se a chave SSH não for a padrão para SSH, você poderá definir a opção -I PATH_TO_PRIVATE_KEY_FILE ou consultar o manual de referência do SSH para obter mais ajuda.

1. Teste de acesso ao VSI no local:

   ssh root@$IP_FIP_ONPREM
   

2. Teste de acesso ao bastion da nuvem:

   ssh root@$IP_FIP_BASTION
   

3. Teste de acesso ao VSI em nuvem por meio de bastion:

   ssh -J root@$IP_FIP_BASTION root@$IP_PRIVATE_CLOUD
   

4. Teste de acesso ao VSI em nuvem por meio de túnel VPN, bastion e no local:

   ssh -J root@$IP_FIP_ONPREM,root@$IP_FIP_BASTION root@$IP_PRIVATE_CLOUD
   

5. Teste de acesso ao VSI no local por meio de bastion, VSI em nuvem, túnel VPN:

   ssh -J root@$IP_FIP_BASTION,root@$IP_PRIVATE_CLOUD root@$IP_PRIVATE_ONPREM
   

Verificar resolução de DNS

A resolução de DNS no local foi configurada para usar o local do resolvedor de DNS IBM Cloud VPC. Isso permite que os serviços em nuvem sejam acessados pelo nome e resolvidos para os endereços IP dos gateways do terminal privado.

Teste de resolução de DNS para o Postgresql e o armazenamento de objetos por meio do gateway do terminal virtual. Os dois caminhos que estão sendo verificados são mostrados no diagrama abaixo:

1. Acesse o VSI no local.

   ssh root@$IP_FIP_ONPREM
   

2. Copie e cole três (3) das variáveis capturadas anteriormente: HOSTNAME_POSTGRESQL, HOSTNAME_COS, PORT_POSTGRESQL.

3. Execute um comando dig para confirmar a resolução para a instância do banco de dados através do Virtual Endpoint Gateway ..

   dig $HOSTNAME_POSTGRESQL
   

4. Verificar a conectividade com o banco de dados, emitindo um comando telnet. Ele deve exibir "conectado".

   telnet $HOSTNAME_POSTGRESQL $PORT_POSTGRESQL
   

5. Uma vez conectado ao banco de dados, emita um Ctrl+C para se desconectar.

6. Execute um comando dig para confirmar a resolução para a instância de armazenamento de objetos em nuvem através do Virtual Endpoint Gateway.

   dig $HOSTNAME_COS
   

7. Verificar a conectividade com a instância de armazenamento de objetos em nuvem, emitindo um comando telnet. Ele deve exibir "conectado".

   telnet $HOSTNAME_COS 443
   

8. Uma vez conectado à instância de armazenamento de objetos em nuvem, emita um Ctrl+C para se desconectar.

Se houver algum problema, consulte a seção Resolução de problemas no repositório github.

Opcionalmente, expanda o tutorial

Deseja incluir ou estender este tutorial? Aqui estão algumas ideias:

• No repositório GitHub há um aplicativo que pode ser implementado que usa o banco de dados e armazenamento de objetos em nuvem. Instruções sobre como implementar estão no LEIA-ME.
• Se você implementou o aplicativo inclua uma zona de DNS para o aplicativo.
• Execute o aplicativo em vários Virtual Servers for VPC e adiciona um balanceador de carga para distribuir o tráfego de microserviço de entrada.

Remover recursos

1. Navegue até Áreas de trabalho do Schematics e clique em sua área de trabalho
2. Clique em Ações... > Destruir recursos
3. Clique em Ações ... > Excluir área de trabalho

Conteúdo relacionado

• Referência do plug-in da CLI do IBM Cloud para VPC
• VPC usando as APIs de REST
• Tutorial da solução: Acessar instâncias remotas de forma segura com um host bastion