(Я понял, что это связано с nscd ; пожалуйста, смотрите в нижней части вопроса)

Я пытаюсь подключиться к автономному серверу через свой ноутбук; они совместно используют проводную связь через беспроводной маршрутизатор Linksys и коммутатор Ethernet TP-Link. Я использую Arch Linux на обеих машинах, используя настройки Systemd по умолчанию с dhcpcd для конфигурации сети.

После недавнего обновления системы на ноутбуке, я начал испытывать следующую ошибку при попытке ssh к серверу (назовем это "myserver"):

$ ssh -v -v -F /dev/null myserver
OpenSSH_7.7p1, OpenSSL 1.1.0h  27 Mar 2018
debug1: Reading configuration data /dev/null
debug2: resolving "myserver" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to myserver [fe80::9cd8:b045:5974:c5cf] port 22.
debug1: connect to address fe80::9cd8:b045:5974:c5cf port 22: Invalid argument
ssh: connect to host myserver port 22: Invalid argument

Выполнение той же команды с помощью strace показывает, что ошибка происходит из-за connect:

connect(3, {sa_family=AF_INET6, sin6_port=htons(22), inet_pton(AF_INET6, "fe80::9cd8:b045:5974:c5cf", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)

Однако ping myserver работает нормально:

$ ping myserver    
PING myserver(myserver (fe80::9cd8:b045:5974:c5cf)) 56 data bytes
64 bytes from myserver (fe80::9cd8:b045:5974:c5cf%en0): icmp_seq=1 ttl=64 time=0.533 ms
64 bytes from myserver (fe80::9cd8:b045:5974:c5cf%en0): icmp_seq=2 ttl=64 time=0.549 ms

Обычно у меня есть локальное named перенаправление DNS-запросов, но ошибка сохраняется, когда я возвращаюсь к использованию DNS-сервера маршрутизатора напрямую:

$ sudo cat /etc/resolv.conf
# Generated by resolvconf
nameserver 192.168.1.1

Ошибка периодически: каждые несколько минут я могу успешно подключиться. Когда я могу подключиться успешно, я вижу, что connect использует адрес IPv4:

connect(3, {sa_family=AF_INET, sin_port=htons(22), sin_addr=inet_addr("192.168.1.149")}, 16) = 0

Однако команда host показывает один и тот же IPv4-адрес независимо от того, работает соединение или разорвано:

$ host myserver                   
myserver has address 192.168.1.149

Прочитав этот вопрос, я решил указать интерфейс вручную (ssh -v -v -F /dev/null -B en0 myserver). Это устраняет ошибку, когда она возникает, но это не постоянное решение для меня, и это не объясняет, почему ошибка внезапно появилась.

Я использовал while цикла в моей оболочке , чтобы определить время с точностью до секунды , когда ssh идет от работы не работает, и наоборот, и я был не в состоянии связать эти события с чем - либо на выходе journalctl включая dhcpcd Сообщения.

Первоначально я опубликовал это в Network Engineering, где конфигурация хоста оказывается не по теме. На этом сайте пользователь Ricky Beam разместил частичный ответ:

Что бы ни делалось при разрешении имени хоста, возвращаются локальные IPv6-адреса канала (-ов), которые недопустимы для выбранного интерфейса, то есть "любой". Локальные адреса должны указывать интерфейс - например, fe80:...:1% eth0

Почему вы получаете локальный адрес ссылки, неизвестно. Возможно, люди, знакомые с Arch Linux, могли бы оказать дальнейшую помощь.


Обновление: похоже, проблема с nscd "демон кеширования службы имен", который объясняет прерывистость, с которой я столкнулся (вероятно, из-за истечения срока действия кеша). Это фиксируется с помощью:

sudo systemctl stop nscd.service

Когда я останавливаю ncsd, тогда ssh может подключиться, используя локальный адрес канала, но на этот раз вызов connect также указывает мой основной интерфейс "en0", и он успешно выполняется:

connect(3, {sa_family=AF_INET6, sin6_port=htons(22), inet_pton(AF_INET6, "fe80::9cd8:b045:5974:c5cf", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=if_nametoindex("en0")}, 28) = 0
write(2, "debug1: Connection established.\r"..., 33) = 33

Я предполагаю, что оставшийся вопрос (который я мог бы задать отдельно), это ошибка в nscd, и мне вообще следует использовать nscd?

1 ответ1

0

Когда я принес Raspberry Pi в сеть, эта проблема проявилась по-новому, и я смог наконец ее диагностировать.

Проблема связана с systemd-resolved . Это влияет на других пользователей, см., Например, Спросить Ubuntu nslookup находит ip, но ping не выполняет или systemd-resolved не запрашивает сервер DNS для локального домена .

Я предполагал, что ssh myserver вызовет DNS- myserver . Однако, это не так в моей системе, вот nsswitch.conf по умолчанию:

$ cat /etc/nsswitch.conf
# Name Service Switch configuration file.
# See nsswitch.conf(5) for details.
...
hosts: files mymachines myhostname resolve [!UNAVAIL=return] dns
...

Компонент resolve является systemd-resolved , который представляет собой проект Леннарта Поэттеринга для реализации многоадресного DNS- протокола Zeroconf и разрешения многоадресных имен локального канала.

[!UNAVAIL=return] означает, что когда доступно systemd-resolved хоста DNS никогда не используется. Обычно это не проблема, поскольку systemd-resolved также может создавать DNS-запросы. Однако он, очевидно, не делает этого для однокомпонентных имен хостов, таких как myserver , даже когда DNS-сервер находится на моем локальном маршрутизаторе (192.168.1.1). Это связано с тем, что имена хостов с одной меткой не должны быть доступны внешней сети, как объяснил Леннарт в этом потоке Github.

Это объясняет тот факт, что host myserver IPv4-адрес (от маршрутизатора), в то время как ssh myserver IPv6-адрес (из многоадресной DNS или LLNR, не уверен, какой именно).

Я был смущен этим, потому что я никогда не узнавал о многоадресной DNS или LLNR или IPv6. Я никогда не узнал об этих технологиях, потому что думал, что мне знакомы технологии IPv4 и DNS.

Очевидно, systemd-resolved необходим не только для создания запросов Zeroconf, но и для ответа на них. Raspberry Pi, который я принес в свою сеть, почему -то остановил systemd-resolved , поэтому, хотя я смог найти имя хоста с помощью host и dig , я не смог увидеть его через ssh или ping:

$ ping raspberrypi
ping: raspberrypi: Name or service not known
[2]$ host raspberrypi
raspberrypi has address 192.168.1.135

Это привело меня к первому отчету об ошибке Ask Ubuntu, который привел меня к решению. Если я запускаю systemd-resolved на Pi, то я могу ping и ssh . Однако, если я отключаю systemd-resolved локально, я также могу ping и ssh к Pi.

Сейчас я только что отключил systemd-resolved на всех своих системах,

$ sudo systemctl stop systemd-resolved.service
$ sudo systemctl disable systemd-resolved.service

поскольку это, кажется, создает проблемы с GNU libc для nscd и так как это требует от меня изучения таких технологий, как IPv6, mDNS и LLNR, в которых я сейчас не нуждаюсь, - потому что все мои компьютеры подключены к базовому потребительскому маршрутизатору, который предоставляет знакомые технологии DNS и NAT "из коробки".

Спасибо тем, кто прокомментировал мой первоначальный вопрос, но в конце концов не было необходимости «настраивать себе префикс ULA, или получать глобальное подключение IPv6, или и то, и другое» через »настройку в домашнем маршрутизаторе, если это не полная часть **** или "кричать на своего провайдера". Мне просто пришлось отключить некоторые из новых программ Леннарта, чтобы убрать себя с кровоточащего края. В потоке Github обсуждается, действительно ли программное обеспечение ведет себя правильно, но я нахожусь в том же положении, что и многие другие пользователи: потратив часы времени на выяснение того, что systemd-resolved является виновником, я бы предпочел не тратить больше часами пытаюсь понять, как это исправить, при отключении это так легко.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .