один конфиг на три устройства — выкидывают друг друга

Весной поднял wireguard на сервере в UK и раздал домашним ленивым способом: один конфиг, qr сфотографировали прямо с моего экрана — телефон жены, планшет, мой ноут. Три недели тишина, потом пошло по кругу: у жены «впн отваливается», на ноуте сессия замирает, планшет вообще живёт своей жизнью.

Полез на сервер, wg show — и сразу видно: у пира latest handshake прыгает между двумя endpoint с разницей в минуту. Телефон подключился — выкинул ноут, ноут переподключился — выкинул телефон. Один приватный ключ на три устройства, сервер держит одну сессию на public key, побеждает тот, кто позже пожал руки.

Лечится за пять минут: каждому устройству свой ключ, свой [Peer] и свой адрес из подсети. Ключ — это устройство, а не человек. Теперь у жены на телефоне и планшете разные пиры, и wg show показывает три спокойные строки вместо одной дёргающейся.

Кто как ведёт учёт пиров — нумеруете по устройствам, по людям, или у всех как у меня весной?

lexa92 писал:
qr сфотографировали прямо с моего экрана — телефон жены, планшет, мой ноут

Мимо учёта пиров тут прошло другое: этот qr — приватный ключ, и он остался лежать в трёх галереях, как минимум одна из которых обычно синкается в облако. Если старый peer ещё в конфиге сервера, то «четвёртое устройство» — любой, у кого осталась фотка.

Ключ не просто перестают использовать, его отзывают: убрать старый peer, выдать новый. Удаления фото из галереи мало — оно уже побывало там, где ты не контролируешь.

n1kita писал:
Ключ не просто перестают использовать, его отзывают

Плюсую, и добавлю, откуда вообще взялась эта фотка. В приложении wireguard на телефоне есть «создать из qr-кода» — камера смотрит прямо на экран, ключ в галерею не попадает вообще. То есть снимок был лишним шагом с самого начала. Отзыв старого пира чинит прошлое, а вот если канал выдачи не поменять, через полгода новые ключи опять окажутся в том же облаке.

Второе — про учёт. Леха спросил, кто как нумерует пиров, а я отвечу как всегда скучно: так, чтобы через полгода было видно, какую строку можно удалять. У меня пиры называются «zhena-tel-2026-04», «planshet-kukhnya-2026-04», и рядом с конфигом лежит текстовый файлик на три строчки: кому выдан, когда, старый отозван или нет. Потому что обслуживать эту схему будет не энтузиаст, который придумал её весной, а ты же, но в одиннадцать вечера, когда жене завтра в командировку.

Три ключа вместо одного — пара лишних минут при выдаче. Отзыв и перевыдача после утечки — вечер. Арифметика простая :)

pavel_63 писал:
так, чтобы через полгода было видно, какую строку можно удалять

Узнал свою работу. У тебя пиры и текстовый файлик рядом с конфигом, у меня пользователи и регистр сведений в информационной базе — кому выдан доступ, когда, отозван ли. Разница только в том, что ты свой регистр из блокнота собрал, а у нас под него отдельный объект метаданных предусмотрен (это не мешает половине клиентов вести его всё равно в экселе).

А история топикстартера у меня вызвала дежавю. Терминальный сервер, тонкий клиент, три бухгалтера на полставки и один пользователь user1 — «пусть заходят по очереди, они же не весь день сидят». Заходили не по очереди: одна открыла базу, вторая подключилась — первую выкинуло из сеанса, документ остался недопроведённым. Потом третья. Ровно ваш handshake, который прыгает между двумя endpoint: сеанс один, претендентов трое, побеждает тот, кто позже нажал «подключиться».

И журнал регистрации после этого читать невозможно: документ изменил user1, и всё. Кто из троих — устанавливай по косвенным признакам, как следователь. Развели их по отдельным учёткам, а я к этому завёл тот самый регистр: фамилия, дата выдачи, дата отзыва. Потому что рано или поздно приходит звонок: «та, что в декрет ушла, доступ ещё действует?» — и хорошо, если видно, какую строку трогать.

