Antwort auf Curl-Anforderung gegen private IP-Adresse des Computers unter OSX kann nicht empfangen werden

794
Simon McClive

Ich erlebe ein interessantes Problem, dem ich schwer auf den Grund gehen möchte, und würde gerne Einsichten in das, was passieren könnte, begrüßen.

Ich verwende ein Macbook Pro unter OSX 10.13.6.

Mein Problem ist wie folgt ... Ich starte eine Knotenserver-Bindung an alle Schnittstellen über die 0.0.0.0Adresse. Ich bin in der Lage zu kräuseln localhost:3000und 127.0.0.1:3000und erfolgreich den Server zu schlagen und eine Antwort zu erhalten.

Wenn ich versuche, meine private IP-Adresse von meinem Computer aus zu kräuseln, wird curl 192.168.1.113:3000die Anfrage vom Server empfangen und eine Antwort gesendet. Die Antwort wird jedoch niemals von curl empfangen. Kollegen im Netzwerk können meine private IP-Adresse erfolgreich kräuseln und erhalten eine Antwort.

Folgendes habe ich bisher beobachtet.

Ich spüle meine Routingtabellen so netstat -rnaus.

Routing tables  Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.1.1 UGSc 74 0 en0 127 127.0.0.1 UCS 0 0 lo0 127.0.0.1 127.0.0.1 UH 3 1561554184 lo0 169.254 link#12 UCS 0 0 en0 192.168.1 link#12 UCS 0 0 en0 192.168.1.1/32 link#12 UCS 1 0 en0 192.168.1.1 70:4f:57:81:72:d2 UHLWIir 24 37 en0 1198 192.168.1.113/32 link#12 UCS 0 0 en0 224.0.0/4 link#12 UmCS 2 0 en0 224.0.0.251 1:0:5e:0:0:fb UHmLWI 0 0 en0 239.255.255.250 1:0:5e:7f:ff:fa UHmLWI 0 2 en0 255.255.255.255/32 link#12 UCS 0 0 en0

Meine private IP hat einen Datensatz 192.168.1.113/32, der an die en0-Schnittstelle gebunden ist. Wenn ich mit curl auf localhost und 127.0.0.1 auf den Server zugreife, ändert sich nichts in meinen Routingtabellen.

Unmittelbar nach dem Zugriff curl 192.168.1.113:3000von meinem Computer aus erscheint ein neuer Datensatz in der Routing-Tabelle (siehe unten).

Routing tables  Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.1.1 UGSc 71 0 en0 127 127.0.0.1 UCS 0 0 lo0 127.0.0.1 127.0.0.1 UH 5 1561554801 lo0 169.254 link#12 UCS 0 0 en0 192.168.1 link#12 UCS 1 0 en0 192.168.1.1/32 link#12 UCS 1 0 en0 192.168.1.1 70:4f:57:81:72:d2 UHLWIir 22 43 en0 1170 192.168.1.113/32 link#12 UCS 1 0 en0 192.168.1.113 88:e9:fe:4c:a3:58 UHLWIi 2 8 lo0 192.168.1.255 ff:ff:ff:ff:ff:ff UHLWbI 0 11 en0 224.0.0/4 link#12 UmCS 2 0 en0 224.0.0.251 1:0:5e:0:0:fb UHmLWI 0 0 en0 239.255.255.250 1:0:5e:7f:ff:fa UHmLWI 0 18 en0 255.255.255.255/32 link#12 UCS 0 0 en0

Die Leitung hat eine Gateway-Schnittstelle, die die Schnittstelle en0 ist und an die Loopback-Schnittstelle gebunden ist.

192.168.1.113 88:e9:fe:4c:a3:58 UHLWIi 2 8 lo0

Ich frage mich, ob die Antwortpakete in einer schlechten Art und Weise weitergeleitet werden, wenn die Anforderung aus dem Host heraus gestellt wird. Alle Hilfe wird geschätzt.

EDIT -> ifconfig weiter unten

