Conecte-se ao RDS da instância do EC2 em uma Zona de disponibilidade (AZ) diferente

Question

OK, tenho um VPC com três servidores de aplicativos e uma instância do Postgres no RDS.

Eu tenho um grupo de segurança chamado 'rds-staging' que permite conexões de entrada na porta 5432 de um grupo de segurança chamado 'app-elb-staging'.

'app-elb-staging' é o grupo de segurança aplicado a todas as minhas instâncias do EC2 e permite que o tráfego de saída vá a qualquer lugar.

A instância do RDS está em AZ us-east-1e. Eu posso me conectar a ele da minha instância do EC2 em us-east-1e (10.0.3. *), Mas não de qualquer instância do EC2 em us-east-1a (10.0.1. *) Ou us-east-1c (10.0 .2. *):

deploy@ip-10-0-3-220:~$ nc -zv xxx.us-east-1.rds.amazonaws.com 5432
Connection to xxx.us-east-1.rds.amazonaws.com 5432 port [tcp/postgresql] succeeded!

deploy@ip-10-0-1-155:~$ nc -zv xxx.us-east-1.rds.amazonaws.com 5432
nc: connect to xxx.us-east-1.rds.amazonaws.com port 5432 (tcp) failed: No route to host

deploy@ip-10-0-2-90:~$ nc -zv xxx.us-east-1.rds.amazonaws.com 5432
nc: connect to xxx.us-east-1.rds.amazonaws.com port 5432 (tcp) failed: No route to host

Alguém já viu isso antes? Verifiquei o DNS e cada máquina está resolvendo o nome do host para o mesmo IP (10.0.3.x).

    

Answer 1

OK, finalmente descobri a causa raiz desse problema. A AMI que eu estava usando criava uma ponte que causava o problema de conexão devido à colisão com os IPs das minhas sub-redes. A saída de sudo route -n ficou assim em uma instância afetada:

ubuntu@ip-10-0-1-92:~$ sudo route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.1.1        0.0.0.0         UG    0      0        0 eth0
10.0.1.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.0.2.0        0.0.0.0         255.255.255.0   U     0      0        0 lxcbr0

Qualquer conexão com 10.0.2. * falharia:

deploy@ip-10-0-1-92:~$ nc -zv 10.0.2.53 22
nc: connect to 10.0.2.53 port 22 (tcp) failed: No route to host

A remoção da ponte com sudo ifconfig lxcbr0 down resolveu o problema, mas o uso de uma AMI que não configurou essa ponte corrigiu a raiz.

    

Answer 2

Eu já vi esse tipo de problema causado por um dos dois motivos:

1. As tabelas de rotas anexadas às várias sub-redes estão configuradas incorretamente.
2. Existe uma ACL de rede em reprodução (incomum).

Você não precisa definir rotas para cada sub-rede, elas estão implícitas na tabela. Verificar novamente os endereços IP para os quais sua entrada de DNS resolve nas outras instâncias AZ garantirá que esteja na VPC.

As ACLs de rede podem entrar em jogo, mas você precisa configurá-las. Por padrão, eles estão abertos. É por isso que o identifiquei como improvável, mas isso pode causar problemas como esse. Dito isso, o erro "não há rota para hospedar" é sugestivo de que isso não é problema seu.