☰

La instancia en la subred privada puede conectarse a Internet pero no puede hacer ping/rastrear ruta

tag-icon • tag-icon amazon-web-services amazon-ec2 iptables amazon-vpc
La instancia en la subred privada puede conectarse a Internet pero no puede hacer ping/rastrear ruta

Tengo una VPC de AWS con algunas subredes públicas y una subred privada, como la imagen a continuación.

  • Ambas instancias pueden conectarse a Internet (INSTANCIA Ase conecta a través dePUERTA DE ENTRADA NATinstancia)
  • PUERTA DE ENTRADA NATPuede hacer ping y rastrear hosts en Internet e instancias en otras subredes.
  • INSTANCIA Apuede hacer pingPUERTA DE ENTRADA NATy otras instancias en su subred y otras subredes

ElPUERTA DE ENTRADA NATes una instancia de Ubuntu 16.04 (t2.micro), configurada por mí. No es una puerta de enlace AWS NAT administrada. Funciona perfectamente como puerta de enlace para todos los demás hosts dentro de la VPC, así como para D-NAT (para algunos servidores Apache privados) y también actúa como bastión SSH.

El problema es eseINSTANCIA ANo puedo hacer ping ni rastrear hosts en Internet. Ya lo probé/comprobé:

  • Tablas de ruta
  • Grupos de seguridad
  • reglas de IPTABLES
  • parámetros del núcleo

diagrama vpc

Grupos de seguridad

 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

Tablas de ruta

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

reglas de 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 del núcleo

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

Traceroute de muestra de la INSTANCIA A

Gracias a @hargut por señalar un detalle sobre traceroute usando UDP (y mis SG no lo permiten). Entonces, usándolo con -Ila opción para 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  * * *
 ...

Respuesta1

El traceroute de Linux/Unix utiliza UDP para solicitudes estándar. Su grupo de seguridad no permite paquetes entrantes UDP.

Desde la página de manual de 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)

https://linux.die.net/man/8/traceroute

Consulte la -Iopción de tracerout que cambia el modo traceroute a seguimiento basado en ICMP.

información relacionada