А фразу «ключ — это устройство, а не человек» в 1С знали задолго до wireguard. Программная лицензия привязывается к параметрам компьютера: поменял диск или сетевую карту — активируй заново, ты для неё уже другое устройство. Так что один ключ на три машины — это не ленивый способ, это заранее записанный вечер разборок, просто дата его пока неизвестна.

Про одиннадцать вечера перед командировкой — точно. Схему обслуживает не тот, кто придумал её весной, а ты сам в пятницу, когда у клиента понедельник и зарплата. Всё это и пишется не для себя нынешнего, а для себя будущего, уставшего.

misha_1c писал:
документ изменил user1, и всё. Кто из троих — устанавливай по косвенным признакам, как следователь

У нас такой следователь однажды не нашёл никого. На регистратуре две девушки работали под одной учёткой — «мы же по сменам, зачем две». Понадобилось выяснить, кто изменил номер телефона в карте пациента. Журнал честно показал: registrator, вечер четверга. В вечернюю смену четверга работают обе. Дальше — опрос по памяти, кто вообще открывал эту карту. Хорошо ещё, что вопрос был про телефон, а не про то, кто смотрел саму историю болезни: там «не знаем, у нас общая учётка» звучит уже совсем неудобно.

С тех пор у всех личные учётки, даже у тех, кто выходит два раза в неделю на полставки. И табличка, как ваш регистр: фамилия, когда выдан доступ, когда отозван. Последнее поле самое важное — однажды нашлась живая учётка сотрудницы, уволившейся полгода назад. Ей никто не пользовался, но само её существование — открытая дверь, о которой все забыли.

Забавное зеркало к теме треда: у вас ключ — это устройство, у нас учётка — это человек. А вывод один: общее не работает нигде.

Принято. Про отзыв в первом посте не написал, а это половина работы.

Старый peer снял в тот же вечер, когда разводил ключи: wg set wg0 peer <старый_pub> remove, без рестарта интерфейса, остальные три строки даже не дёрнулись. После этого ключ — просто картинка, handshake он не поднимет уже нигде.

Фото из галерей потёр тоже, но порядок тут важный: сначала отзыв на сервере, потом уборка. Удалённый снимок ключ не обесценивает. Удалённый peer обесценивает любой снимок.

lexa92 писал:
Удалённый peer обесценивает любой снимок.

И это единственный порядок, при котором уборка не даёт ложного спокойствия. Обратная последовательность — любимая: фото стёрли, выдохнули, peer жив.

Отдельно к месту то, что qr — вообще лишний носитель. С телефона на телефон ключ удобнее отдать файлом через тот же мессенджер-петлю, без камеры и галереи вообще.

n1kita писал:
Обратная последовательность — любимая: фото стёрли, выдохнули, peer жив.

У меня эта последовательность в быту выглядит ещё хуже. Жена фотку с qr не стирала — она у неё в «важных» лежит, рядом с рецептом торта и номером паспорта сфотканным. Я полгода назад развёл всех по ключам, старый peer снял, всё красиво. А на днях планшет среднего обновил клиента, ключ слетел, и она мне спокойно: «так у меня ж фотка есть». Достала, отсканировала, старый peer вернулся из могилы — ну, попытался, сервер его уже не знал, но сама сцена была показательная.

Люди удаляют не ключ, а файл. А «важное» у них — это как раз то, что никогда не стирают. Теперь у меня в домашнем файлике с пирами есть колонка не только «отозван», но и «носитель убит»: qr с экрана, файл, распечатка. Потому что иначе через год кто-то из семьи принесёт тебе зомби на блюдечке :)

Про файл через мессенджер-петлю — да, но у меня в семье это гарантированно «а где оно, я в телеграме тыщу чатов». Файл на той же железке, рядом с конфигом, для домашних оказался надёжнее: найдут по логину, а не по тому, куда в марте что переслали.

