Pareamento Remoto de VCN usando um DRG Legado
Este tópico trata do pareamento remoto de VCNs. Nesse caso, remoto significa que as VCNs residem em regiões diferentes. Se as VCNs que você deseja conectar estiverem na mesma região, consulte Pareamento de VCN Local usando LPGs (Local Peering Gateways).
Este artigo pressupõe que o DRG seja um DRG legado e recomendamos o método descrito em Pareamento Remoto de VCN por meio de um DRG Atualizado para qualquer DRG submetido a upgrade. Consulte Versões do DRG para obter uma explicação das versões do DRG.
Visão Geral do Pareamento Remoto de VCNs
Pareamento remoto de VCNs é o processo de conexão de duas VCNs em regiões diferentes (mas na mesma tenancy ). 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. 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 diferentes regiões que suportam pareamento remoto.
Observação
Não Deve Haver Sobreposição entre Todos os CIDRs da VCN
As duas VCNs na relacionamento de pareamento não devem ter CIDRs que se sobreponham. Além disso, se uma VCN específica tiver várias relações de pareamento, essas outras VCNs não deverão ter CIDRs sobrepostos 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.
- 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 rota para permitir que o tráfego flua pela conexão e apenas para selecionar sub-redes nas respectivas VCNs (se necessário).
- 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ó pode usar as RPCs conectadas para acessar VNICs na outra VCN ou em uma rede on-premises e não destinos fora das VCNs, como a internet. Por exemplo, se o VCN-1 no diagrama anterior tivesse um gateway de internet, as instâncias da VCN-2 não o poderiam usar para enviar tráfego para os pontos finais na internet. Para obter mais informações, consulte Implicações Importantes do Pareamento.
Spoke para Spoke: Pareamento Remoto com Roteamento de Trânsito
O cenário que esta seção menciona ainda é suportado, mas está obsoleto. Recomendamos que você use o método de roteamento de Trânsito de 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 específica 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 comunique-se 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.
Acordo Explícito Obrigatório dos Dois Lados
O pareamento entre duas VCNs requer um acordo explícito de ambas as partes na forma de políticas do Oracle Cloud Infrastructure Identity and Access Management que cada parte implementa para seu compartimento da própria VCN.
Conceitos Importantes sobre Pareamento Remoto
Os conceitos a seguir ajudam a entender os conceitos básicos de pareamento e como estabelecer um pareamento remoto.
- PEERING
- Um pareamento é um relacionamento de pareamento único entre duas VCNs. Exemplo: Se o VCN-1 for pareado com duas outras VCNs, haverá dois pareamentos. A palavra remoto no termo pareamento remoto indica que as VCNs estão em diferentes regiões.
- 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, isso significa que 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 como solicitante e o outro como aceitador. O solicitante deve ser aquele que inicia 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 a uma 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 específico 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. Isso significa que 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, atualize 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, que, por sua vez , roteia esse tráfego para o próximo salto na outra VCN.
-
Callout 3: 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 4: 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 da sub-rede para permitir o tráfego.
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 um Pareamento Remoto
Essa seção abrange o processo geral para configurar um pareamento entre duas VCNs em diferentes regiões.
O seguinte procedimento pressupõe que:
- Esta tenancy está inscrita na região da outra VCN. Caso contrário, consulte Gerenciando Regiões.
- Você já deverá ter um DRG anexado à VCN. Se você não quiser, consulte Gateways de Roteamento Dinâmico.
- 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.
- Configure as políticas do IAM necessárias para a conexão: os administradores configuram as políticas do IAM para ativar a conexão a ser estabelecida.
- 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 da rota: cada administrador atualiza as tabelas da rota da VCN para permitir o tráfego entre as VCNs ou sub-redes pareadas.
- Atualizar regras da segurança: cada administrador atualiza as regras da VCN para permitir o tráfego entre as VCNs ou as sub-redes pareadas.
Os administradores podem executar tarefas E e F antes de estabelecer a conexão. Cada administrador precisa conhecer o bloco CIDR ou sub-redes específicas da outra VCN e compartilhá-lo na tarefa B.
Cada administrador aceitador ou solicitante cria uma RPC para o DRG de sua própria VCN.
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
Consulte Criando uma Conexão de Pareamento Remoto e Gerenciamento de Pareamento Remoto para obter instruções gerais sobre como criar e trabalhar com RPCs. Se você for o aceitador, registre a região e o OCID da RPC e compartilhe essas informações com o solicitante. Se as duas VCNs estiverem em tenancies diferentes, cada administrador deverá registrar o OCID da tenancy (localizado na parte inferior da página na Console) e fornecer essas informações ao outro administrador.
Quando ambas as VCNs estiverem na mesma tenancy, mas em regiões diferentes, use as políticas fornecidas em Pareamento Remoto com um DRG Legado.
Se ambas as VCNs estiverem em tenancies diferentes, mas na mesma região, use as políticas fornecidas em Anexando a VCNs em Outras Tenancies.
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.
Consulte Criando uma Conexão de Pareamento Remoto para obter instruções gerais e use as informações fornecidas para o aceitador. Consulte Remote Peering Management para obter instruções gerais sobre como trabalhar com 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 da VCN ou o bloco CIDR para sub-redes específicas na outra VCN.
Para cada VCN, decida quais sub-redes na VCN precisam se comunicar com a outra VCN e atualize a tabela de roteamento (consulte Atualizando as Regras da Tabela de Roteamento de uma VCN) para cada uma dessas sub-redes a fim de incluir uma nova regra de roteamento que direcione o tráfego destinado à outra VCN para o DRG:
- 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. 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. Para obter mais informações sobre regras e tabelas de roteamento da VCN, consulte Tabelas de Roteamento da VCN.
Sem o roteamento necessário, o tráfego não flui entre os DRGs pareados. Caso ocorra uma situação em que você precise interromper temporariamente o pareamento, remova temporariamente 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 conhecer o bloco CIDR ou sub-redes específicas para compartilhar com a outra VCN. Em geral, use o mesmo bloco CIDR usado na regra de tabela de roteamento do procedimento Tarefa E: Configurar as tabelas de roteamento.
Adicione as seguintes regras:
- Regras de entrada para os tipos de tráfego que você deseja permitir da outra VCN, seja do CIDR da VCN ou apenas de sub-redes específicas.
- 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 para Todos os Destinos (como 0.0.0.0/0), você não precisará adicionar uma Regra 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 a VCN local, decida quais sub-redes na VCN precisam se comunicar com a outra VCN e atualize a lista de segurança para cada uma dessas sub-redes a fim de incluir regras que permitam o tráfego de saída ou de entrada com o bloco CIDR ou a sub-rede da outra VCN:
Para obter mais informações sobre regras de segurança, consulte Regras de Segurança.
Digamos que você queira adicionar uma regra de monitoramento de estado que permite tráfego HTTPS (porta 443) de entrada proveniente do outro CIDR da VCN. Estas são as etapas básicas que você executa ao adicionar uma regra:
- Na seção Permitir Regras para Entrada, selecione +Add Regra.
- Deixe a caixa de seleção Sem Monitoramento de Estado desmarcada.
- Tipo de Origem: deixe como CIDR.
- CIDR de Origem: insira o mesmo bloco CIDR que as regras de roteamento utilizam (consulte Tarefa E: Configurar tabelas de roteamento).
- Protocolo IP: deixe como TCP.
- Intervalo de Portas de Origem: deixe como Todos.
- Intervalo de Portas de Destino: insira 443.
- Descrição: Uma descrição opcional da regra.