☰

Statische IP kann nicht vom internen Netzwerk gepingt werden, nur von außerhalb

tag-icon • tag-icon networking ping localhost
Statische IP kann nicht vom internen Netzwerk gepingt werden, nur von außerhalb

Ich verwende Ubuntu und habe Apache am Laufen, kann jedoch weder intern an meine statische IP-Adresse pingen noch http://207.40.XXX.XXden Webserver mit meiner statischen IP-Adresse durchsuchen. Ich kann nur pingen/browsenlocalhost, 127.0.0.1, and 192.168.0.120 ODER 207.40.XXX.XXnur von der Außenwelt.

# cat /etc/hosts
127.0.0.1       localhost
127.0.1.1       my-server.myhost.com my-server

# hostname
my-server

# netstat -tapn
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -                  
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      -               
tcp        0      0 127.0.0.1:29754         0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      -               
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN

Irgendwelche Ideen, warum das nicht funktioniert?

Antwort1

Ihr NAT-Gateway verhält sich nicht so, dass es dies zulässt. So funktioniert es wahrscheinlich:

Klingeln

  1. Sie senden eine ICMP-Echo-Anfrage von 192.168.0.5 an 207.40.123.45
  2. Die Weiterleitung erfolgt über Ihren Router.
  3. Ihr NAT-Gateway in Ihrem Router schreibt die Anfrage so um, dass sie von 207.40.123.45 stammt (statische IP-Adresse).
  4. Ihr Router antwortet auf die ICMP-Echo-Anfrage
  5. Da Ihr Router den ICMP-Status nicht unterstützt, leitet er die ECHO-Antwort nie an Sie zurück.

HTTP

  1. Sie senden eine TCP/80-Verbindungsanfrage von 192.168.0.5 an 207.40.123.45
  2. Dies leitet über Ihren Router
  3. Ihr NAT-Gateway schreibt das Paket um, als käme esaus207.40.123.45:41345 bis 207.40.123.45:80
  4. Ihr NAT-Gateway erkennt, dass eine Portweiterleitung vorhanden ist, und leitet das Paket an 192.168.0.120:80 weiter.
  5. Der Server unter 192.168.0.120 antwortet auf den Verbindungsversuch von 207.40.123.45:41345
  6. Ihr NAT-Gateway sieht die Antwort und schreibt die An:-Adresse in der Antwort auf 192.168.0.5:36311 um, lässt aber die Von:-Adresse unverändert (192.168.0.120:80).
  7. Ihr Computer unter 192.168.0.5 erhält ein Paket von 192.168.0.120, das er nie angefordert hat, und lässt es fallen.
  8. Ihre Verbindung schwächelt und wird nie geöffnet.‘

Beachten Sie, dass der Grund für das Fehlschlagen des Pings möglicherweise derselbe Grund ist, aus dem auch HTTP fehlschlägt. Dies wird als „NAT Hairpinning“ bezeichnet.

Was Sie brauchen, ist ein NAT-Gateway, das intelligent genug ist, dass es in Schritt 6 auch dieQuelleAdresse.

Antwort2

Obwohl die Antwort von 1138 richtig ist, wollte ich nur eine ausführliche Erklärung dazu einwerfen, was „Hairpin-NAT“ ist, wie es funktioniert und warum es in diesem Fall notwendig ist. Wenn Sie sich nicht für die Einzelheiten von IP, NAT und Routing interessieren, können Sie den Rest meiner (ziemlich langen) Antwort gerne ignorieren.