ifconfig lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP> inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 nd6 options=201<PERFORMNUD,DAD> gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 stf0: flags=0<> mtu 1280 XHC0: flags=0<> mtu 0 XHC1: flags=0<> mtu 0 XHC20: flags=0<> mtu 0 en1: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 options=60<TSO4,TSO6> ether 32:00:f0:81:a8:01 media: autoselect <full-duplex> status: inactive en2: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 options=60<TSO4,TSO6> ether 32:00:f0:81:a8:00 media: autoselect <full-duplex> status: inactive en3: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 options=60<TSO4,TSO6> ether 32:00:f0:81:a8:05 media: autoselect <full-duplex> status: inactive en4: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 options=60<TSO4,TSO6> ether 32:00:f0:81:a8:04 media: autoselect <full-duplex> status: inactive en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 88:e9:fe:4c:a3:58 inet6 fe80::a5:7168:25d:73ec%en0 prefixlen 64 secured scopeid 0xc inet 192.168.1.113 netmask 0xffffff00 broadcast 192.168.1.255 nd6 options=201<PERFORMNUD,DAD> media: autoselect status: active p2p0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2304 ether 0a:e9:fe:4c:a3:58 media: autoselect status: inactive awdl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1484 ether a2:cf:3c:7c:70:56 inet6 fe80::a0cf:3cff:fe7c:7056%awdl0 prefixlen 64 scopeid 0xe nd6 options=201<PERFORMNUD,DAD> media: autoselect status: active bridge0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 options=63<RXCSUM,TXCSUM,TSO4,TSO6> ether 32:00:f0:81:a8:01 Configuration: id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0 maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200 root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0 ipfilter disabled flags 0x2 member: en1 flags=3<LEARNING,DISCOVER> ifmaxaddr 0 port 8 priority 0 path cost 0 member: en2 flags=3<LEARNING,DISCOVER> ifmaxaddr 0 port 9 priority 0 path cost 0 member: en3 flags=3<LEARNING,DISCOVER> ifmaxaddr 0 port 10 priority 0 path cost 0 member: en4 flags=3<LEARNING,DISCOVER> ifmaxaddr 0 port 11 priority 0 path cost 0 nd6 options=201<PERFORMNUD,DAD> media: <unknown type> status: inactive utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 2000 inet6 fe80::61db:32d6:4611:1341%utun0 prefixlen 64 scopeid 0x10 nd6 options=201<PERFORMNUD,DAD> en5: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether ac:de:48:00:11:22 inet6 fe80::aede:48ff:fe00:1122%en5 prefixlen 64 scopeid 0x7 nd6 options=201<PERFORMNUD,DAD> media: autoselect status: active

Server kann in Node gestartet werden

require('http') .createServer(function (req, res) { res.end('OK'); }) .listen(3000, '0.0.0.0');

oder Python 2

python -m SimpleHTTPServer 3000
2
Können Sie eine ifconfig-Ausgabe bereitstellen. Ich habe eine Ahnung von dem Problem, muss aber die Schnittstellenkonfiguration bestätigen. Hogstrom vor 6 Jahren 0
Hi @hogstrom Ich habe die ifconfig zum Post hinzugefügt. Vielen Dank. Simon McClive vor 6 Jahren 0
Zwei Dinge. Danke für die ifconfig. Haben Sie Ihren Knoten-Js-Code in einer Form, die Sie mitteilen können, wie Sie das Abhören einrichten? Binden Sie an "0.0.0.0". Seltsam ist, dass es einen anderen Eintrag gibt, den ich nicht verstehe. `192.168.1.113 88: e9: fe: 4c: a3: 58 UHLWIi 2 8 lo0 Dies zeigt, dass Ihre IP an den Loopback gebunden ist. Das ist seltsam für mich, zumindest habe ich es noch nie gesehen. Können Sie einen Code-Ausschnitt bereitstellen, damit ich ihn erneut produzieren kann? Können Sie diesen Befehl auch ausführen, damit wir sehen können, an welche IP-Adresse die App gebunden ist? `netstat -an -f inet -p tcp | grep LISTEN` Hogstrom vor 6 Jahren 0
Ich habe Netzwerke verschoben, aber dasselbe Problem. Netstat-Ausgabe `192.168.0.27/32 link # 12 UCS 1 0 en0` und` 192.168.0.27 88: e9: fe: 4c: a3: 58 UHLWI 1 29 lo0` für Port 3000 Der einzige Datensatz ist dieser `tcp4 0 0 * * .3000 *. * LISTEN`. Knoten / Python-Code oben hinzugefügt, beide sind an 0.0.0.0 gebunden. Simon McClive vor 6 Jahren 0
Sie haben ein sehr seltsames Netzwerk-Setup, was wahrscheinlich der Grund ist. Sind Sie für Ihr Netzwerk verantwortlich oder ist es eine andere Person? Ein normales Setup hätte einige / 24 oder einen anderen Adressbereich auf "en0" anstelle von einzelnen / 32 Adressen und ein vollständiges LAN-Segment dahinter, und ** würde niemals dieselbe Adresse auf "lo" haben. Ist dein Netzwerk in irgendeiner Weise speziell oder warum hast du dieses Setup beendet? dirkt vor 6 Jahren 0

1 Antwort auf die Frage

1
Hogstrom

Beim Versuch, das Problem neu zu erstellen, habe ich eine sporadische Zuordnung der primären IP zur lo0- Schnittstelle festgestellt . Es scheint, dass die Manipulation der Routingtabellen das Problem verursacht.

Um Ihre Netzwerkschnittstelle ohne Neustart auf eine "Standardkonfiguration" zurückzusetzen, können Sie Folgendes tun. (Beachten Sie, im schlimmsten Fall müssen Sie möglicherweise einen Neustart durchführen, wenn es nicht weiter funktioniert.) (Warnung: Dies wird alle vorhandenen IP-Verbindungen und -Dienste unterbrechen ):

  1. Fahren Sie alle Netzwerkdienstprogramme und -dienste wie VPNs herunter
  2. Deaktivieren Sie vorhandene Netzwerkschnittstellen. Bei den meisten MacBooks ist dies en0

