Рассматривал ранее вариант построения виртуальной сети с помощью zerotier. На днях попробовал еще одно решение на эту тему - Nebula - инструмент для построения защищенных оверлейных сетей. Узлы сети устанавливают прямое vpn соединение между собой (p2p). Отличительная особенность системы - ее простота - все поставляется в комплекте, запускается посредством бинарника с раскиданными по хостам конфигурационными файлам и сертификатами, которыми подтверждается принадлежность к сети.
Ключ и сертификат сети
- Воспользуемся nebula-cert из архива для генерации ключа и сертификата для последующего выпуска сертификатов хостов сети. Срок действия 1 год по умолчанию.
./nebula-cert ca -name "DeSoft.ru" ls ca.crt ca.key nebula nebula-cert nebula-linux-amd64.tar.gz
Сертификаты хостов
- Создаем и подписываем сертификаты для хостов системы
# контроллер сети и его внутрисетевой адрес
./nebula-cert sign -name "lighthouse-1" -ip "10.10.101.1/24"
# хост №1
./nebula-cert sign -name "vps-1" -ip "10.10.101.11/24" -groups "vps"
# хост №2
./nebula-cert sign -name "vps-2" -ip "10.10.101.12/24" -groups "vps"
Конфигурационные файлы хостов
- Берем конфигурационный файл из репозитория
curl -o config.yml https://raw.githubusercontent.com/slackhq/nebula/master/examples/config.yml
- Готовим конфиг для контроллера сети, он же lighthouse
cp config.yml config-lighthouse.yaml
Раздел static_host_map оставляем пустым, в разделе lighthouse выставляем параметр am_lighthouse в true, а hosts также оставляем пустым.
static_host_map:
lighthouse:
am_lighthouse: true
hosts:
- Готовим конфиг для хостов
cp config.yml config.yaml
В разделе static_host_map должен быть прописан внутренний и внешний адреса lighthouse сервера. По умолчанию используется udp порт 4242, не забываем оставить его открытым.
static_host_map:
"10.10.101.1": ["<vps ip>:4242"]
В разделе lighthouse в hosts прописываем внутренний адрес сервера lighthouse.
lighthouse:
am_lighthouse: false
interval: 60
hosts:
- "10.10.101.1"
Отдельно упомяну про раздел firewall, параметры которого позволяют разграничить трафик между хостами в сети. По умолчанию весь исходящий трафик открыт, а вот входящий заблокирован, кроме icmp пакетов. Также в конфиге представлен пример разграничения по группам, что добавляет гибкости в настройках взаимодействия между устройствами в сети.
firewall:
...
outbound:
# Allow all outbound traffic from this node
- port: any
proto: any
host: any
inbound:
# Allow icmp between any nebula hosts
- port: any
proto: icmp
host: any
# Allow tcp/443 from any host with BOTH laptop and home group
- port: 443
proto: tcp
groups:
- laptop
- home
Запускаем lighthouse
- Скачиваем бинарник под систему, на которой будет располагаться lighthouse.
- Переносим на сервер подготовленные ранее ca.cert, lighthouse-1.crt, lighthouse-1.key, config-lighthouse.yaml.
- Поскольку в конфигурационных файлах указаны пути до рабочего каталога и файлов в нем (раздел pki), перенесем всю рабочую конфигурацию в этот каталог, соблюдая типовое наименование.
mkdir /etc/nebula
mv ca.crt /etc/nebula/ca.crt
mv lighthouse-1.crt /etc/nebula/host.crt
mv lighthouse-1.key /etc/nebula/host.key
mv config-lighthouse.yaml /etc/nebula/config.yaml
- Стартуем
./nebula -config /etc/nebula/config.yaml
Запускаем host
- Переносим на сервер подготовленные ранее ca.cert, vps-1.crt, vps-1.key, config.yaml.
- Можно также создать каталог и перенести туда рабочую конфигурацию или внести корректировки в pki раздел config.yaml, указав собственные пути. Для единообразия оставим предложенную схему.
mkdir /etc/nebula
mv ca.crt /etc/nebula/ca.crt
mv vps-1.crt /etc/nebula/host.crt
mv vps-1.key /etc/nebula/host.key
mv config.yaml /etc/nebula/config.yaml
- Стартуем
./nebula -config /etc/nebula/config.yaml
По аналогии настраиваем и запускаем nebula на втором хосте (vps-2).
Проверка
Осталось проверить поднятую сеть и, согласно правилам firewall, только пропинговать устройства как с хостов так и с контроллера.
ping 10.10.101.1
PING 10.10.101.1 (10.10.101.1) 56(84) bytes of data.
64 bytes from 10.10.101.1: icmp_seq=1 ttl=64 time=36.7 ms
64 bytes from 10.10.101.1: icmp_seq=2 ttl=64 time=36.5 ms
64 bytes from 10.10.101.1: icmp_seq=3 ttl=64 time=36.6 ms
64 bytes from 10.10.101.1: icmp_seq=4 ttl=64 time=36.6 ms
ping 10.10.101.11
PING 10.10.101.11 (10.10.101.11) 56(84) bytes of data.
64 bytes from 10.10.101.11: icmp_seq=1 ttl=64 time=1375 ms
64 bytes from 10.10.101.11: icmp_seq=2 ttl=64 time=354 ms
64 bytes from 10.10.101.11: icmp_seq=3 ttl=64 time=36.8 ms
64 bytes from 10.10.101.11: icmp_seq=4 ttl=64 time=37.4 ms
ping 10.10.101.12
PING 10.10.101.12 (10.10.101.12) 56(84) bytes of data.
64 bytes from 10.10.101.12: icmp_seq=1 ttl=64 time=36.9 ms
64 bytes from 10.10.101.12: icmp_seq=2 ttl=64 time=37.4 ms
64 bytes from 10.10.101.12: icmp_seq=3 ttl=64 time=37.1 ms
64 bytes from 10.10.101.12: icmp_seq=4 ttl=64 time=36.8 ms