Невозможно получить ответ на запрос curl против частного IP-адреса компьютера в OSX

578
Simon McClive

У меня возникла интересная проблема, которую я изо всех сил пытаюсь докопаться до сути, и приветствую любые идеи о том, что может происходить.

Я использую Macbook Pro на OSX 10.13.6.

Моя проблема заключается в следующем ... Я запускаю привязку сервера узла ко всем интерфейсам через 0.0.0.0адрес. Я в состоянии Curl localhost:3000и 127.0.0.1:3000успешно ударить сервер и получить ответ.

Когда я пытаюсь свернуть свой частный IP-адрес с моего компьютера, curl 192.168.1.113:3000сервер получает запрос и отправляет ответ, однако ответ никогда не получен. Коллеги в сети успешно могут свернуть мой частный IP и получить ответ.

Вот что я наблюдал до сих пор.

Я сбрасываю мои таблицы маршрутизации netstat -rnвыглядит следующим образом.

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 

У моего личного IP есть запись 192.168.1.113/32, которая связана с интерфейсом en0. Когда я получаю доступ к серверу, используя curl на localhost и 127.0.0.1, в моих таблицах маршрутизации ничего не меняется.

Сразу после получения доступа curl 192.168.1.113:3000с моего компьютера в таблице маршрутизации появляется новая запись, как показано ниже.

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 

Линия имеет интерфейс шлюза, который является интерфейсом en0 и связан с замкнутым интерфейсом.

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

Мне интересно, если ответные пакеты неправильно маршрутизируются при выполнении запроса изнутри хоста. Вся помощь приветствуется.

РЕДАКТИРОВАТЬ -> ifconfig ниже

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 

Сервер может быть запущен в узле

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

или Python 2

python -m SimpleHTTPServer 3000 
2
Можете ли вы предоставить вывод ifconfig. У меня возникли некоторые проблемы, но мне нужно подтвердить конфигурацию интерфейса. Hogstrom 5 лет назад 0
Привет @hogstrom Я добавил ifconfig к сообщению. Благодарю. Simon McClive 5 лет назад 0
Две вещи. Спасибо за ifconfig. У вас есть JS-код вашего узла в форме, которой вы можете поделиться, как вы настраиваете прослушивание? Привязываете ли вы к «0.0.0.0». Странно, что есть еще одна запись, которую я не понимаю. `192.168.1.113 88: e9: fe: 4c: a3: 58 UHLWIi 2 8 lo0` Это показывает, что ваш IP связан с обратной связью. Это странно для меня, по крайней мере, я никогда не видел это. Можете ли вы предоставить фрагмент кода, чтобы я мог воспроизвести заново? Можете ли вы также выполнить эту команду, чтобы мы могли видеть, к какому IP-адресу привязано приложение? `netstat -an -f inet -p tcp | grep LISTEN` Hogstrom 5 лет назад 0
Я переместил сети, но та же проблема. Вывод Netstat `192.168.0.27/32 ссылка № 12 UCS 1 0 en0` и` 192.168.0.27 88: e9: fe: 4c: a3: 58 UHLWIi 1 29 lo0` для порта 3000 единственная запись - это `tcp4 0 0 * .3000 *. * СЛУШАТЬ`. Добавленный код узла / питона выше, оба привязаны к 0.0.0.0. Simon McClive 5 лет назад 0
У вас очень странная настройка сети, что, скорее всего, является причиной. Вы несете ответственность за свою сеть, или это другой человек? Нормальная установка будет иметь некоторый / 24 или другой диапазон адресов на `en0` вместо одиночных / 32 адресов, и полный сегмент ЛВС за ним, и он ** никогда ** не будет иметь такой же адрес на` lo`. Является ли ваша сеть какой-то особенной, или почему вы в конечном итоге с этой настройкой? dirkt 5 лет назад 0

1 ответ на вопрос

1
Hogstrom

В попытке воссоздать проблему я видел спорадическое назначение основного IP- адреса интерфейсу lo0 . Похоже, что манипулирование таблицами маршрутизации является причиной проблемы.

Чтобы сбросить сетевой интерфейс к конфигурации по умолчанию без перезагрузки, вы можете сделать следующее. (Обратите внимание, что в худшем случае вам, возможно, придется перезагрузиться, если что-то не работает) (Внимание: это БУДЕТ РАЗРЫВАТЬ все существующие IP-соединения и службы):

  1. Отключите все сетевые утилиты и сервисы, такие как VPN
  2. Отключить существующие сетевые интерфейсы. На большинстве MacBook это будет en0

Ищите интерфейс, который представляет ваш основной IP. Вы можете найти это с помощью этой команды:

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 

Ищите этот IP-адрес (в данном случае это 10.0.0.114) в выходных данных в ifconfigвыходных данных.

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 

Обратите внимание на имя интерфейса (в этом примере это en0)

  1. Отключить текущую сеть

    sudo ifconfig en0 down
    `

  2. Очистить существующие маршруты sudo route -n flush

Примечание: флаг -n необходим, иначе вы в конечном итоге будете ждать длительные периоды ожидания сети; которые ожидаются, когда мы очищаем таблицу маршрутизации.

Вот как выглядит таблица маршрутизации, когда основной не работает, и route -n flushон был запущен несколько раз. Я выполняю команду три раза.

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. Поднимите выключение основного интерфейса в шаге 3.
sudo ifconfig en0 up

Используйте имя интерфейса из шага 3.

  1. Проверьте таблицу сетевой маршрутизации:

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 

Примечание: основной IP-адрес (10.0.0.114 в моей системе) не связан с lo0, что было основано на предоставленной диагностике. Я наблюдал это при настройке таблицы маршрутизации, но это аномально и, скорее всего, причина проблемы.

  1. Проверьте конфигурацию сети

Я проверяю, пингуя основной DNS-сервер Google.

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 

На этом этапе вы должны иметь работающую сеть и иметь доступ к серверу вашего узла, используя как localhost, так и ваш основной IP-адрес.

Привет @Hogstrom, спасибо, что нашли время опубликовать ответ, я был в пустыне на прошлой неделе, поэтому извиняюсь за задержку. Я выполнил описанные выше действия, отключив и снова включив сетевой интерфейс, но как только я подключил сервер к порту 3000 и сгенерировал против него запрос curl, соединение lo0 снова появляется на том же IP-адресе, так что это выглядит так не решая проблему, к сожалению. Я попытаюсь достать чистый ноутбук, который не трогали, и посмотреть, смогу ли я воспроизвести и исключить, произойдет ли это на всех компьютерах Mac или только на тех, которые настроены этой компанией. Simon McClive 5 лет назад 0
Привет @SimonMcClive извините, я не мог помочь ... Я предполагаю, что есть какое-то сетевое программное обеспечение (VPN или другое), которое вас портит. Удачи Hogstrom 5 лет назад 0