No se puede resolver hostname.local en LAN

No se puede resolver hostname.local en LAN

Solía ​​​​poder cambiar de máquina en mi LAN pero ya no funciona. Puedo hacer ssh usando la IP, por supuesto, pero es DHCP, por lo que puede cambiar de vez en cuando. Ambas máquinas ejecutan Debian 9.12, una es una máquina virtual en un host de Windows, pero aun así funcionó; No he jugado con los archivos de configuración, solo actualizaciones periódicas.ssh [email protected]

ping hostname.local
ping: hostname.local: Name or service not known

(Puede que no sea exactamente ese mensaje según lo traduzco del francés)

ssh hostname.local
ssh: Could not resolve hostname hostname.local: Name or service not known

(salidas ssh en inglés)

De avahi.org:

Avahi es un sistema que facilita el descubrimiento de servicios en una red local a través del conjunto de protocolos mDNS/DNS-SD

He investigado /etc/resolv.conf, /etc/avahi/avahi-daemon.confpero /etc/nsswitch.confes una configuración estándar lista para usar.

/etc/resolv.conf(se reinicia network-managercada vez que comienza)

# Generated by NetworkManager
search lan
nameserver xx.xx.xx.xx # DNS IPs obtained from DHCP
nameserver xx.xx.xx.xx 

man resolv.confdice que la searchlista contiene solo el nombre de dominio local de forma predeterminada (algo así, lo traduje de la página de manual en francés); ¿No debería ser localen lugar de lan?

Intenté cambiarlo y hacer ping o ssh a otro host en mi LAN de inmediato (sin reiniciar el administrador de red), no funcionó. Y cuando reinicio el administrador de red, lo reescribe /etc/resolv.confy lo configura search lan.

/etc/nsswitch.conf(por defecto, no he realizado ningún cambio)

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat
group:          compat
shadow:         compat
gshadow:        files

hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Intenté descubrir hosts y servicios con avahi-browsey nbtscan, que dependen de avahi (zeroconf/Bonjour), pero parecen encontrar solo el host en el que se ejecutan.

(Sé que esto es un posible duplicado de otras preguntas, pero no encontré ninguna respuesta y no tengo suficiente reputación para hacer nada)

Respuesta1

Lo encontré !

Parece que mi enrutador tiene un servidor DNS:

nslookup host_ip router_ip
Server:     192.168.1.254
Address:    192.168.1.254#53

69.1.168.192.in-addr.arpa   name = hostname.lan.

Entonces eso responde a la pregunta .localvs..lanEn Debian reciente, el dominio local es .lan.

Aún así, ping hostname.landevuelve un host desconocido.

Gracias ahttps://askubuntu.com/questions/623940/network-manager-how-to-stop-nm-updating-etc-resolv-conf, descubrí que /etc/resolv.confes un enlace simbólico a /var/run/NetworkManager/resolv.conf; así que tuve quereemplazarlo con el míoresolv.conf:

search lan
nameserver 192.168.1.254

para que utilice el DNS del enrutador (que enrutará las consultas si es necesario).

Reiniciando el administrador de red systemctl restart network-managery funciona de maravilla:

$ ping hostname.lan
PING hostname.lan (192.168.1.69) 56(84) bytes of data.
64 bytes from hostname.lan (192.168.1.69): icmp_seq=1 ttl=64 time=2.02 ms

( ping google.frpara asegurarse de que se procesen las consultas WAN)

Respuesta2

En mi caso, la razón por la que no se podía acceder a un host en particular en la red a través del prefijo .local fue simplemente porque el servicio avahi daemon se había detenido en ese host:

[~][0]$ service avahi-daemon status
○ avahi-daemon.service - Avahi mDNS/DNS-SD Stack
     Loaded: loaded (/lib/systemd/system/avahi-daemon.service; disabled; preset: enabled)
     Active: inactive (dead)
TriggeredBy: ○ avahi-daemon.socket
[~][3]$ service avahi-daemon start
[~][0]$ 
█[~][0]$ ping asus.local
PING asus.local (192.168.1.204) 56(84) bytes of data.
64 bytes from 192.168.1.204 (192.168.1.204): icmp_seq=1 ttl=64 time=0.892 ms
64 bytes from 192.168.1.204 (192.168.1.204): icmp_seq=2 ttl=64 time=0.848 ms
64 bytes from 192.168.1.204 (192.168.1.204): icmp_seq=3 ttl=64 time=0.784 ms
^C

Respuesta3

No debería necesitar un FQDN; solo usa la parte del host. Por ejemplo:

`[root@darouter ~]# arping -I enp2s0f1 matilda
ARPING 192.168.100.12 from 192.168.100.254 enp2s0f1
Unicast reply from 192.168.100.12 [D0:67:E5:EB:37:25]  0.759ms
Unicast reply from 192.168.100.12 [D0:67:E5:EB:37:25]  0.801ms
Unicast reply from 192.168.100.12 [D0:67:E5:EB:37:25]  0.732ms
Sent 3 probes (1 broadcast(s))
Received 3 response(s)`

Usé arping ya que matilda es una caja de viento; eso era más fácil que descubrir cómo permitir el ping entrante. Yo desactivaría el DNS en el enrutador. AlládeberíaSea un lugar para colocar la IP del servidor DNS para que pueda usar su DNS interno. Si su DNS interno no se resuelve por nombre de host, debe averiguar dónde está rota su configuración de DNS. Tuve este problema hace un tiempo. Lamentablemente eso fue hace un tiempo; y como no recuerdo lo que hice ayer no puedo darte una respuesta definitiva de lo que hice para solucionarlo.

¡Espero que esto ayude!

Todh

información relacionada