NósconfiguramosoAWSVPCemduasregiões,conformeilustradoacima.AconexãoVPNagorafuncionaentreduasinstânciascadaumaconectadadiretamenteàsVPCsemcadaextremidadedaconfiguraçãoVPN(ouseja,VPCPRODemeu-west1eVPCPRODemap-south1).Então,"Serviço remoto" pode se comunicar com "Prod service". Isso é ilustrado pela linha pontilhada verde.
Como há uma conexão de peering entre os 2 VPCs eu-west1, eu esperava que o VPC PROD em ap-south1 fosse capaz de se comunicar com o VPC ADMIN em eu-west1. Este não parece ser o caso. Ou seja, "serviço remoto" não pode comunicar com "serviço de administração". Ilustrado pela linha pontilhada vermelha.
O VPC ADMIN tem entradas na tabela de roteamento:
10.100.0.0/16 ==> peering connection to VPC PROD (eu-west1)
O VPC PROD (eu-west1) tem entradas na tabela de roteamento:
10.100.0.0/16 ==> Virtual Private Gateway (VPG) / VPN connection
Além disso, o VPC PROD (ap-south1) possui entradas na tabela de roteamento:
172.20.0.0/16 and 172.30.0.0/16 ==> strongswan instance.
Eu imagino que o problema pode ser que o tráfego do ap-south1 chegue ao roteador VPG da eu-west1 e tenha uma grande demanda para atingir seu endpoint no VPC associado a VPGs, e ele não verá a tabela de roteamento de VPCs e portanto, não suportará o uso da entrada da tabela de roteamento correspondente para enviar o tráfego para a conexão de peering para o VPC ADMIN. Alguém pode confirmar se isso deveria ou não funcionar?
No momento, a única maneira de fazer isso parece criar uma segunda conexão VPN que teria um VPG associado ao VPC ADMIN. Em seguida, ajuste o roteamento em ap-south1 para acessar a VPN antiga para 172.20.0.0/16 (VPC PROD)
e a nova VPN para 172.30.0.0/16 (VPC ADMIN)
. Isso deve funcionar, mas vai custar o dobro e significa mais configurações para manter ...
Outras ideias para fazer funcionar?