0 votos

"respuesta de una fuente inesperada" al usar una dirección de resolución IPv6 de enlace local

Recientemente he estado tratando de configurar IPv6 correctamente para todo en mi red, sin embargo he tenido un problema al usar mi resolver Pihole desde macOS Monterey.

Dado que el prefijo IPv6 público puede cambiar, estoy distribuyendo su dirección IPv6 de enlace local en mi red local, lo cual está causando un problema en mi Mac. Lo siguiente lo demuestra claramente:

  ~ dig @fe80::fea5:8099:fe4f:8ac6%en0 google.com     
;; respuesta de una fuente inesperada: fe80:e::fea5:8099:fe4f:8ac6%14#53, esperado fe80::fea5:8099:fe4f:8ac6%14#53
^C%    
  ~ nslookup google.com fe80::fea5:8099:fe4f:8ac6%en0
;; respuesta de una fuente inesperada: fe80:e::fea5:8099:fe4f:8ac6%14#53, esperado fe80::fea5:8099:fe4f:8ac6%14#53
^C  
  ~ nslookup google.com fe80:e::fea5:8099:fe4f:8ac6%en0
Servidor:     fe80:e::fea5:8099:fe4f:8ac6%en0
Dirección:    fe80:e::fea5:8099:fe4f:8ac6%14#53

Respuesta no autorizada:
Nombre:   google.com
Dirección: 142.250.81.238

  ~ ping6  fe80::fea5:8099:fe4f:8ac6%en0 
PING6(56=40+8+8 bytes) fe80::1c4c:232:1096:128a%en0 --> fe80::fea5:8099:fe4f:8ac6%en0
16 bytes desde fe80::fea5:8099:fe4f:8ac6%en0, icmp_seq=0 hlim=64 tiempo=5.584 ms
16 bytes desde fe80::fea5:8099:fe4f:8ac6%en0, icmp_seq=1 hlim=64 tiempo=2.664 ms

  ~ ping6  fe80:e::fea5:8099:fe4f:8ac6%en0
PING6(56=40+8+8 bytes) fe80::1c4c:232:1096:128a%en0 --> fe80::fea5:8099:fe4f:8ac6%en0
16 bytes desde fe80::fea5:8099:fe4f:8ac6%en0, icmp_seq=0 hlim=64 tiempo=6.354 ms
16 bytes desde fe80::fea5:8099:fe4f:8ac6%en0, icmp_seq=1 hlim=64 tiempo=2.965 ms

  ~ ifconfig
en0: banderas=8863 mtu 1500
    opciones=6463
    ether bc:d0:74:43:e1:d6 
    inet6 fe80::1c4c:232:1096:128a%en0 prefijo 64 asegurado scopeid 0xe 
    [...]

Parece que algo inserta un ID de subred incorrecto (que siempre coincide con el ID de alcance de ifconfig, pero cambia en cada reinicio) en la dirección, pero también puede eliminarlo, simplemente no lo hace correctamente en las consultas DNS. Ejecutar Wireshark en esas consultas DNS confirma que en el adaptador de red real los paquetes tienen las direcciones IPv6 correctas (sin ID de subred). Por lo tanto, creo que esto está en alguna parte dentro del sistema operativo.

Leí aquí que macOS inserta el ID de subred para la identificación del adaptador de red en el kernel, por lo que parece que no se elimina. Eso me llevaría a creer que es un error en el kernel, pero ha pasado desapercibido durante muchos años (¿IPv6 no es tan nuevo?).

Las máquinas que no son de macOS no tienen este problema y resuelven estos nombres correctamente y macOS también resuelve totalmente bien con la dirección pública enrutada también.

¿Alguna idea de qué podría ser/cómo solucionarlo?

1voto

Josh Puntos 21

Esto parece haber sido resuelto en algún momento. No puedo reproducirlo con macOS 13.5.

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X