Transit Routing – Acessando serviços do OCI de maneira privada

Um dos recursos disponíveis (e sugeridos) no OCI é o uso de uma topologia de Hub-and-Spoke (que eu já comentei aqui) e podemos usar essa topologia para o acesso à serviços do OCI, tudo isso passando por dentro dessa conexão, basicamente a sua rede local vai ser comunicar com a OCI sem passar pela internet, a conexão pode ser tanto em cima de um Fastconnect ou VPN(que vamos abordar aqui).

Esses são alguns dos serviços que podem ser acessados dessa forma:

  • Autonomous Shared
  • Object Storage
  • Data Safe
  • Analytics Cloud

Os acessos são divididos em duas categorias:

  • Private Endpoint
    • Nessa categoria ficam os serviços que geram um ip privado para o acesso como por exemplo o autonomous Database
  • Service Gateway

A diferença aqui é que os serviços que entregam acesso via Private Endpoint geram um IP na sua VCN e você pode inclusive gerenciar seu acesso com NSG/Sec. List enquanto que no acesso via Service Gateway você não tem esse controle.

Essa diferença é demonstrada na topologia abaixo:

De verde o acesso via Service GW e de Amarelo o acesso via Private Endpoint

Além disso, ainda temos duas possibilidades de configuração, uma utilizando o que chamamos de roteamento entre Gateways e outra chamada Roteamento através de um IP Privado que é basicamente quando temos um Firewall entre as duas pontas, hoje vou falar sobre a primeira opção.

Topologia

Aqui vou usar um pouco do que já fiz no post do Hub and Spoke, minha topologia é organizada da seguinte forma:

IAD(meu lado onpremises)

  • Rede: 10.100.0.0/16
  • VPN: 10.100.71.204
  • VM client: 10.100.70.52
  • Tabela de rotas: Endereço Obj Storage GRU -> 10.100.71.204

GRU(meu lado cloud)

  • Rede: 10.70.0.0/16
  • Service Gateway
  • DRG
  • Tabelas de rota:
    • RT_SGW_OUT: Rede IAD -> DRG
    • RT_FAST: OCI GRU Object Storage -> Service GW
  • Object Storage

Mão na massa

Vamos assumir que você já tenha uma conexão entre os dois ambientes(seja via VPN ou Fastconnect) e passar direto para a configuração dos recursos, a maior parte das configurações vai ser feita em GRU.

Recursos de rede:

Tabelas de rota

Vamos precisar de duas tabelas de rota, uma que vai ser vinculada ao Service Gateway e vai conter a rede local(propaga a rota de volta) e outra que vai ser attachada ao DRG apontando o Service Gateway como destino(que propaga os endereços dos serviços dentro do túnel).

Service Gateway

Com a tabela de rotas criada, você pode criar o Service Gateway e vincular a tabela de rota que contém a rede local dentro dele, aqui vale ressaltar que a opção em Services vai ser responsável por propagar os endereços, então se você selecionar a opção All Services, todos os serviços daquela região vão ser propagados.

DRG

Após o DRG criado, você precisa vincular uma tabela de rotas dentro dele, dentro do attachment você vai em edit e seleciona a tabela de rotas que aponta para o Service Gateway:

Essa rota deve aparecer dentro da tabela de rotas do DRG, se você estiver usando tudo no padrão ela vai se chamar Autogenerated Drg Route Table for VCN attachments:

Ajustando o lado onpremises

No meu lado onpremises eu subi uma VPN usando Libreswan e tive que adicionar algumas rotas de forma manual pois estou usando VPN do tipo Route Based, o ideal é que se você puder, use BGP pois dessa forma esse ajuste manual não é necessário.

Tabela de rotas no OCI

Perceba que a terceira linha joga todo o tráfego com destino ao IP do Object Storage da região GRU para a interface de rede da VPN:

Dentro da minha VM do LibreSwan eu tenho uma rota que joga o mesmo pacote para a interface de VPN:

Dica, caso você esteja usando os dois túneis que a OCI disponibiliza(essa é a melhor prática) você pode adicionar a rota da seguinte forma:

ip route add 134.70.84.3/32 nexthop dev vti01 nexthop dev vti2

Testes

Nesse primeiro teste eu removi a rota que joga o trafego para a interface de VPN e ele está indo pela internet:

[opc@tnk-oci360 ~]$ traceroute objectstorage.sa-saopaulo-1.oraclecloud.com
traceroute to objectstorage.sa-saopaulo-1.oraclecloud.com (134.70.84.3), 30 hops max, 60 byte packets
 1  140.91.196.216 (140.91.196.216)  0.138 ms 140.91.196.209 (140.91.196.209)  0.103 ms 140.91.196.222 (140.91.196.222)  0.133 ms
 2  140.91.208.23 (140.91.208.23)  135.132 ms 140.91.208.10 (140.91.208.10)  135.087 ms 140.91.208.11 (140.91.208.11)  135.060 ms
 3  * * *
28  * * *
29  * * *
30  * * *
[opc@tnk-oci360 ~]$ ping objectstorage.sa-saopaulo-1.oraclecloud.com
PING objectstorage.sa-saopaulo-1.oci.oraclecloud.com (134.70.84.3) 56(84) bytes of data.
64 bytes from 134.70.84.3 (134.70.84.3): icmp_seq=1 ttl=62 time=135 ms
64 bytes from 134.70.84.3 (134.70.84.3): icmp_seq=2 ttl=62 time=135 ms
64 bytes from 134.70.84.3 (134.70.84.3): icmp_seq=3 ttl=62 time=135 ms
64 bytes from 134.70.84.3 (134.70.84.3): icmp_seq=4 ttl=62 time=135 ms
^C
--- objectstorage.sa-saopaulo-1.oci.oraclecloud.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 135.469/135.531/135.599/0.453 ms

Adicionei a rota forçando que o trafego saia da máquina cliente para a de VPN mas deixei a VPN down:

[root@tnk-oci360 opc]# traceroute objectstorage.sa-saopaulo-1.oraclecloud.com
traceroute to objectstorage.sa-saopaulo-1.oraclecloud.com (134.70.84.3), 30 hops max, 60 byte packets
 1  tanaka-libreswan.redewanusa.vcntanakausa.oraclevcn.com (10.100.71.204)  0.301 ms  0.261 ms  0.232 ms
 2  tanaka-libreswan.redewanusa.vcntanakausa.oraclevcn.com (10.100.71.204)  0.230 ms !H  0.222 ms !H  0.196 ms !H

Subi a VPN e adicionei a rota na máquina:

[root@tnk-oci360 opc]# traceroute objectstorage.sa-saopaulo-1.oraclecloud.com
traceroute to objectstorage.sa-saopaulo-1.oraclecloud.com (134.70.84.3), 30 hops max, 60 byte packets
 1  tanaka-libreswan.redewanusa.vcntanakausa.oraclevcn.com (10.100.71.204)  0.342 ms  0.310 ms  0.294 ms
 2  * * *
 3  * * *
 4  * * *
 5  134.70.84.3 (134.70.84.3)  156.746 ms  150.718 ms  164.532 ms
[root@tnk-oci360 opc]# 

Verificando por onde a comunicação está sendo feita

Se quiser validar por onde o acesso está sendo feito, basta ativar a opção de log no bucket e validar o campo clientIPAddress:

Download da minha máquina via internet:

Download via Transit:

Removendo a comunicação

Para remover a comunicação, uma das formas é remover a rota que aponta para a sua rede local:

Você também pode usar a opção Block Traffic direto no Service Gateway mas isso vai parar todo e qualquer tráfego que esteja usando esse gateway!

chevron_left
chevron_right