Pareamento Remoto de VCN por meio de um DRG Atualizado
Este tópico trata do pareamento remoto de VCNs.
Nesse caso, remoto significa que as VCNs (redes virtuais na nuvem) são anexadas a outro gateway de roteamento dinâmico (DRG) e que o DRG pode residir em outra região ou possivelmente na mesma região. Se as VCNs que você deseja conectar estiverem na mesma região e conectadas ao mesmo DRG, consulte Pareamento Local de VCN por Meio de um DRG Atualizado.
Esse cenário está disponível para um DRG legado ou atualizado, com a exceção de que os DRGs legados não suportam a conexão de DRGs em diferentes tenancies ou a anexação de várias VCNs. Consulte Versões do DRG para obter detalhes sobre as versões do DRG.
Antes de implementar este cenário, certifique-se de que:
- A VCN A é anexada ao DRG A
- VCN B é anexada ao DRG B
- A configuração de roteamento em ambos os DRGs está usando tabelas de roteamento padrão
- Permissões apropriadas do IAM são aplicadas para VCNs que estão nas mesmas tenancies ou em tenancies diferentes
Visão Geral do Pareamento Remoto de VCNs
O pareamento remoto de VCN é o processo de conexão de duas VCNs em regiões diferentes. O peering permite que os recursos das VCNs se comuniquem usando endereços IP privados sem rotear o tráfego pela internet ou por meio de uma rede on-premises. As VCNs podem estar na mesma tenancy do Oracle Cloud Infrastructure ou em outras. Sem pareamento, uma VCN precisaria de um gateway de Internet e de endereços IP públicos para as instâncias que precisam se comunicar com outra VCN em outra região.
Resumo dos Componentes do serviço Networking para Peering Remoto
De alto nível, os componentes do serviço Networking necessários para um pareamento remoto incluem:
-
Duas VCNs com CIDRs que não se sobrepõem, em regiões diferentes.
Observação
Nenhum CIDR da VCN pode ser sobreposto
As duas VCNs no relacionamento de pareamento não pode ter CIDRs sobrepostos. Além disso, se uma VCN específica tiver vários relacionamentos de pareamento, essas outras VCNs não poderão ter CIDRs que se sobreponham entre si. Por exemplo, se a VCN-1 for pareada com a VCN-2 e também com a VCN-3, a VCN-2 e a VCN-3 não deverão ter CIDRs que se sobreponham.
Se você estiver configurando esse cenário, deverá atender a esse requisito no estágio de planejamento. É provável que haja problemas de roteamento quando ocorrerem CIDRs sobrepostos, mas as operações da Console ou da API não impedem que você crie uma configuração que cause problemas.
- Um DRG (Dynamic Routing Gateway) anexado a cada VCN no relacionamento de pareamento. Uma VCN já tem um DRG se você estiver usando um túnel IPSec da VPN Local a Site ou um circuito virtual privado Oracle Cloud Infrastructure FastConnect.
- Uma conexão de pareamento remoto (RPC) em cada DRG no relacionamento de pareamento.
- Uma conexão entre essas duas RPCs.
- Suporte a regras de roteamento para permitir que o tráfego flua pela conexão e somente entre sub-redes selecionadas nas respectivas VCNs (se desejado).
- Suporte a regras de segurança para controlar os tipos de tráfego permitidos entre as instâncias nas sub-redes que precisam se comunicar com a outra VCN.
O diagrama a seguir ilustra os componentes.
Uma VCN só poderá usar as RPCs conectadas para acessar VNICs na outra VCN ou em uma rede on-premises se o DRG tiver uma conexão local. Por exemplo, se o VCN-1 no diagrama anterior tiver um gateway de internet, as instâncias da VCN-2 não poderão usá-lo para enviar tráfego para os pontos finais na internet. Para obter mais informações, consulte Implicações Importantes do Pareamento.
Implicações Importantes do Pareamento
Se você ainda não tiver feito, leia Implicações Importantes do Pareamento para entender o controle de acesso, a segurança e as implicações de desempenho das VCNs pareadas.
O pareamento de VCNs em diferentes tenancies tem algumas complicações de permissões que precisam ser resolvidas em ambas as tenancies. Consulte Políticas do Serviço IAM para Roteamento entre VCNs para obter detalhes sobre as permissões necessárias.
Spoke para Spoke: Pareamento Remoto com Roteamento de Trânsito (Somente DRGs Legados)
O cenário que esta seção menciona ainda é suportado, mas recomendamos que você use o método de roteamento de trânsito do DRG descrito em Roteando tráfego por meio de um appliance virtual de rede central.
Imagine que em cada região você tenha diversas VCNs em um layout hub-and-spoke, conforme mostrado no diagrama a seguir. Esse tipo de layout dentro de uma região é abordado com detalhes em Roteamento de Trânsito dentro de uma VCN hub. As VCNs spoke em uma região são pareadas localmente com a VCN hub na mesma região, usando gateways de pareamento locais .
Você pode configurar o pareamento remoto entre as duas VCNs hubs. Você então poderá configurar também o roteamento de trânsito do DRG e de LPGs da VCN hub, conforme descrito em Roteamento de Trânsito dentro de uma VCN hub. Essa instalação permite que uma VCN de spoke em uma região se comunique com uma ou mais VCNs de spoke na outra região sem precisar de uma conexão remota de pareamento diretamente entre essas VCNs.
Por exemplo, você pode configurar o roteamento de forma que os recursos na VCN-1-A possam se comunicar com recursos na VCN-2-A e na VCN-2-B por meio das VCNs hubs. Dessa forma, a VCN 1-A não precisa ter um pareamento remoto separado com cada uma das VCNs spoke na outra região. Você também pode configurar o roteamento para que a VCN-1-B possa se comunicar com as VCNs spoke na região 2, sem precisar de pareamentos remotos específicos para eles.
Spoke para Spoke: Pareamento Remoto com Roteamento de Trânsito (DRG Atualizado)
O cenário desta seção usa o método de roteamento de trânsito do DRG descrito em Roteando tráfego por meio de um appliance virtual de rede central.
Imagine que em cada região você tenha diversas VCNs em um layout hub-and-spoke, conforme mostrado no diagrama a seguir. Esse tipo de layout dentro de uma região é abordado com detalhes em Roteamento de Trânsito dentro de uma VCN hub. As VCNs spoke na região são pareadas localmente com o par DRG/VCN hub na mesma região por mútua conexão com o DRG.
Você pode configurar pareamento remoto entre duas VCNs de hub. Você também pode configurar um roteamento de trânsito para o DRG da VCN hub, conforme discutido em Roteamento de tráfego por meio de um appliance virtual da rede central. Essa instalação permite que uma VCN de spoke em uma região se comunique com uma ou mais VCNs de spoke na outra região sem precisar de uma conexão remota de pareamento diretamente entre essas VCNs.
Por exemplo, você pode configurar o roteamento de forma que os recursos na VCN-1-A possam se comunicar com recursos na VCN-2-A e na VCN-2-B por meio das VCNs hubs. Dessa forma, a VCN 1-A não precisa ter um pareamento remoto separado com cada uma das VCNs spoke na outra região. Você também pode configurar o roteamento para que a VCN-1-B possa se comunicar com as VCNs spoke na região 2, sem precisar de pareamentos remotos específicos para eles.
Conceitos Importantes sobre Pareamento Remoto
Os conceitos a seguir ajudam a compreender os conceitos básicos do pareamento de VCNs e como estabelecer um pareamento remoto.
- PEERING
- Um pareamento é um relacionamento de pareamento único entre duas VCNs. Exemplo: Se a VCN-1 for pareada com outras duas VCNs, haverá dois pareamentos. A palavra remoto no termo pareamento remoto indica que as VCNs estão em diferentes regiões. Para esse método de pareamento remoto, as VCNs podem estar na mesma tenancy ou em tenancies diferentes.
- VCN ADMINISTRATORS
- Em geral, o pareamento de VCNs só poderá ocorrer se os dois administradores das VCNs estiverem de acordo com esse pareamento. Na prática, os dois administradores devem:
- ACCEPTOR AND REQUESTOR
- Para implementar as políticas do IAM necessárias para pareamento, os dois administradores de VCN devem selecionar um administrador para ser o solicitante e o outro para ser o aceitador. O solicitante deve ser a moeda para iniciar a solicitação para conectar as duas RPCs. Por sua vez, o aceitador deve criar uma política específica do IAM que dê ao solicitante permissão para se conectar com RPCs no compartimento do aceitador. Sem essa política, a solicitação do solicitante para conexão falhará.
- REGION SUBSCRIPTION
- Para parear uma VCN em outra região, uma tenancy deve estar inscrita primeiro nessa região. Para obter informações sobre inscrições em regiões, consulte Gerenciando Regiões.
- CONEXÃO DE PAREAMENTO REMOTO (RPC)
- Uma conexão de peering remoto (RPC) é um componente que você cria no DRG anexado à VCN. O trabalho da RPC é atuar como um ponto de conexão para uma VCN remotamente pareada. Como parte da configuração de VCNs, cada administrador deve criar uma RPC para o DRG de sua respectiva VCN. Um DRG deve ter uma RPC separada para cada pareamento remoto que ele estabelece para a VCN. Para continuar o exemplo anterior: o DRG na VCN-1 teria duas RPCs para parear com outras duas VCNs. Na API, uma RemotePeeringConnection é um objeto que contém informações sobre o pareamento. Não é possível reutilizar uma RPC para estabelecer outro pareamento posteriormente.
- CONNECTION BETWEEN TWO RPCS
- Quando o solicitante começa a solicitação para par (na Console ou API), ele está efetivamente pedindo para conectar as duas RPCs. O solicitante deve ter informações para identificar cada RPC (como a região e o OCID da RPC).
- ROUTING TO THE DRG
- Como parte da configuração das VCNs, cada administrador deve atualizar o roteamento da VCN para permitir que o tráfego flua entre as VCNs. Para cada sub-rede que precisa se comunicar com a outra VCN, você atualiza a tabela de roteamento da sub-rede. A regra de roteamento especifica o CIDR do tráfego do destino e o DRG como o destino. O DRG roteia tráfego que corresponde a essa regra para o outro DRG, o que, por sua vez, roteia esse tráfego para o próximo salto na outra VCN.
-
Callout 1: Tabela de Roteamento da Sub-rede A CIDR de Destino Destino da Rota 0.0.0.0/0 Gateway de Internet 192.168.0.0/16 DRG-1 Callout 2: Tabela de Roteamento da Sub-rede X CIDR de Destino Destino da Rota 10.0.0.0/16 DRG-2 - REGRAS DE SEGURANÇA
- Cada sub-rede em uma VCN tem uma ou mais listas de segurança que controlam o tráfego de entrada e de saída das VNICs da sub-rede no nível do pacote. Você pode usar listas de segurança para controlar o tipo de tráfego permitido com a outra VCN. Como parte da configuração das VCNs, cada administrador deve decidir quais sub-redes em sua própria VCN precisam se comunicar com VNICs na outra VCN e atualizar as listas de segurança de suas sub-redes adequadamente.
Implicações Importantes do Pareamento
Se você ainda não tiver feito, leia Implicações Importantes do Pareamento para entender o controle de acesso, a segurança e as implicações de desempenho das VCNs pareadas.
Configurando o Pareamento Remoto
Esta seção abrange o processo geral para configurar o pareamento entre duas VCNs em diferentes regiões.
O seguinte procedimento pressupõe que:
- A tenancy está inscrita na região da outra VCN. Caso contrário, consulte Gerenciando Regiões.
- Você já tem uma VCN anexada ao DRG. Se você não quiser, consulte Gateways de Roteamento Dinâmico.
- Você já configurou as políticas obrigatórias do IAM para a conexão. As políticas do IAM para pareamento remoto na mesma tenancy e entre tenancies são diferentes. Consulte Políticas do Serviço IAM para Roteamento entre VCNs
Visão geral das etapas obrigatórias:
- Crie os RPCs: cada administrador de RPC cria um LPG para o DRG de sua própria VCN.
- Compartilhe informações: os administradores compartilham as informações básicas necessárias.
- Estabeleça a conexão: o solicitante conecta as duas RPCs (consulte Conceitos Importantes sobre Pareamento Remoto para obter a definição de solicitante e aceitador).
- Atualizar tabelas de roteamento: Cada administrador atualiza as tabelas de roteamento da VCN para permitir o tráfego entre as VCNs pareadas conforme pretendido.
- Atualizar regras de segurança: Cada administrador atualiza as regras de segurança da VCN para permitir o tráfego entre as VCNs pareadas conforme pretendido.
Se você quiser, os administradores poderão executar as tarefas 4 e 5 antes de estabelecer a conexão. Cada administrador precisa conhecer o bloco CIDR ou as sub-redes específicas da VCN do outro administrador e compartilhar essas informações na tarefa 2.
Cada administrador cria uma RPC para sua própria VCN. "Você" no procedimento a seguir significa um administrador (o aceitador ou o solicitante).
Política do IAM Necessária para Criar RPCs
Se os administradores já tiverem amplas permissões de administrador de rede (consulte Permitir que os administradores de rede gerenciem uma rede na nuvem), eles terão permissão para criar, atualizar e excluir RPCs. Caso contrário, veja a seguir um exemplo de política que fornece as permissões necessárias a um grupo chamado RPCAdmins. A segunda instrução é necessária porque a criação de uma RPC afeta o DRG ao qual ela pertence; portanto, o administrador deve ter permissão para gerenciar DRGs.
Allow group RPCAdmins to manage remote-peering-connections in tenancy
Allow group RPCAdmins to manage drgs in tenancy
- Na Console, verifique se você está exibindo o compartimento que contém o DRG ao qual deseja adicionar o RPC. Para obter informações sobre compartimentos e controle de acesso, consulte Controle de Acesso.
- Abra o menu de navegação e selecione Rede. Em Conectividade do cliente, selecione Gateway de roteamento dinâmico.
- Selecione o DRG no qual está interessado.
- Em Recursos, selecione Anexos de Conexões de Pareamento Remoto.
- Selecione Criar Conexão de Pareamento Remoto.
-
Informe o seguinte:
- Nome: um nome amigável para a RPC. Esse nome não precisa ser exclusivo e não pode ser alterado posteriormente na Console (mas você pode alterá-lo com a API). Evite inserir informações confidenciais.
- Criar no compartimento: o compartimento onde você deseja criar a RPC, se diferente do compartimento em que está trabalhando.
-
Selecione Criar Conexão de Pareamento Remoto.
Em seguida, a RPC é criada e exibida na página Conexões de Pareamento Remoto no compartimento escolhido.
- Se você for o aceitador, anote a região e o OCID da RPC para fornecê-los posteriormente ao solicitante.
- Se as duas VCNs estiverem em tenancies diferentes, registre o OCID desta tenancy (localizado no final da página na Console). Dê o OCID para o outro administrador posteriormente.
Esta tarefa é específica de uma conexão entre tenancies. Se a conexão estiver na mesma tenancy, você poderá pular para a próxima tarefa.
-
Se você for o aceitador, forneça estas informações ao solicitante (por exemplo, por e-mail ou por outro método fora de banda):
- A região na qual a VCN se encontra (a tenancy do solicitante deve estar inscrita nessa região).
- O OCID da RPC.
- Os blocos CIDR para sub-redes na VCN que você deseja disponibilizar para a outra VCN. O solicitante precisa dessas informações ao configurar o roteamento para a VCN do solicitante.
- Se as VCNs estiverem em tenancies diferentes: o OCID da tenancy do aceitador.
-
Se você for o solicitante, forneça estas informações ao aceitador:
- A região na qual a VCN está (a tenancy do aceitador deve estar inscrita nessa região).
- Se as VCNs estiverem na mesma tenancy: O nome do grupo do IAM concedeu permissão para criar uma conexão no compartimento do aceitador.
- Se as VCNs estiverem em tenancies diferentes: o OCID da tenancy do solicitante.
- Os blocos CIDR para sub-redes na VCN que você deseja disponibilizar para a outra VCN. O aceitador precisa dessas informações ao configurar o roteamento para a VCN do aceitador.
O solicitante deve executar esta tarefa.
Pré-requisito: o solicitante deve ter:
- A região em que a VCN do aceitador está (a tenancy do solicitante deverá estar inscrita na região).
- O OCID da RPC do aceitador.
- O OCID da tenancy do aceitante (somente se a VCN do aceitador estiver em outra tenancy)
Consulte as instruções em Conectando Duas Conexões de Pareamento Remoto. Outras tarefas envolvendo RPCs são explicadas no Remote Peering Management.
Como mencionado anteriormente, cada administrador pode executar essa tarefa antes ou depois de a conexão ser estabelecida.
Pré-requisito: Cada administrador deve conhecer o bloco CIDR ou sub-redes específicas da outra VCN.
Para cada VCN, decida quais sub-redes na VCN local precisam se comunicar com a outra VCN. Em seguida, atualize a mesa de roteamento de cada sub-redes para incluir uma nova regra que direcione o tráfego destinado à outra VCN do DRG local. Consulte Atualizando as Regras da Tabela de Roteamento de uma VCN e adicione uma regra de roteamento que use as seguintes definições:
- Tipo de Destino: Gateway de Roteamento Dinâmico. O DRG anexado à VCN é selecionado automaticamente como alvo e você não precisa especificar o alvo.
- Bloco CIDR de Destino: o bloco CIDR da outra VCN. O exemplo usa VCNs com 10.0.0.0/16 e 192.68.0.0/16. Se quiser, você poderá especificar uma sub-rede ou um subconjunto específico do CIDR da VCN pareada.
- Descrição: Uma descrição opcional da regra.
Qualquer tráfego da sub-rede com um destino que corresponda à regra é roteado para o DRG local. Para obter mais informações sobre a configuração de regras de roteamento, consulte Tabelas de Roteamento da VCN.
Sem o roteamento necessário, o tráfego não flui entre os DRGs pareados. Se ocorrer uma situação em que você precise interromper temporariamente o pareamento, poderá remover as regras de roteamento que permitem tráfego. Não é necessário excluir as RPCs.
Como mencionado anteriormente, cada administrador pode executar essa tarefa antes ou depois de a conexão ser estabelecida.
Pré-requisito: cada administrador deve ter o bloco CIDR ou as sub-redes específicas da outra VCN. Em geral, use o mesmo bloco CIDR usado na regra da tabela de roteamento na Tarefa D: Configurar as tabelas da rota.
Recomendamos adicionar as seguintes regras:
- Regras de entrada para os tipos de tráfego que você deseja permitir a partir do CIDR da outra VCN ou de sub-redes específicas. O exemplo usa VCNs com 10.0.0.0/16 e 192.68.0.0/16.
- Regra de saída para permitir o tráfego de saída da VCN local para a outra VCN. Se a sub-rede já tiver uma regra de saída ampla para todos os tipos de protocolos a todos os destinos (0.0.0.0/0), não será necessário adicionar uma especial para a outra VCN.
O procedimento a seguir usa listas de segurança, mas você pode, em vez disso, implementar as regras de segurança em um grupo de segurança de rede e criar todos os recursos da sub-rede nesse NSG.
Para cada VCN, decida quais sub-redes na VCN local precisam se comunicar com a outra VCN. Em seguida, atualize a lista da segurança de cada dessas sub-redes para incluir regras que permitam o tráfego pretendido de saída ou de entrada com o bloco CIDR ou a sub-rede da outra VCN. Consulte Atualizando Regras em uma Lista de Segurança e também Criando uma Lista de Segurança (para obter detalhes sobre as opções disponíveis para regras de segurança).
Consulte Regras de Segurança para obter informações gerais sobre regras.