localhost do OS-X resolvendo estranhamente

Question

O problema que estou prestes a descrever vejo apenas quando executo alguns testes de unidade Java. No entanto, tenho certeza que a causa é a configuração do OS-X, não o Java, então estou postando para o superusuário que não é o StackOverflow.

Temos um teste de unidade Java que inicializa um servidor incorporado e, em seguida, faz solicitações em http://localhost:9324 . Esses testes costumavam passar antes de eu atualizar para o Yosemite, agora eles falham. Sintomas específicos e coisas que eu tentei:

Resolvendo para a interface AWDL

Eu olhei para o netstat para ver o que estava atingindo a porta 9324. Encontrei isto:

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

então, por algum motivo, o localhost estava resolvendo para um endereço IPV6 e ifconfig mostra que é o endereço de awdl0 . Um pequeno Googling mostra que é a interface que a Apple usa para o compartilhamento ponto a ponto. Observe que nslookup localhost , dig localhost e dscacheutil -q host -a name localhost all retornam 127.0.0.1 conforme o esperado. Então, de alguma forma, o código Java está fazendo a resolução de nomes de forma diferente ou algo assim (então sim, talvez essa seja uma questão Java)

Resolvendo para um endereço externo

Desativar a interface do AWDL via sudo ifconfig awdl0 down fez com que o código parasse de ser interrompido e o netstat informasse basicamente informações corretas:

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

mas observe que, por algum motivo, o código local usando um endereço localhost está atingindo 192.168.0.124 , meu endereço IP externo e esse código está preso em SYN_SENT e será interrompido e nunca uma resposta. Note que isto não é devido às configurações do firewall, pois eu desativei o firewall completamente para este teste.

Conexão recusada

Apesar do uso estranho do endereço externo, há conexões corretas que parecem usar o loopback, mas elas recebem ConnectionRefused erros do Java. No entanto, curl http://localhost:9324 se conecta com sucesso e obtém uma resposta.

Pergunta

Estou bastante perplexo. Isso pode ser um problema de Java, mas suspeito que minha configuração de rede do OS-X esteja funcionando de alguma forma.

Ah, aqui está meu /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

Meu /private/etc/resolv.conf é idêntico.

/ 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

e aqui está a saída se 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

    

Answer 1

Bem-vindo ao mundo pós-IPv4. Quando você usa um utilitário como nslookup ou dig, o padrão é retornar um registro "A". No entanto, com sistemas operacionais e aplicativos modernos habilitados para IPv6, eles normalmente verificarão um registro "AAAA" primeiro para ver se o recurso está disponível no IPv6 antes de recorrer a um recurso IPv4.

Então, o que está acontecendo é que você tem uma entrada IPv4 e uma entrada IPv6 para localhost em seu sistema e quase sempre preferirá o IPv6.

Então, o que você pode fazer sobre isso? Bem, você tem várias opções. Você pode remover a entrada do IPv6 para localhost ou desabilitar o IPv6 completamente, no entanto esta é uma solução menos que ideal e está em vigor "olhando para trás" em vez de seguir em frente.

Em vez disso, você provavelmente deve certificar-se de que seu serviço esteja configurado para ser executado em IPv6 além do IPv4. Você também pode precisar fazer alguns ajustes nas regras do firewall IPv6 para permitir o serviço. Isso prepara você para o futuro quando o IPv6 desloca o IPv4 como o protocolo mainstream.

    

Answer 2

Tente redefinir discoveryd ou liberar seu cache ou reverter para mDNSResponder (o resolvedor DNS anterior ao Yosemite).

Veja como liberar o discoveryd cache:

sudo discoveryutil mdnsflushcache

A reversão para mDNSResponder é descrita aqui:

Ars Technica OS X discoveryd revert