misha_1c писал:
сеанс один, претендентов трое, побеждает тот, кто позже нажал «подключиться»

Узнал клинику, куда меня звали пару лет назад. Там было ещё веселее: один пользователь на троих в терминале, а у него в настройках выставлено автоподключение при разрыве. Дальше не сеанс, а качели: одна вышла покурить, вторая открыла базу, первая вернулась, терминал сам переподключился — и вторая уже смотрит в чужой сеанс. Обе уверены, что система глючит, и обе правы по-своему. Разводил их по учёткам и сразу выключил это автоподключение, потому что с общей учёткой оно превращает баг в бытовой прибор.

И да, после такого журнал регистрации — просто украшение. Документ изменил user, сеанс был у user, остальное — косвенные признаки и опрос очевидцев.

Так что зеркало тут ровное: ключ — устройство, учётка — человек, и в обоих местах «давайте по очереди» кончается тем, что по очереди не выходит никогда.

pavel_63 писал:
с общей учёткой оно превращает баг в бытовой прибор

Верное слово — прибор. У меня в образе такой был: терминал в бухгалтерии с автологином, чтобы «не тратить утро на пароль». Утро не тратили, зато каждый обед чей-то документ уезжал в чужой сеанс. Автологин и автоподключение — из одной коробки: экономия на нажатии, счёт приходит потом.

Причём обе стороны при этом честно считают, что всё сломалось само.

lexa92 писал:
Причём обе стороны при этом честно считают, что всё сломалось само.

У меня дома ровно так и звучало, пока не развёл всех по ключам. Один конфиг лежал у жены на планшете и у среднего на телефоне, у обоих автоподключение — удобно же, нажимать ничего не надо. Вечер, жена смотрит сериал через туннель к дому, сын сидит в своей комнате, где вайфай через три стены еле дышит. Телефон у него проваливается на мобильную сеть, клиент молча поднимает соединение — и сериал встаёт. «У нас опять интернет сломался». Сын из комнаты: «я вообще ничего не трогал». И оба честные, оба правы — это они друг друга выкидывали по кругу, а я сидел перед keenetic и гадал, почему handshake скачет между двумя адресами.

Смешное в другом: автоподключение я в итоге не тронул. С отдельными ключами оно стало безобидным — пусть цепляются когда хотят, никому не мешают. Так что счёт у нас пришёл не за экономию на нажатии, а за экономию на ключах. Нажатие экономим до сих пор, и ничего, живы :)

che32 писал:
Теперь у меня в домашнем файлике с пирами есть колонка не только «отозван», но и «носитель убит»

Колонка честная, но невыполнимая: носитель ты не контролируешь, он у жены в «важных». Рабочий вариант проще — отозванный peer не должен проходить молча. Лог на отклонённый handshake с неизвестным ключом, и сцена «у меня ж фотка есть» всплывёт в тот же вечер, а не через полгода.

pavel_63 писал:
Дальше не сеанс, а качели

Качели наказывают дважды: один раз сеансом, второй раз репутацией программы. Торговая фирма, менеджеры под одним терминальным пользователем, у rdp-клиента галочка переподключения при разрыве. Менеджер набивал реализацию строк на двести, не записал — записывать в середине работы никого не приучишь — и в этот момент вторая смена нажала «подключиться». Сеанс уехал вместе с открытым окном. У первой на экране пустой рабочий стол, у второй — чужая реализация, которую она, разумеется, закрыла, чтоб не мешала.

Самое обидное, что документ никуда не делся: он висит в отключённом сеансе на сервере, живой, нетронутый. Но попробуй объясни это человеку, который два часа собирал строки. Для него информационная база документ «съела», и это мнение потом ходило по фирме месяцами — уже не про учётку, а про то, что 1С ненадёжная программа. Развёл по пользователям, выключил переподключение без подтверждения. Жалобы на «пропадающие документы» кончились в ту же неделю, хотя в базе я не поменял ни строчки.