Пользовательский адрес обратной связи IPv6 и проверка связи с ним с другого хоста
Позвольте мне угадать - вы используете Wayland. Я столкнулся с этой проблемой сегодня и решил поделиться решением.
Gnome-Session по какой-то причине имеет жестко закодированное переопределение для SSH_AUTH_SOCK под wayland. См. следующий коммит: https://github.com/GNOME/gnome-session/commit/a8896ccad65583885735a04205351f48a42f29ae
The workaround? Установите переменную окружения, чтобы отключить это поведение: GSM_SKIP_SSH_AGENT_WORKAROUND=1. Это замыкает код настройки окружения.
Для тех, кто обнаружит это и пытается настроить ssh-agent: В моем файле systemd unit для ssh-agent есть следующая строка:
ExecStartPost=/usr/bin/bash -c "/usr/bin/systemctl --user set-environment SSH_AUTH_SOCK=$SSH_AUTH_SOCK GSM_SKIP_SSH_AGENT_WORKAROUND=1"
Полный файл выглядит так:
[Unit]
Description=SSH Agent
IgnoreOnIsolate=true
[Service]
Type=forking
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
ExecStart=/usr/bin/ssh-agent -a $SSH_AUTH_SOCK
ExecStartPost=/usr/bin/bash -c "/usr/bin/systemctl --user set-environment SSH_AUTH_SOCK=$SSH_AUTH_SOCK GSM_SKIP_SSH_AGENT_WORKAROUND=1"
[Install]
WantedBy=default.target
Да. Точно так же, как вы можете сделать это с IPv4, это называется маршрутизацией. Вы должны сообщить одному хосту, как связаться с другим хостом.
Допустим, у нас есть два хоста, A и B.
Хост А имеет петлевой адрес по умолчанию ::1, а также ваш пользовательский адрес в петлевом интерфейсе. (В моем примере пользовательский адрес будет fd56:dcaa:2099::1. Я выбрал это из уникального локального адреса. Вы должны использовать адреса ULA для подобных целей.)
Хост А также имеет интерфейс Ethernet, назовем его eth0. В IPv6 он будет иметь локальный адрес ссылки IPv6. У него могут быть другие адреса IPv6. Вы можете найти их, запустив ip -6 addr eth0. Вот пример из моей системы:
$ ip -6 addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2601:404:ce00:adc0:9d6c:9e16:a9a9:b03b/64 scope global temporary dynamic
valid_lft 593594sec preferred_lft 74600sec
inet6 2601:404:ce00:adc0:bc87:129a:ed5d:814/64 scope global temporary deprecated dynamic
valid_lft 78769sec preferred_lft 0sec
inet6 2601:404:ce00:adc0:1453:3734:6742:4500/64 scope global mngtmpaddr noprefixroute dynamic
valid_lft 2591820sec preferred_lft 604620sec
inet6 fe80::5520:a68f:5416:a68c/64 scope link
valid_lft forever preferred_lft forever
В этом списке четыре разных адреса (у вас может быть больше ). Для наших целей вам нужен тот, который говорит «ссылка на область» после него. В моей системе (и в моем примере )это fe80::5520:a68f:5416:a68c.
На хосте B также есть интерфейс eth0. Чтобы позволить хосту B получить доступ к специальному петлевому адресу хоста A, хосту B нужно знать, где его найти. Вы делаете это, добавляя запись в таблицу маршрутизации хоста B :
# ip route add fd56:dcaa:2099::1 via fe80::5520:a68f:5416:a68c dev eth0
Что мы делаем, так это сообщаем ядру хоста B, что оно может получить доступfd56:dcaa:2099::1(по специальному адресу хоста A на его петлевом интерфейсе )поfe80::5520:a68f:5416:a68c(ссылке хоста A -по локальному адресу на его eth0интерфейсе ), но этому хосту B необходимо попытаться достичь fe80::5520:a68f:5416:a68cс интерфейсаeth0хоста B. (Это сложная вещь, связанная с -локальными адресами ссылок. Сам адрес имеет смысл только в контексте данного сегмента сети. Изучите сетевую модель OSI для получения более подробной информации.)
Когда у вас есть эта запись в таблице маршрутизации хоста B, вы сможете пропинговать пользовательский адрес хоста A с хоста B,поскольку хост B теперь знает, что локальный адрес канала хоста A можно использовать в качестве маршрутизатора для доступа к этому адресу.