incapaz de pingar ou ssh entre sub-redes vpc do aws

1

Eu tenho um layout de sub-rede de vários níveis razoavelmente padrão no VPC. Há uma camada / sub-rede do banco de dados, uma camada / sub-rede do servidor da Web e uma camada / sub-rede do host do bastião. Meu problema é que não consigo pingar ou ssh entre sub-redes.

Em particular, eu gostaria de fazer ping e ssh da camada / sub-rede de bastiões para a sub-rede / sub-servidor do servidor da web.

172.31.32.0/20 bastion-tier
172.31.0.0/20 webserver-tier

As duas sub-redes estão na mesma zona de disponibilidade e ambas as sub-redes estão conectadas à mesma tabela de rotas. A tabela de rotas é assim:

172.31.0.0/16 local
0.0.0.0/0 igw-xxxxxxxx

Atualmente, as ACLs de rede para a camada do servidor da web permitem tráfego ALL, protocolos ALL, portas ALL de 172.31.32.0/20, que é a camada de bastiões. As regras de saída / saída permitem todo o tráfego. Os grupos de segurança também estão bem abertos. Aqui estão as ACLs da rede para a camada do servidor da Web.

RULE #  TYPE          PROTOCOL  PORT RANGE  SOURCE          ALLOW/DENY
100     ALL Traffic   ALL       ALL         172.31.32.0/20  ALLOW
200     HTTP (80)     TCP (6)   80          0.0.0.0/0       ALLOW
202     HTTP* (8080)  TCP (6)   8080        0.0.0.0/0       ALLOW
210     HTTPS (443)   TCP (6)   443         0.0.0.0/0       ALLOW
*       ALL Traffic   ALL       ALL         0.0.0.0/0       DENY

Eu tentei ping e ssh em sub-redes com ambas as sub-redes sendo anexadas à tabela de rota padrão / principal E tentei com a sub-rede do servidor da Web ser anexada à sua própria tabela de rotas. Quando eu abro qualquer uma dessas sub-redes para trafegar do endereço IP do meu laptop, eu sou capaz de fazer ssh com sucesso através dos endereços IP públicos das instâncias.

Eu vi informações on-line que implicam um comportamento estranho / com bugs nas AWS VPCs. Problemas, por exemplo, ao criar Elastic IPs através do console VPC, mas atribuí-los através do console EC2 e depois ter tráfego desaparecer como se estivesse em um buraco negro. A solução parecia ser excluir o EIP com bugs e recriar e atribuir um novo totalmente por meio do console VPC ou EC2. No entanto, isso é, na melhor das hipóteses, uma visão indireta do possível / geral AWS bugginess, uma vez que no meu caso não há EIPs envolvidos.

Minha próxima medida de solução de problemas é começar de novo com um novo VPC, criar duas sub-redes, criar uma instância do servidor em cada uma delas e testar o ping e o ssh entre elas. Uma única tabela de rotas e grupos de segurança e acesso à rede totalmente abertos - não pode ser mais simples do que isso.

Isto parece-me ser uma configuração básica e, por isso, suspeito que exista uma solução básica que esteja em falta. Alguma ideia? Por favor e obrigado!

    
por Richard Riehle 23.06.2016 / 02:35

2 respostas

1

Você precisa de uma rota e abrir ACLs de rede da sub-rede do servidor da web de volta à sub-rede do tipo "bastião" ou os pacotes de resposta nunca retornarão ao servidor. Habilite o ICMP (e verifique se o seu cliente ping está usando apenas ICMP - alguns usam pacotes UDP por padrão) da sub-rede do servidor para o bastião e abra as portas TCP efêmeras apropriadas (o intervalo é geralmente dependente do sistema operacional; consulte link ) de webserver-tier para bastion-tier.

Se você executar o tcpdump em uma instância de servidor da Web e uma ocorrência de bastião simultaneamente, provavelmente verá o servidor da Web obtendo os pacotes de bastiões e enviando uma resposta, mas a instância de bastião nunca obterá a resposta.

    
por 23.06.2016 / 07:03
0

Verifique as regras do grupo de segurança de entrada para a instância nas duas sub-redes. Você precisa permitir que o CIDR especifique a sub-rede ou então conecte o grupo de segurança padrão a eles.

"Permitir tráfego de entrada de instâncias atribuídas ao mesmo grupo de segurança"

link

    
por 26.06.2016 / 11:29