☰

OS-X localhost странно разрешается

tag-icon • tag-icon macos networking osx-yosemite
OS-X localhost странно разрешается

Проблема, которую я собираюсь описать, возникает только при запуске некоторых юнит-тестов Java. Однако я почти уверен, что причина в конфигурации OS-X, а не в Java, поэтому я пишу суперпользователю, а не на StackOverflow.

У нас есть модульный тест Java, который запускает встроенный сервер, а затем делает запросы к в http://localhost:9324. Эти тесты проходили до того, как я обновился до Yosemite, теперь они не проходят. Конкретные симптомы и то, что я пробовал:

Разрешение интерфейса AWDL

Я посмотрел netstat, чтобы узнать, что заходит на порт 9324. Нашел следующее:

localhost:platform oliver$ netstat -tn | grep 9324
tcp6       0      0  fe80::b8d2:8eff:.50602 fe80::b8d2:8eff:.9324  SYN_SENT

поэтому по какой-то причине localhost разрешался в адрес IPV6 и ifconfigпоказывает, что это адрес awdl0. Немного поиска в Google показывает, что это интерфейс, который Apple использует для однорангового обмена. Обратите внимание, что nslookup localhost, dig localhostи dscacheutil -q host -a name localhostвсе возвращают 127.0.0.1ожидаемый результат. Так что, каким-то образом код Java выполняет разрешение имен по-другому или что-то в этом роде (так что да, может быть, это вопрос по Java)???

Разрешение внешнего адреса

Отключение интерфейса AWDL через sudo ifconfig awdl0 downпривело к тому, что код перестал зависать, а netstat стал сообщать в основном корректную информацию:

tcp4       0      0  192.168.0.124.52137    192.168.0.124.9324     SYN_SENT   
tcp4       0      0  127.0.0.1.9324         127.0.0.1.52135        ESTABLISHED
tcp4       0      0  127.0.0.1.52135        127.0.0.1.9324         ESTABLISHED

но обратите внимание, что по какой-то причине локальный код, использующий localhostадрес, попадает на 192.168.0.124мойвнешнийip-адрес и этот код застрянет SYN_SENTи будет зависать и никогда не получит ответа. Обратите внимание, что это не из-за настроек брандмауэра, так как я полностью отключил брандмауэр для этого теста.

В соединении отказано

Несмотря на странное использование внешнего адреса, есть корректно выглядящие соединения, которые, кажется, используют обратную связь, но они получают ConnectionRefusedошибки от Java. Тем не менее, curl http://localhost:9324подключается успешно и получает ответ.

Вопрос

Я в полном замешательстве. Это может быть проблема Java, но я подозреваю, что мои настройки сети OS-X как-то испорчены.

О, вот мой /etc/resolv.conf:

#
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.
#
nameserver 10.1.10.1
nameserver 2001:558:feed::1
nameserver 2001:558:feed::2

Мой /private/etc/resolv.conf идентичен.

/etc/hosts это:

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1   localhost
255.255.255.255 broadcasthost
::1             localhost 
fe80::1%lo0     localhost

и вот результат, если ifconfig -a:

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
    options=3<RXCSUM,TXCSUM>
    inet6 ::1 prefixlen 128 
    inet 127.0.0.1 netmask 0xff000000 
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
    nd6 options=1<PERFORMNUD>
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ether 3c:15:c2:da:29:0c 
    nd6 options=1<PERFORMNUD>
    media: autoselect (<unknown type>)
    status: inactive
en1: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
    options=60<TSO4,TSO6>
    ether 72:00:04:0f:34:70 
    media: autoselect <full-duplex>
    status: inactive
en2: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
    options=60<TSO4,TSO6>
    ether 72:00:04:0f:34:71 
    media: autoselect <full-duplex>
    status: inactive
p2p0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2304
    ether 0e:15:c2:da:29:0c 
    media: autoselect
    status: inactive
awdl0: flags=8902<BROADCAST,PROMISC,SIMPLEX,MULTICAST> mtu 1452
    ether ba:d2:8e:05:03:6c 
    nd6 options=1<PERFORMNUD>
    media: autoselect
    status: inactive
bridge0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    options=63<RXCSUM,TXCSUM,TSO4,TSO6>
    ether 3e:15:c2:ad:9e:00 
    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 5 priority 0 path cost 0
    member: en2 flags=3<LEARNING,DISCOVER>
            ifmaxaddr 0 port 6 priority 0 path cost 0
    nd6 options=1<PERFORMNUD>
    media: <unknown type>
    status: inactive
en5: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    options=23<RXCSUM,TXCSUM,TSO4>
    ether 00:24:9b:0f:3c:02 
    inet6 fe80::224:9bff:fe0f:3c02%en5 prefixlen 64 scopeid 0xc 
    inet 192.168.0.50 netmask 0xffffff00 broadcast 192.168.0.255
    inet6 2601:1c0:c901:980e:224:9bff:fe0f:3c02 prefixlen 64 autoconf 
    inet6 2601:1c0:c901:980e:4041:88e9:46e8:a893 prefixlen 64 autoconf temporary 
    nd6 options=1<PERFORMNUD>
    media: autoselect (1000baseT <full-duplex,flow-control,energy-efficient-ethernet>)
    status: active

решение1

Добро пожаловать в мир после IPv4. Когда вы используете утилиту вроде nslookup или dig, по умолчанию возвращается запись "A". Однако современные операционные системы и приложения с поддержкой IPv6 обычно сначала проверяют наличие записи "AAAA", чтобы узнать, доступен ли ресурс по IPv6, прежде чем прибегать к ресурсу IPv4.

Итак, происходит следующее: у вас есть как запись IPv4, так и запись IPv6 длялокальный хоств вашей системе, и он почти всегда будет отдавать предпочтение IPv6.

Итак, что вы можете сделать по этому поводу? Ну, у вас есть несколько вариантов. Вы можете удалить запись IPv6 длялокальный хостили полностью отключить IPv6, однако это не идеальное решение и по сути является «взглядом назад», а не движением вперед.

Вместо этого вам, вероятно, следует убедиться, что ваша служба настроена на работу на IPv6 в дополнение к IPv4. Вам также может потребоваться внести некоторые изменения в правила брандмауэра IPv6, чтобы разрешить службу. Это подготовит вас к будущему, когда IPv6 заменит IPv4 в качестве основного протокола.

решение2

Попробуйте сбросить настройки discoverydили очистить кэш, либо вернуться к mDNSResponder (прежде чем Yosemite DNS-резолвер).

Вот как очистить discoverydкэш:

sudo discoveryutil mdnsflushcache

Возврат к mDNSResponder описан здесь:

Ars Technica OS X discoveryd revert

Связанный контент