El problema que estoy a punto de describir solo lo veo cuando ejecuto algunas pruebas unitarias de Java. Sin embargo, estoy bastante seguro de que la causa es la configuración de OS-X, no de Java, por lo que estoy publicando en superusuario, no en StackOverflow.
Tenemos una prueba unitaria de Java que inicia un servidor integrado y luego realiza solicitudes en http://localhost:9324. Estas pruebas solían pasar antes de que actualizara a Yosemite, ahora fallan. Síntomas específicos y cosas que he probado:
Resolviendo a la interfaz AWDL
Miré netstat para ver qué estaba llegando al puerto 9324. Encontré esto:
localhost:platform oliver$ netstat -tn | grep 9324
tcp6 0 0 fe80::b8d2:8eff:.50602 fe80::b8d2:8eff:.9324 SYN_SENT
entonces, por alguna razón, localhost se estaba resolviendo en una dirección IPV6 y ifconfigmuestra que es la dirección de awdl0. Una pequeña búsqueda en Google muestra que esa es la interfaz que Apple utiliza para compartir de igual a igual. Tenga en cuenta que nslookup localhosty dig localhosttodos dscacheutil -q host -a name localhostregresan 127.0.0.1como se esperaba. Entonces, de alguna manera el código Java está resolviendo el nombre de manera diferente o algo así (entonces sí, ¿quizás esta sea una pregunta de Java)?
Resolver en dirección externa
Al desactivar la interfaz AWDL, sudo ifconfig awdl0 downel código dejó de colgarse y netstat informó información básicamente correcta:
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
pero tenga en cuenta que, por alguna razón, el código local que usa una localhostdirección ingresa 192.168.0.124, miexternodirección IP y ese código está atascado SYN_SENTy se bloqueará y nunca obtendrá una respuesta. Tenga en cuenta que esto no se debe a la configuración del firewall, ya que lo desactivé por completo para esta prueba.
Conexión denegada
A pesar del uso extraño de la dirección externa, hay conexiones que parecen correctas que parecen usar el loopback, pero reciben ConnectionRefusederrores de Java. Sin embargo, curl http://localhost:9324se conecta correctamente y obtiene una respuesta.
Pregunta
Estoy bastante perplejo. Esto podría ser un problema de Java, pero sospecho que la configuración de mi red OS-X está fallada de alguna manera.
Oh, aquí está mi /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
Mi /private/etc/resolv.conf es idéntico.
/etc/hosts es:
##
# 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
y aquí está el resultado si 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
Respuesta1
Bienvenido al mundo posterior a IPv4. Cuando utiliza una utilidad como nslookup o dig, el valor predeterminado es devolver un registro "A". Sin embargo, con los sistemas operativos y aplicaciones modernos habilitados para IPv6, normalmente primero buscarán un registro "AAAA" para ver si el recurso está disponible a través de IPv6 antes de recurrir a un recurso IPv4.
Entonces, lo que sucede es que tienes una entrada IPv4 y una entrada IPv6 paraservidor localen su sistema y casi siempre preferirá IPv6.
Entonces, ¿qué puedes hacer al respecto? Bueno, tienes varias opciones. Puede eliminar la entrada IPv6 paraservidor localo deshabilitar IPv6 por completo; sin embargo, esta no es una solución ideal y, de hecho, es "mirar hacia atrás" en lugar de avanzar.
En su lugar, probablemente debería asegurarse de que su servicio esté configurado para ejecutarse en IPv6 además de IPv4. Es posible que también deba realizar algunos ajustes en las reglas de su firewall IPv6 para permitir el servicio. Esto lo prepara para el futuro cuando IPv6 desplace a IPv4 como protocolo principal.
Respuesta2
Intente restablecer discoverydo vaciar su caché, o volver a mDNSResponder (el solucionador de DNS anterior a Yosemite).
A continuación se explica cómo vaciar el discoverydcaché:
sudo descubrimientoutil mdnsflushcache
La reversión a mDNSResponder se describe aquí: