As instâncias do EC2 não podem alcançar um ao outro

Question

Eu criei duas instâncias do EC2 no mesmo AZ e na mesma conta. Eles usam grupos de segurança diferentes. Eu gostaria que a instância A aceitasse conexões em uma determinada porta a partir da única instância B.

Não acredito que essas instâncias sejam VPC, mas não saibam como confirmar. Não consegui alterar o grupo de segurança, o que me faz pensar que eles não são VPC.

No grupo de segurança, por exemplo, A, adicionei uma regra à porta e usei o IP / 32 público da instância B para a origem. Em seguida, tentei conectar-me a partir da instância B usando o IP público da instância A, mas a tentativa de conexão falha imediatamente.

Eu tentei as mesmas etapas com o IP privado de cada instância. O que estou perdendo?

Veja um artigo que responde a uma pergunta semelhante, mas o VPC está envolvido: Não é possível conectar-se à instância do EC2 no VPC (Amazon AWS) .

Ambas as instâncias têm o mesmo ID de VPC e ID de sub-rede.

Eu também tentei definir a fonte para o grupo de segurança da instância B, o que também não funcionou.

Estou tentando isso com o mysql. O cliente mysql em execução na instância B falhou imediatamente com este erro:

ERROR 2003 (HY000): Can't connect to MySQL server on '54.xx.xx.xx' (113)

Para verificar se não houve um problema com a configuração do mysqld, tentei o mesmo com o ICMP Echo Reply que também não funcionou.

Editar Graças às respostas iniciais, pude confirmar que essas duas instâncias estão sendo executadas em um VPC (indo para o console VPC). Então, minha pergunta é muito parecida com o artigo vinculado. Mas, nesse caso, o problema era que as instâncias não eram instâncias padrão, portanto, não tinham a rota e a sub-rede apropriadas criadas. Veja como meu VPC está configurado: O VPC é o padrão e tem uma tabela de rotas associada a ele. A tabela de rotas está implicitamente associada à sub-rede associada ao VPC. A tabela de rotas tem uma única rota e o destino é "local".

Todos eles são criados por padrão, pois eu entendo que os documentos devem permitir que duas instâncias se conectem umas às outras. O que eu ainda sinto falta?

    

Answer 1

Resolvi isso com a ajuda do suporte técnico da AWS. Aqui está a informação para futuros novatos como eu:

O problema era que o iptables estava em execução na instância B e não permitia tráfego. Aprendi que existem dois níveis de firewall para instâncias do EC2: grupos de segurança (gerenciados no console da AWS) e iptables (gerenciados no host). Existem razões para usar o iptables, por exemplo link

Most of the time you don't need to worry about using a host-level firewall such as iptables when running Amazon EC2, because Amazon allows you to run instances inside a "security group", which is effectively a firewall policy that you use to specify which connections from the outside world should be allowed to reach the instance. However, this is a "whitelist" approach, and it is not straightforward to use it for "blacklisting" purposes on a running instance.

No meu caso, não preciso de um firewall no nível do host, por isso, desliguei o iptables:

sudo service chkconfig stop
sudo chkconfig iptables off

Aqui estão alguns resultados relacionados aos comentários postados nesta pergunta:

• conectando-se ao ip privado trabalhado
• conectando-se ao nome DNS privado trabalhado
• conectando-se ao ip público trabalhado
• conectando-se com o EIP público trabalhado
• conectando-se com o DNS público funcionou, mas como Chad Smith disse em sua resposta DNS retorna o IP private para este nome

A razão pela qual isso funcionou para mim em uma instância diferente é que a imagem que usei naquela instância não executava iptables - cada imagem é diferente. A imagem que usei neste caso usava o iptables para proibir todas as conexões, exceto o SSH.

    

Answer 2

Um pouco fora do tópico, mas esse é o único resultado de pesquisa para esse problema.

Tivemos um problema semelhante, mas nossas instâncias existentes foram reiniciadas e, de repente, não puderam se comunicar. Acontece que havia muitas regras no grupo de segurança - apenas removendo alguma comunicação permitida para continuar. Ele ainda estava funcionando antes da reinicialização porque as regras são adicionadas com o passar do tempo por chamadas automatizadas à API.

Espero que isso ajude alguém no futuro.

    

Answer 3

Se você não puder modificar as configurações de segurança das instâncias em execução, elas NÃO serão iniciadas em um VPC.

Mesmo em instâncias que não estão no VPC, o EC2 as lança em redes privadas interconectadas. Portanto, você deve especificar o endereço IP privado da instância B no grupo de segurança da instância A.

    

Answer 4

(1) você pode verificar se sua instância está em um VPC por meio do console da AWS. No painel do EC2, você pode selecionar sua instância e, na guia Descrição, na coluna à esquerda, há um campo ID da VPC. Se estiver em branco, você está no EC2-clássico.

(2) Você não pode acessar o IP público de uma instância de outra instância no EC2, a menos que essa porta esteja aberta para o mundo. Seu erro acima de usar o IP 54.X.X.X me diz que você está usando o IP público. Altere sua string de conexão para usar o DNS público. Este será o nome do host que começa com ec2-. Quando você fizer uma pesquisa de DNS nesse nome de DNS público, ele será resolvido para o IP PRIVADO em vez do IP público, que deve ser acessado se os grupos de segurança estiverem configurados corretamente.

resumo: tente conectar-se à sua instância do mysql usando o DNS público da instância.

Se você ainda não consegue se conectar, verifique se o mysql está escutando na eth0 e não apenas na interface de loopback.

    

Answer 5

A AWS tem grupos de segurança separados para instâncias VPC e não VPC, portanto, você precisa descobrir se está no VPC ou não (basta acessar o console do VPC e verificar se vê suas instâncias) e, em seguida, verificar se a segurança grupos que você criou estão no mesmo contexto. Em seguida, você pode simplesmente adicionar o grupo de segurança A ao grupo de segurança B como confiável e fazer o contrário também. Dessa forma, você permite apenas todo o tráfego entre dois hosts em uma porta individual (suponho que essa era sua intenção).