Virtual Private Cloud:VPC peering connection

Conectar três VPCs

Ao configurar rotas para uma Conexão de Peering de VPC, você tem as seguintes opções:

• Definir o bloco CIDR de destino como todo o bloco CIDR da VPC par. Isso permite que todas as instâncias se comuniquem entre si e simplifica o gerenciamento de rotas.

• Configurar rotas mais granulares definindo o bloco CIDR de destino como o bloco CIDR de um vSwitch par ou o endereço IP de uma instância específica. Embora isso aumente a segurança, exige atualização manual da tabela de rotas sempre que novas instâncias precisarem se comunicar.

Por exemplo, a VPC1 possui rotas que apontam para o bloco CIDR do vSwitch 3 na VPC2 e para a ECS04 na VPC3. Consequentemente, os recursos na VPC1 só conseguem se comunicar com os recursos no bloco CIDR do vSwitch 3 e com a ECS04 pela rede privada. Já a VPC2 e a VPC3 possuem rotas que apontam para os blocos CIDR inteiros de suas VPCs pares, permitindo que todos os seus recursos se comuniquem entre si.

Conectar VPCs em uma topologia hub-and-spoke

Em uma topologia hub-and-spoke, as VPCs spoke podem acessar serviços na VPC hub, mas não se comunicam diretamente entre si. Os casos de uso para este modelo incluem:

• Isolamento departamental: VPCs de diferentes departamentos de negócios não se comunicam entre si, mas precisam acessar serviços compartilhados na VPC hub.

• Isolamento multilocatário: Um serviço é implantado em uma VPC dedicada e fornecido a vários locatários. A VPC de cada locatário pode se comunicar com a VPC do serviço, mas as VPCs dos locatários não podem se comunicar entre si.

Chaves de condição

Durante a autorização, o RAM utiliza o parâmetro AcceptingAliUid (ao criar uma conexão de peering) ou o parâmetro RequestingAliUid (ao aceitar uma conexão de peering) para consultar o Resource Directory da conta par. Em seguida, o RAM injeta as seguintes chaves de condição no contexto de autorização para avaliação pelo bloco Condition em sua política personalizada.

Nota:

Essas chaves de condição são injetadas apenas para as ações vpc:CreateVpcPeerConnection e vpc:AcceptVpcPeerConnection . Outras operações em conexões de peering de VPC, como consulta, modificação ou exclusão, não são afetadas.

Se uma solicitação for negada pela política, a API retornará o código de erro Forbidden.NoPermission . O campo NoPermissionType nos detalhes do erro será definido como ExplicitDeny . É possível rastrear a solicitação negada usando seu RequestId no ActionTrail .

Escolher uma política de restrição

Substitua os marcadores de posição, como o ID do Resource Directory, o caminho do resource directory ou o ID da conta, pelos valores reais da sua organização. Você pode encontrar seu ID do Resource Directory e o caminho do resource directory no Console de Gerenciamento de Recursos .

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "vpc:CreateVpcPeerConnection",
        "vpc:AcceptVpcPeerConnection"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "acs:TargetRDId": ["rd-xxxxxx"]
        }
      }
    }
  ]
}

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "vpc:CreateVpcPeerConnection",
        "vpc:AcceptVpcPeerConnection"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotLike": {
          "acs:TargetRDPath": ["rd-xxxxxx/r-xxxxxx/fd-xxxxxx/*"]
        }
      }
    }
  ]
}

Criar e anexar a política

Conexões de peering transfronteiriças são suportadas?

Sim, tanto conexões não transfronteiriças quanto transfronteiriças são suportadas.

• Não transfronteiriça: Conecta duas regiões dentro da China continental ou duas regiões fora da China continental.

• Transfronteiriça: Conecta uma região na China continental a uma região fora da China continental. Certifique-se de que sua conta tenha concluído o registro de nome real empresarial.

Por que não consigo selecionar a VPC de destino?

Certifique-se de que a região e a conta selecionadas correspondam à Region e ao Owner da VPC de destino.

A região do solicitante aparece no topo da página, e a conta atual é a solicitante. Você configura a conta e a região do receptor ao criar a conexão de peering.

