☰

Não é possível resolver hostname.local na LAN

tag-icon • tag-icon debian lan avahi
Não é possível resolver hostname.local na LAN

Eu costumava fazer isso entre máquinas na minha LAN, mas não está mais funcionando. Posso fazer ssh usando o IP, é claro, mas é DHCP, então pode mudar de tempos em tempos. Ambas as máquinas rodam Debian 9.12, uma é uma VM em um host Windows, mas ainda assim funcionou; Não brinquei com os arquivos de configuração, apenas atualizações regulares.ssh [email protected]

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

(pode não ser exatamente essa mensagem, pois traduzo do francês)

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

(saídas ssh em inglês)

De avahi.org:

Avahi é um sistema que facilita a descoberta de serviços em uma rede local através do conjunto de protocolos mDNS/DNS-SD

Eu olhei para /etc/resolv.conf, /etc/avahi/avahi-daemon.conf, /etc/nsswitch.confmas é uma configuração padrão pronta para uso.

/etc/resolv.conf(redefinir network-managercada vez que inicia)

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

man resolv.confdiz que a searchlista contém apenas o nome de domínio local por padrão (algo assim, traduzi da página de manual em francês); não deveria ser localem vez de lan?

Tentei alterá-lo e fazer ping ou ssh em outro host na minha LAN imediatamente (sem reiniciar o gerenciador de rede), não funcionou. E quando eu reinicio o gerenciador de rede, ele reescreve /etc/resolv.confe define search lan.

/etc/nsswitch.conf(padrão, não fiz nenhuma alteração)

# /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

Tentei descobrir hosts e serviços com avahi-browseand nbtscan, que dependem do avahi (zeroconf/Bonjour), mas eles parecem encontrar apenas o host no qual são executados.

(Sei que esta é uma possível duplicata de outras perguntas, mas não encontrei nenhuma resposta e não tenho reputação suficiente para fazer nada)

Responder1

Encontrei !

Parece que meu roteador realmente possui um 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.

Então isso responde à pergunta .localvs..lanNo Debian recente, o domínio local é .lan.

Ainda assim, ping hostname.lanretorna host desconhecido.

Graças ahttps://askubuntu.com/questions/623940/network-manager-how-to-stop-nm-updating-etc-resolv-conf, descobri que /etc/resolv.confé um link simbólico para /var/run/NetworkManager/resolv.conf; então eu tive quesubstitua-o pelo meuresolv.conf:

search lan
nameserver 192.168.1.254

para que utilize o DNS do roteador (que encaminhará as consultas se necessário).

Reiniciando o gerenciador de rede systemctl restart network-managere funciona perfeitamente:

$ 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 garantir que as consultas WAN sejam processadas)

Responder2

No meu caso, o motivo pelo qual um host específico na rede não estava acessível através do prefixo .local foi simplesmente porque o serviço daemon avahi foi interrompido naquele 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

Responder3

Você não deveria precisar de um FQDN; basta usar a parte do host. Por exemplo:

`[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)`

Usei arping porque matilda é uma caixa windoz; isso foi mais fácil do que descobrir como permitir a entrada de ping. Eu desabilitaria o DNS no roteador. Ládeveseja um lugar para colocar um ip do servidor DNS para que você possa usar seu DNS interno. Se o seu DNS interno não estiver resolvendo pelo nome do host, você precisará descobrir onde a configuração do seu DNS está quebrada. Eu tive esse problema há algum tempo. Infelizmente isso foi há algum tempo; e como não me lembro do que fiz ontem, não posso dar uma resposta definitiva do que fiz para resolver.

Espero que isto ajude!

Todh

informação relacionada