Circuito de acesso remoto

Visão Geral

Nesse cenário, a conectividade é estabelecida entre as VCNs e a rede on-premises, mas não entre as VCNs. Essa opção de política de roteamento é implementada configurando as tabelas de roteamento do gateway de roteamento dinâmico (DRG); caso contrário, esse cenário será semelhante ao pareamento remoto.

Esse cenário só está disponível para um DRG atualizado.

Resumo dos componentes do serviço Networking para circuito de acesso único

De forma geral, os componentes do serviço Networking necessários para circuito de acesso único incluem:

• Duas VCNs com CIDRs não sobrepostos, na mesma região

  Observação
  
  

  Nenhum CIDR da VCN pode ser sobreposto

  As duas VCNs no relacionamento de pareamento não podem ter CIDRs sobrepostos. Além disso, se uma VCN específica tiver vários relacionamentos de pareamento, as outras VCNs não deverã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, precisará 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 (gateway de roteamento dinâmico) anexado a cada VCN no relacionamento de pareamento. Sua VCN já terá um DRG se você estiver usando a VPN Site a Site ou um circuito virtual privado FastConnect do Oracle Cloud Infrastructure.
• Duas tabelas de roteamento do DRG personalizadas: uma roteando o tráfego para as VCNs e outra roteando o tráfego para a rede on-premises. As tabelas de roteamento padrão do DRG (uma para anexos locais da VCN e outra para todos os outros anexos) não são usadas após a conclusão da configuração.
• Uma conexão de pareamento remoto (RPC) em cada DRG no relacionamento de pareamento.
• Uma conexão de pareamento remoto estabelecida 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. A VCN-1 será opcional se sua intenção principal for acessar a VCN-2. É necessário dar suporte a tabelas de roteamento e regras de segurança em cada VCN 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.

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.

Conceitos importantes do 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:

• Compartilhar algumas informações básicas entre si.
• Trabalhar de forma coordenada para configurar as políticas do Oracle Cloud Infrastructure Identity and Access Management necessárias para permitir o pareamento.
• Configurar suas VCNs para o pareamento.

Dependendo da situação, um único administrador poderá ser responsável pelas VCNs e pelas políticas relacionadas. As VCNs podem estar na mesma tenancy ou em tenancies diferentes.

Para obter mais informações sobre as políticas obrigatórias e a configuração da VCN, consulte Políticas do IAM para Roteamento entre VCNs.

ACCEPTOR AND REQUESTOR

Para implementar as políticas do IAM necessárias para pareamento, os dois administradores das VCNs devem designar um administrador como solicitante e outro como aceitador. O solicitante deve ser quem inicia a solicitação para conectar os duas RPCs. Por sua vez, o aceitador deve criar uma política do IAM específica que permita ao solicitante estabelecer conexão com RPCs no compartimento do aceitador. Sem essa política, a solicitação do solicitante para conexão falhará.

REGION SUBSCRIPTION

Para fazer um pareamento com uma VCN em outra região, primeiro a sua tenancy deverá estar inscrita 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 pareamento remoto (RPC) é um componente que você cria no DRG anexado à sua 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 estabelecido com 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 inicia a solicitação de pareamento (na Console ou na API), ele está pedindo efetivamente para estabelecer conexão com as duas RPCs. O solicitante deve ter informações para identificar cada RPC (como a região e o OCID da RPC).

Ambos os administrador das VCNs podem encerrar um pareamento excluindo sua respectiva RPC. Nesse caso, o status da outra RPC muda para REVOKED. Em vez disso, o administrador pode processar a conexão não funcional removendo as regras de roteamento que permitem ao tráfego fluir pela conexão (consulte a seção a seguir).

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 rede on-premises, atualize a tabela de roteamento da sub-rede. A regra de roteamento especifica o CIDR do tráfego de destino e o seu DRG como alvo. O seu DRG roteia o tráfego correspondente à regra para o outro DRG, que, por sua vez, encaminha o tráfego para o próximo salto na outra VCN.

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 determinar quais sub-redes de suas próprias VCNs precisam se comunicar com VNICs na outra VCN e deve atualizar as listas de segurança da sub-rede de forma adequada.

Se você usar grupos de segurança de rede (NSGs) para implementar regras de segurança, observe que você poderá criar regras de segurança para um NSG que especifica outro NSG como origem ou destino do tráfego. Entretanto, os dois NSGs devem pertencer à mesma VCN.

Configurando o circuito de acesso único

Antes de tentar implementar esse cenário, verifique se:

1. A VCN-1 é anexado ao DRG-1 na região 1 seguindo as etapas em Anexando uma VCN a um DRG.
2. A VCN-2 é anexado ao DRG-2 na região 2 seguindo as etapas em Anexando uma VCN a um DRG.
3. A VCN-2 é pareada com a VCN-1 seguindo as etapas em Pareamento Remoto de VCN por meio de um DRG Atualizado
4. Ambos os DRGs não são modificados.
5. O circuito virtual FastConnect 1 está na região 1, conectado ao DRG-1, seguindo o método apropriado, dependendo da origem do circuito virtual (parceiro Oracle, colocalização Oracle, provedor de terceiros) conforme descrito na documentação do FastConnect.

O diagrama a seguir mostra o estado inicial antes da implementação desse cenário. A VCN-1 e a VCN-2 estão pareadas. O tráfego de uma instância na Sub-rede A (10.0.0.15) destinado a uma instância na VCN-2 (192.168.0.15) é roteado para o DRG-1 com base na regra da tabela de roteamento da Sub-rede A. A partir daí, o tráfego é roteado por meio das RPCs para o DRG-2. Depois, vai para o destino na Sub-rede X. A rede on-premises pode tratar recursos na VCN-1, mas não na VCN-2.

O cenário de circuito de acesso implementado descrito no próximo diagrama não permite que as VCNs roteiem o tráfego entre si. A VCN-1 e a VCN-2 estão pareadas. O tráfego de um recurso on-premises na sua rede (172.16.0.10) destinado a uma instância na VCN-2 (192.168.0.15) é roteado para o DRG-1 com base na regra da tabela de roteamento de anexo IPSEC_TUNNEL To-on-premises. A partir daí, o tráfego é roteado por meio do anexo de RPC para o DRG-2. Depois, vai para o destino na Subnet X.

Etapas

Todas essas etapas são executadas no DRG-1: