Сделать генерацию конфигов Wireguard для участников

[jekhor]

Есть идея перевести VPN для доступа в сеть ХС с OpenVPN на WireGuard.
Для этого нужно решение по генерации конфигов, поскольку WG рассчитано на уникальность ключей и IP-адресов для каждого клиента. У каждого участника может быть несколько устройств, с которых он захочет иметь доступ в ХС, в том числе одновременно.

Возможный вариант:
В профиле пользователя есть список имеющихся конфигураций, пустой по дефолту. Рядом ссылка на инструкцию по настройке клиента под Windows/Linux/Mac.
Кнопка "Создать конфигурацию WG", по нажатию на неё:

1. Генерируется пара закрытый-открытый ключ клиента.
2. Выделяется IP адрес из пула и помечается в базе как выделенный (либо храним базу адресов, либо просто инкрементируемое поле с последним использованным адресом).
3. Эти данные сохраняются в базу, пользователю показывается, что в список конфигураций добавилась новая.
4. Закрытый ключ клиента и настройки IP-адреса сохраняются в базе для дальнейшего использования на VPN-сервере.
5. VPN-сервер уведомляется об изменении конфигурации и экспортирует конфиг себе (либо делает это по крону раз в 10 минут).
6. По нажатию на ссылку "скачать конфигурацию" генерируется клиентский конфиг, содержащий: открытый ключ сервера, закрытый ключ клиента, адрес сервера, настройки IP маршрутизации, keepalive.
7. Пользователь скачивает конфиг, устанавливает его и запускает VPN.

VPN-сервер:
По крону обновляет конфигурацию клиентов с сайта. При этом сайт отдаёт конфиги только активных юзеров. Сервер синхронизирует локальную базу с базой сайта, добавляя-удаляя-редактируя записи у себя.

Открытые вопросы для обсуждения:

• разрешать ли default route (доступ в интернет через ХС) или только доступ в сеть ХС? Если да, то опционально (галочка в свойствах конфигурации) или по дефолту?

• можно ли с WG сделать, чтобы работал mDNS/Bonjour (доступ по именам устройств вида freddy.local)?
  Ответ: Можно, но нужно ставить mdns рефлектор на VPN сервере. В теории возможна маршрутизация multicast пакетов, но на практике сложна в настройке (нужна корректировка TTL и всё такое).

• можно ли WG интерфейс сервера объединить в мост с ETH-интерфейсом, смотрящим в сеть ХС, и раздать клиентам IP из той же подсети, что и внутри ХС? И надо ли? Тогда не надо настраивать ничего на маршрутизаторе, зато усложняет настройку VPN-сервера. Сейчас OpenVPN сервер как раз работает в режиме ethernet-моста, клиент получает IP-адрес от основного DHCP-сервера ХС.
  Ответ: Можно использовать методику proxy arp, но на практике не нужно, проще раздать маршруты через DHCP и редиректить пакеты, всё равно пришедшие на default gateway, но адресованные узлам-клиентам WG, на собственно маршрутизаторе.

[abitrolly]

WG рассчитано на уникальность ключей и IP-адресов для каждого клиента

Ты хочешь сказать, что никакого DHCP и каждый входящий клиент прибит гвоздями к внутренней сети?

[abitrolly]

А нельзя при добавлении SSH ключа VPN ключ генерить и ложить туда же в репу?

https://www.bjornjohansen.com/encrypt-file-using-ssh-key

[abitrolly]

можно ли с WG сделать, чтобы работал mDNS/Bonjour (доступ по именам устройств вида freddy.local)?

А почему нельзя? Я думал будет обратная проблема, что при подключении VPN устройства в моей локалке станут недоступны, как и доступ к инету. Я не уверен как маршрутизация работает в этом случае.

[abitrolly]

можно ли WG интерфейс сервера объединить в мост с ETH-интерфейсом, смотрящим в сеть ХС, и раздать клиентам IP из той же подсети, что и внутри ХС?

А разве VPN не предполагает раздачу IP из подсети, в которую клиент коннектится?

[abitrolly]

В МалиноХС проблема с WG была в том, что роутер надо было перепрошивать, все боялись это делать (и пугали меня). :D

[jekhor]

Ты хочешь сказать, что никакого DHCP и каждый входящий клиент прибит гвоздями к внутренней сети?

Именно так, это WG, детка.

[jekhor]

А нельзя при добавлении SSH ключа VPN ключ генерить и ложить туда же в репу?

А если у человека 2-3 устройства? Два компа и телефон?

[jekhor]

В МалиноХС проблема с WG была в том, что роутер надо было перепрошивать, все боялись это делать (и пугали меня). :D

Я в ЗХС сто раз так делал :)

[jekhor]

А разве VPN не предполагает раздачу IP из подсети, в которую клиент коннектится?

Предполагает, но подсеть по дефолту локальная для VPN-сервера, как ты там дальше разруливаешь — другой вопрос.

[jekhor]

А почему нельзя? Я думал будет обратная проблема, что при подключении VPN устройства в моей локалке станут недоступны, как и доступ к инету. Я не уверен как маршрутизация работает в этом случае.

Потому что мультикаст по дефолту проходить не будет. Но это решаемо, судя по гуглу.

[jekhor]

Бридж wg<->eth можно организовать с использованием parprouted, который будет пересылать ARP запросы-ответы, править таблицы роутинга (добавляя роуты на хост, для которого появилась запись в ARP-таблице): https://wiki.debian.org/BridgeNetworkConnectionsProxyArp . Обычный бридж не поднимешь, потому что WG работает на уровне IP-протокола, а не на MAC-уровне.

Но учитывая то, что адреса в WG всё равно должны быть выданы статически, это практически не даёт преимущества по сравнению с маршрутизацией отдельной подсети, зато усложняет конфигурацию и отладку VPN-сервера.

[abitrolly]

А нельзя при добавлении SSH ключа VPN ключ генерить и ложить туда же в репу?

А если у человека 2-3 устройства? Два компа и телефон?

В блокчейне.. :D есть возможность несколько ключей доступа генерить из одного мастер ключа. Не уверен, правда, что они одним приватником открываются. Надо спрашать.

Но да, добавлять SSH доступ на GitHub для какого-нибудь RPi я бы не стал. Для таких случаев нужен пул айпишников. По линуксовому - префикс с числом ключей к имени ключа добавлять. :D

[jekhor]

Генерация конфигов сделана, остался экспорт для сервера.