Ohne Hairpinning passiert Folgendes während eines HTTP-Verbindungsversuchs von einem lokalen LAN-Client (192.168.0.5) zum Webserver über die externe IP-Adresse (207.40.123.45):

  1. 192.168.0.5 sendet sein SYN-Paket an 207.40.123.45, Port 80. Da sich 207.40.123.45 nicht im lokalen Netzwerk befindet, wird dieses Paket an das Standard-Gateway (also den Router) gesendet.

  2. Der Router, der so konfiguriert ist, dass er 207.40.123.45:80 an 192.168.0.120:80 weiterleitet, schreibt die Zieladresse des Pakets in 192.168.0.120 um und liefert das Paket dann an den Webserver.

  3. Der Webserver empfängt das SYN-Paket und sendet ein Antwort-SYN-ACK-Paket zurück an die Adresse des Absenders.192.168.0.5Da sich 192.168.0.5 im selben Netzwerk befindet, liefert der Webserver das Paket direkt an 192.168.0.5.

  4. Das SYN-ACK-Paket von192.168.0.120kommt bei 192.168.0.5 an, aber der Host dort hat kein SYN-ACK von 192.168.0.120 erwartet und wird daher verworfen/abgelehnt. Der Host bei 192.168.0.5 wartet weiterhin auf eine SYN-ACK-Antwort von 207.40.123.45, aber dieses Paket wird natürlich nie ankommen. Der Verbindungsversuch wird irgendwann ablaufen, möglicherweise nach einigen Wiederholungsversuchen, und letztendlich können Client und Webserver keine Verbindung herstellen.

Dieses Problem kann der Router in Schritt 2 lösen, indem er ein „Hairpin NAT“ anwendet. Kurz gesagt besteht die Lösung darin, den Client und den Webserver dazu zu bringen, ihren gemeinsamen Datenverkehr über den Router zu senden. Dies wird geschickt erreicht, indemeine zweite Phase von NATin Schritt 2 zusätzlich zu der einen Phase, die normalerweise für die Portweiterleitung angewendet wird. Hier ist die Sequenz noch einmal, dieses Mal mit dem zusätzlichen Hairpinning-NAT:

  1. Wie zuvor sendet 192.168.0.5 sein SYN-Paket mit Ziel 207.40.123.45, Port 80, an den Router.

  2. Wie zuvor empfängt der Router das SYN-Paket und schreibt die Zieladresse gemäß seiner konfigurierten Portweiterleitungsregel auf 192.168.0.120 um. Dieses Mal bemerkt der Router jedoch, dass er das Paket wieder in dasselbe Netzwerk zurücksenden wird, aus dem es empfangen wurde. Daher schreibt er auch die Zieladresse des Pakets um.Quelladressean die eigene LAN-Adresse des Routers (z. B. 192.168.0.1). Der Router liefert das Paket dann an den Webserver unter 192.168.0.120.

  3. Der Webserver empfängt das SYN-Paket und sendet sein Antwortpaket SYN-ACK zurück an die Adresse des Absenders, die diesmal lautet:192.168.0.1Die Antwort geht somit zurück an den Router.

  4. Der Router empfängt das SYN-ACK vom Webserver und erkennt, dass es sich um eine Antwort auf ein Paket handelt, das er kürzlich (zweimal) per NAT verarbeitet hat. Der Router kehrt also beide NATs pflichtbewusst um und das Antwortpaket hat nun die Quelladresse 207.40.123.45 und die Zieladresse 192.168.0.5. Daher wird die Antwort an 192.168.0.5 übermittelt, der TCP-Verbindungs-Handshake wird fortgesetzt und Client und Webserver können erfolgreich kommunizieren.

Wenn der Router Hairpinning unterstützt, glaubt der Host unter 192.168.0.5, dass er mit einem Webserver unter 207.40.123.45 kommuniziert, während der Webserver unter 192.168.0.120 glaubt, dass er mit einem Client auf dem Router selbst (192.168.0.1) kommuniziert. Beim Hairpinning läuft der gesamte Datenverkehr zwischen den beiden Hosts über den Router, obwohl sich beide Hosts tatsächlich im selben Netzwerk befinden. Dies ist offensichtlich eine suboptimale Nutzung der Netzwerkressourcen und der Hauptgrund, warum die Einrichtung eines geteilten DNS normalerweise besser ist als Hairpinning.

Antwort3

Welche Art Firewall verwenden Sie? Es klingt, als wäre NAT Hairpinning nicht eingeschaltet.

verwandte Informationen