Criei duas instâncias EC2 na mesma AZ e na mesma conta. Eles usam grupos de segurança diferentes. Gostaria que a instância A aceitasse conexões em uma determinada porta apenas da instância B.
Não acredito que essas instâncias sejam VPC, mas não sei 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, AI adicionou uma regra para a porta e usou o IP público /32 da instância B para a origem. Em seguida, tentei conectar-me da instância B usando o IP público da instância A, mas a tentativa de conexão falhou imediatamente.
Tentei os mesmos passos com o IP privado de cada instância. o que estou perdendo?
Aqui está um artigo que responde a uma pergunta semelhante, mas o VPC está envolvido:Não é possível conectar-se à instância EC2 no VPC (Amazon AWS).
Ambas as instâncias têm o mesmo ID de VPC e ID de sub-rede.
Também tentei definir a origem para o grupo de segurança da instância B, o que também não funcionou.
Estou tentando isso com mysql. O cliente mysql em execução na instância B falhou imediatamente com este erro:
ERRO 2003 (HY000): Não é possível conectar ao servidor MySQL em '54.xx.xx.xx' (113)
Para verificar se não houve 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, consegui confirmar que essas duas instâncias estão sendo executadas em uma VPC (acessando o console da VPC). Então, minha pergunta é muito semelhante ao 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 adequadas criadas. Veja como minha VPC está configurada: A VPC é padrão e possui uma tabela de rotas associada a ela. A tabela de rotas está implicitamente associada à sub-rede associada à VPC. A tabela de rotas possui uma única rota e o destino é "local".
Todos eles são criados por padrão, pois, pelo que entendi, os documentos devem permitir que duas instâncias se conectem entre si. O que (ainda) estou perdendo?
Responder1
Resolvi isso com a ajuda do suporte técnico da AWS. Aqui estão as informações para futuros novatos como eu:
O problema era que o iptables estava rodando na instância B e não permitia nenhum tráfego. Aprendi que existem dois níveis de firewall para instâncias EC2: grupos de segurança (gerenciados no console AWS) e iptables (gerenciados no host). Existem razões para usar iptables, por exemplo https://wincent.com/wiki/Using_iptables_on_EC2_instances
Na maioria das vezes, você não precisa se preocupar em usar um firewall em nível de host, como o iptables, ao executar o Amazon EC2, porque a Amazon permite que você execute instâncias dentro de um "grupo de segurança", que é efetivamente uma política de firewall que você usa para especifique quais conexões do mundo externo devem ter permissão para chegar à instância. No entanto, esta é uma abordagem de "lista de permissões" e não é simples usá-la para fins de "lista negra" em uma instância em execução.
No meu caso, não preciso de firewall no nível do host, então desliguei o iptables:
sudo service chkconfig stop
sudo chkconfig iptables off
Aqui estão alguns resultados que obtive relacionados aos comentários postados sobre esta questão:
- conectando com ip privado funcionou
- conectar com nome DNS privado funcionou
- conectando com ip público funcionou
- conectar-se com EIP público funcionou
- conectar-se ao DNS público funcionou, mas como Chad Smith disse em sua resposta, o DNS retorna oprivadoIP 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 executou iptables - cada imagem é diferente. A imagem que usei neste caso usou iptables para proibir todas as conexões, exceto SSH.
Responder2
Um pouco fora do assunto, mas este é o único resultado da pesquisa para esse problema.
Tivemos um problema semelhante, mas nossas instâncias existentes foram reinicializadas e de repente não conseguiram se comunicar. Acontece que havia muitas regras no grupo de segurança - apenas a remoção de algumas permitia a retomada da comunicação. Ainda estava funcionando antes da reinicialização porque as regras eram adicionadas ao longo do tempo por chamadas automatizadas para a API.
Espero que isso ajude alguém no futuro.
Responder3
Se você não puder modificar as configurações de segurança das instâncias em execução, elas NÃO serão executadas em uma VPC.
Mesmo para instâncias que não estão em VPC, o EC2 as lança em redes privadas que estão interconectadas. Então você deve especificar oendereço IP privadoda instância B no grupo de segurança da instância A.
Responder4
A AWS tem grupos de segurança separados para instâncias VPC e não VPC, então você precisa descobrir de alguma forma se está no VPC ou não (basta ir ao console do VPC e verificar se você vê suas instâncias lá) e então certificar-se de que os grupos de segurança você tem criados estão no mesmo contexto. Então você pode simplesmente adicionar o Grupo de segurança A ao Grupo de segurança B como confiável e fazer o oposto também. Dessa forma, você apenas permite todo o tráfego entre dois hosts em portas individuais (presumo que essa seja sua intenção).