История изменений

под динамикой я имел ввиду некий процесс, по которому вновь присоединённый к сети пир (настроенный на присоединение только к «центральному серверу») сам узнает от сервера о существовании других клиентов. то есть, в идеале заменить циску сервачками под OpenBSD :) с ospfd и wg, чтобы свежеподнятый сервачок цеплялся к центральному «хабу», подтягивал инфу от него об имеющихся префиксах (подсетях) и next-hop’ах к этим префиксам (внешний IP клиента + IP wg- интерфейса).

Я сразу скажу, что я не настоящий сварщик, но DHCPv6 умеет next-hop в качестве опции. Если отдать это значение достаточно, чтобы все заработало, то как бы вот и оно.

Основная проблема, которую я вижу, это то, что WG требует заранее расшарить между клиентами пары публичных ключей. В принципе, если на центральном сервере хранить yaml файлик вида:

nodes:
   node1: { address: ..., public_key: ... },
   node2: { address: ..., public_key: ... }

И при коннекте к «центральному серверу» условная node3 подхватывает эти значения, поднимает интерфейсы, добавляет себя в этот лист и другие ноды каким-то образом это узнают (HTTP GET с опцией «не отдавай если не протухло?») и добавляют новый хост… То вот и оно.

Хотя, в идеале конечно пуш семантику. node3 цепляется, регистрируется, остальные получают push с апдейтами её ключей.

под динамикой я имел ввиду некий процесс, по которому вновь присоединённый к сети пир (настроенный на присоединение только к «центральному серверу») сам узнает от сервера о существовании других клиентов. то есть, в идеале заменить циску сервачками под OpenBSD :) с ospfd и wg, чтобы свежеподнятый сервачок цеплялся к центральному «хабу», подтягивал инфу от него об имеющихся префиксах (подсетях) и next-hop’ах к этим префиксам (внешний IP клиента + IP wg- интерфейса).

Я сразу скажу, что я не настоящий сварщик, но DHCPv6 умеет next-hop в качестве опции. Если отдать это значение достаточно, чтобы все заработало, то как бы вот и оно.

Основная проблема, которую я вижу, это то, что WG требует заранее расшарить между клиентами пары публичных ключей. В принципе, если на центральном сервере хранить yaml файлик вида:

nodes:
   node1: { address: ..., public_key: ... },
   node2: { address: ..., public_key: ... }

И при коннекте к «центральному серверу» условная node3 подхватывает эти значения, поднимает интерфейсы, добавляет себя в этот лист и другие ноды каким-то образом это узнают (HTTP GET с опцией «не отдавай если не протухло?») и добавляют новый хост… То вот и оно.