При настройке локальной сети Wi-Fi в небольшом месте от провайдера, такого как Verizon, с использованием маршрутизатора и модема машинам в сети назначаются частные IP-адреса.
В такой локальной сети Wi-Fi я могу использовать ssh name@<hostname> для доступа к SSH-серверу на другом компьютере <hostname>, где <hostname> это результат команды hostname. Выход hostname разрешен на частный IP-адрес каким-то DNS-сервером (возможно, на маршрутизаторе?)?
Но я слышал это выход hostname не имеет отношения к разрешению имени хоста DNS. Тогда почему я могу успешно бежать ssh name@<hostname>, где <hostname> это результат команды hostname?
Здесь может сработать пара механизмов.
Во-первых, система часто будет включать свое локально настроенное имя хоста в качестве идентификатора клиента DHCP, а маршрутизатор (который также является сервером DHCP и DNS) будет динамически добавлять запись DNS для этого идентификатора клиента, соответствующего IP-адресу, который он выдал для этого запроса. .
Другой вероятный случай состоит в том, что система рекламирует свое локально настроенное имя хоста с помощью Multicast DNS Service Discovery (через службы Bonjour в macOS или демона avahi в Linux), и многие современные дистрибутивы по умолчанию включают mDNS в свою цепочку поиска NSS.
Системы Linux, использующие nss-myhostname, будут разрешать текущее настроенное локальное имя хоста (которое в некоторых системах происходит из / etc / hostname), когда вы используете getaddrinfo/gethostbyname. Системы без nss-myhostname обычно имеют локальное имя хоста, указанное в /etc/hosts, и таким образом разрешите локальное имя хоста.
Если вы специально выполняете поиск по DNS (например, с помощью nslookup или dig), который обходит nss и использует только dns, поэтому nss-myhostname не имеет возможности повлиять на результат.
Если вы хотите ssh@<hostname> для работы с других устройств убедитесь, что имя хоста разрешается в dns или указано в /etc/hosts на этих устройствах.