Instanz im privaten Subnetz kann Internetverbindung herstellen, aber kein Ping/Traceroute durchführen

Instanz im privaten Subnetz kann Internetverbindung herstellen, aber kein Ping/Traceroute durchführen

Ich habe ein AWS VPC mit einigen öffentlichen Subnetzen und einem privaten Subnetz, wie im Bild unten.

  • Beide Instanzen können sich mit dem Internet verbinden (INSTANZEN Averbindet durchNAT-GATEWAYBeispiel)
  • NAT-GATEWAYkann Hosts im Internet und Instanzen in anderen Subnetzen anpingen und tracerouten
  • INSTANZEN Akann pingenNAT-GATEWAYund andere Instanzen in seinem Subnetz und anderen Subnetzen

DerNAT-GATEWAYist eine von mir konfigurierte Ubuntu 16.04 (t2.micro)-Instanz. Es ist kein verwaltetes AWS NAT-Gateway. Es funktioniert perfekt als Gateway für alle anderen Hosts innerhalb des VPC, sowie für D-NAT (für einige private Apache-Server) und fungiert auch als SSH-Bastion.

Das Problem ist, dassINSTANZEN AHosts im Internet können nicht angepingt oder verfolgt werden. Ich habe bereits Folgendes versucht/überprüft:

  • Routentabellen
  • Sicherheitsgruppen
  • IPTABLES-Regeln
  • Kernel-Parameter

VPC-Diagramm

Sicherheitsgruppen

 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

Routentabellen

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

Iptables-Regeln

# 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

Kernel-Parameter

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

Beispiel-Traceroute von INSTANZ A

Vielen Dank an @hargut für den Hinweis auf ein Detail zu Traceroute mit UDP (und meine SGs lassen es nicht zu). Also, ich verwende es mit -Ider Option für 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  * * *
 ...

Antwort1

Linux/Unix Traceroute verwendet UDP für Standardanfragen. Ihre Sicherheitsgruppe lässt keine eingehenden UDP-Pakete zu.

Aus der Traceroute-Manpage:

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

Sehen Sie sich die -IOption „Traceroute“ an, die den Traceroute-Modus auf ICMP-basiertes Tracing umschaltet.

verwandte Informationen