Suchen Sie nach der Schnittstelle, die Ihre primäre IP darstellt. Sie können das mit diesem Befehl finden:

ping `hostname`

Porky:Downloads hogstrom$ ping `hostname` PING porky.local (10.0.0.114): 56 data bytes 64 bytes from 10.0.0.114: icmp_seq=0 ttl=64 time=0.055 ms

Suchen Sie in der Ausgabe in Ihrer ifconfigAusgabe nach dieser IP-Adresse (in diesem Fall 10.0.0.114)

ifconfig

 en0: flags=8863 mtu 1500 ether a0:99:9b:1a:a7:f1 inet6 fe80::874:c2c9:c839:ac4a%en0 prefixlen 64 secured scopeid 0x5 inet 10.0.0.114 netmask 0xffffff00 broadcast 10.0.0.255 nd6 options=201 media: autoselect status: active

Notieren Sie den Schnittstellennamen (in diesem Beispiel en0).

  1. Fahren Sie das aktuelle Netzwerk herunter 

    sudo ifconfig en0 down
    `

  2. Spülen Sie die vorhandenen Routen sudo route -n flush

Hinweis: Das Flag -n ist erforderlich. Andernfalls warten Sie längere Zeit auf Netzwerk-Timeouts. welche erwartet werden, da wir die Routingtabelle leeren

Die Routing-Tabelle sieht folgendermaßen aus, wenn der Primary-Server ausgefallen ist und der route -n flushServer einige Male ausgeführt wurde. Ich führe den Befehl dreimal aus.

Routing tables  Internet: Destination Gateway Flags Refs Use Netif Expire 127 127.0.0.1 UCS 0 0 lo0 127.0.0.1 127.0.0.1 UH 1 97314 lo0 224.0.0 link#1 UmCS 1 0 lo0 224.0.0.251 link#1 UHmW3I 0 0 lo0 12
  1. Starten Sie das primäre Herunterfahren der Schnittstelle in Schritt 3. 
sudo ifconfig en0 up

Verwenden Sie den Schnittstellennamen aus Schritt3.

  1. Überprüfen Sie die Netzwerkroutingtabelle:

netstat -rn

Routing tables  Internet: Destination Gateway Flags Refs Use Netif Expire default 10.0.0.1 UGSc 92 0 en0 10/24 link#5 UCS 1 0 en0 10.0.0.1/32 link#5 UCS 2 0 en0 10.0.0.1 2c:fd:a1:2:49:40 UHLWIir 24 5 en0 1198 10.0.0.114/32 link#5 UCS 0 0 en0 10.0.0.255 ff:ff:ff:ff:ff:ff UHLWbI 0 2 en0 127 127.0.0.1 UCS 0 0 lo0 127.0.0.1 127.0.0.1 UH 1 97314 lo0 169.254 link#5 UCS 0 0 en0 224.0.0/4 link#5 UmCS 2 0 en0 224.0.0.251 1:0:5e:0:0:fb UHmLWI 0 0 en0 239.255.255.250 1:0:5e:7f:ff:fa UHmLWI 0 2 en0 255.255.255.255/32 link#5 UCS 0 0 en0

Hinweis: Die primäre IP-Adresse (10.0.0.114 auf meinem System) ist nicht mit lo0 verbunden. Dies war aufgrund der bereitgestellten Diagnosen der Fall. Ich habe dies beim Anpassen der Routing-Tabelle beobachtet, ist aber anomal und höchstwahrscheinlich die Ursache des Problems.

  1. Überprüfen Sie die Netzwerkkonfiguration

Ich teste, indem ich den primären DNS-Server von Google anpinge.

ping 8.8.8.8

Porky:Downloads hogstrom$ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=120 time=25.527 ms

An diesem Punkt sollten Sie über ein funktionierendes Netzwerk verfügen und über Localhost und Ihre primäre IP-Adresse auf Ihren Knotenserver zugreifen können.

Hallo @Hogstrom, vielen Dank, dass Sie sich die Zeit genommen haben, um eine Antwort zu posten. Ich war die letzte Woche in der Wildnis und entschuldige mich für die Verzögerung. Ich habe die oben genannten Schritte durchlaufen und die Netzwerkschnittstelle heruntergefahren und wieder hochgefahren, aber sobald ich einen Server an Port 3000 hochfahre und eine Lock-Anfrage dagegen abfeuere, erscheint die lo0-Verbindung auf derselben IP-Adresse, sodass es so aussieht das Problem leider nicht lösen. Ich werde versuchen, einen sauberen Laptop zu ergattern, der nicht angerührt wurde, und zu sehen, ob ich ihn reproduzieren und ausschließen kann, ob er auf allen Macs oder nur auf den von dieser Firma konfigurierten Macs auftritt. Simon McClive vor 6 Jahren 0
Hallo @SimonMcClive Entschuldigung, ich konnte nicht helfen ... Ich gehe davon aus, dass es Netzwerksoftware (VPN oder andere) gibt, die Sie durcheinander bringt. Viel Glück Hogstrom vor 6 Jahren 0

Verwandte Probleme