Erro de permissão CDT ausente para usuários RAM

Um usuário RAM possui a permissão AliyunVPCFullAccess, mas recebe um erro indicando que a permissão cdt:GetCdtServiceStatus está ausente ao criar uma conexão de peering de VPC. Isso ocorre porque as conexões de peering de VPC dependem do serviço Cloud Data Transfer (CDT). Criar uma conexão de peering exige a chamada de APIs relacionadas ao CDT, portanto, apenas as permissões de VPC não são suficientes.

Conceda ao usuário RAM uma das seguintes permissões adicionais:

• AliyunCDTFullAccess: Concede acesso total ao serviço CDT.

• AliyunCDTReadOnlyAccess: Concede acesso somente leitura ao serviço CDT. Esta permissão é suficiente se o usuário precisar apenas criar conexões de peering e não precisar gerenciar recursos do CDT.

Falha de comunicação para instâncias ECS com docker

Se as configurações de roteamento e grupo de segurança estiverem corretas, esse problema geralmente é causado por um conflito entre o endereço da interface de rede do docker e o bloco CIDR de destino. Execute o comando ip addr para verificar se há conflitos.

Caso exista um conflito, siga estas etapas para modificar o bloco CIDR do docker e resolver o conflito com o bloco CIDR de destino.

• Parar o serviço docker ou modificar o bloco CIDR do docker interrompe os serviços de negócios. Realize esta operação fora do horário de pico.

• Ao modificar o bloco CIDR do docker, garanta que o novo bloco CIDR seja compatível com as configurações de rede de todos os contêineres e aplicativos existentes para evitar possíveis problemas de conectividade.

1. Execute o comando sudo systemctl stop docker para parar o serviço docker.

2. Execute o comando sudo vim /etc/docker/daemon.json para editar o arquivo de configuração do docker. Adicione o seguinte conteúdo ao arquivo e salve-o:

   O arquivo de configuração do docker geralmente está localizado em /etc/docker/daemon.json ou /etc/docker/daemon.conf . O nome exato do arquivo pode variar.

   {
       "bip":"New Docker CIDR block"
   }

3. Execute o comando sudo systemctl start docker para iniciar o serviço docker e garantir que as alterações tenham efeito.

Limitações

• Não é possível criar uma conexão de peering de VPC nos seguintes cenários:

  • As duas VPCs pertencem a contas em sites diferentes da Alibaba Cloud, por exemplo, uma conta no site da Alibaba Cloud China e uma conta no site Internacional da Alibaba Cloud.

• Uma conexão de peering de VPC não suporta roteamento transitivo.

  Por exemplo, se a VPC 1 estiver conectada à VPC 2 e à VPC 3 através de conexões de peering de VPC separadas, a VPC 2 e a VPC 3 não poderão se comunicar entre si através da VPC 1.

  

• Se uma VPC for compartilhada entre várias contas, apenas o proprietário do recurso poderá criar, modificar ou excluir uma conexão de peering de VPC. Os usuários do recurso não possuem essas permissões.

Faturamento

As conexões de peering de VPC intrarregionais são gratuitas, independentemente de as VPCs pertencerem à mesma conta ou a contas diferentes.

Para conexões de peering de VPC inter-regionais, o Cloud Data Transfer (CDT) cobra uma taxa de transferência de dados baseada no tráfego de saída.

• O preço unitário é determinado pelo par de regiões e pelo tipo de link selecionado. Dois tipos de link, Platinum e Gold, estão disponíveis para fornecer diferentes níveis de qualidade de transferência de dados.

• O ciclo de faturamento é horário. Se você alterar o tipo de link dentro de um ciclo de faturamento, a tarifa do nível de serviço mais alto será aplicada a todo o ciclo.

Máquina de estados da conexão de peering de VPC

Após um solicitante iniciar uma conexão de peering de VPC, ela passa por vários estados.

Ao criar uma conexão de peering de VPC entre VPCs na mesma conta, o sistema aceita automaticamente a solicitação e a conexão torna-se Activated.

Regiões suportadas

Cotas