Instância na sub-rede privada pode se conectar à internet, mas não pode pingar / traceroute

Question

Eu tenho um AWS VPC com algumas sub-redes públicas e uma sub-rede privada, como a imagem abaixo.

• Ambas as instâncias podem se conectar à Internet ( INSTANCE A conecta-se através da instância do NAT GATEWAY )
• O NAT GATEWAY pode fazer ping e traceroute hosts na Internet e instâncias em outras sub-redes
• INSTANCE A pode pingar NAT GATEWAY e outras instâncias em sua sub-rede e outras sub-redes

O NAT GATEWAY é uma instância do Ubuntu 16.04 (t2.micro), configurada por mim. Não é um gateway NAT AWS gerenciado. Ele está funcionando perfeitamente como um gateway para todos os outros hosts dentro do VPC, bem como para o D-NAT (para alguns servidores Apache privados) e também atuando como um bastião do SSH.

O problema é que o INSTANCE A não pode enviar ping ou rastrear hosts na Internet. Eu já tentei / verifiquei:

• Tabelas de roteiro
• Grupos de segurança
• Regras do IPTABLES
• parâmetros do kernel

Grupos de segurança

 NAT GATEWAY
 Outbound: 
  * all traffic allowed
 Inbound:
  * SSH from 192.168.0.0/16 (VPN network)
  * HTTP/S from 172.20.0.0/16 (allowing instances to connect to the internet)
  * HTTP/S from 0.0.0.0/0 (allowing clients to access internal Apache servers through D-NAT)
  * ALL ICMP V4 from 0.0.0.0/0 


 INSTANCE A
 Outbound: 
  * all traffic allowed
 Inbound:
  * SSH from NAT GATEWAY SG
  * HTTP/S from 172.20.0.0/16 (public internet throught D-NAT)
  * ALL ICMP V4 from 0.0.0.0/0

Tabelas de rotas

PUBLIC SUBNET
172.20.0.0/16: local
0.0.0.0/0: igw-xxxxx (AWS internet gateway attached to VPC)

PRIVATE SUBNET
0.0.0.0/0: eni-xxxxx (network interface of the NAT gateway)
172.20.0.0/16: local

Regras do Iptables

# iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

# iptables -tnat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -o eth0 -j MASQUERADE

Parâmetros do kernel

net.ipv4.conf.all.accept_redirects = 0  # tried 1 too
net.ipv4.conf.all.secure_redirects = 1
net.ipv4.conf.all.send_redirects = 0  # tried 1 too
net.ipv4.conf.eth0.accept_redirects = 0  # tried 1 too
net.ipv4.conf.eth0.secure_redirects = 1
net.ipv4.conf.eth0.send_redirects = 0  # tried 1 too
net.ipv4.ip_forward = 1

Exemplo de traceroute da INSTANCE A

Obrigado a @hargut por apontar um detalhe sobre o traceroute usando UDP (e meus SGs não permitindo isso). Então, usando-o com a opção -I para o ICMP:

# traceroute -I 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  ip-172-20-16-10.ec2.internal (172.20.16.10)  0.670 ms  0.677 ms  0.700 ms
 2  * * *
 3  * * *
 ...

    

Answer 1

O traceroute Linux / Unix usa o UDP para solicitações padrão. Seu grupo de segurança não permite pacotes de entrada UDP.

Da página do manual do traceroute:

In the modern network environment the traditional traceroute methods can not be always applicable, because of widespread use of firewalls. Such firewalls filter the "unlikely" UDP ports, or even ICMP echoes. To solve this, some additional tracerouting methods are implemented (including tcp), see LIST OF AVAILABLE METHODS below. Such methods try to use particular protocol and source/destination port, in order to bypass firewalls (to be seen by firewalls just as a start of allowed type of a network session)

link

Veja a opção -I do tracerout que alterna o modo traceroute para rastreamento baseado em ICMP.