Nebula
Построение защищенных виртуальных сетей с помощью Nebula
Решим задачу по объединению распределенных устройств в отдельную изолированную сеть. Nebula - инструмент для построения защищенных оверлейных сетей. Узлы сети устанавливают прямое vpn
соединение между собой (p2p
). Отличительная особенность системы - ее простота - все поставляется в комплекте, запускается посредством бинарника с раскиданными по хостам конфигурационными файлам и сертификатами, которыми подтверждается принадлежность к сети.
Ключ и сертификат сети
- Забираем актуальную версию
Nebula
из релизов под любую систему. - Воспользуемся
nebula-cert
из архива для генерации ключа и сертификата для последующего выпуска сертификатов хостов сети. Срок действия 1 год по умолчанию.
./nebula-cert ca -name "site.ru" ls ca.crt ca.key nebula nebula-cert nebula-linux-amd64.tar.gz
Сертификаты хостов
- Создаем и подписываем сертификаты для хостов системы
# контроллер сети и его внутрисетевой адрес ./nebula-cert sign -name "controller-1" -ip "10.10.0.1/24" # хост №1 ./nebula-cert sign -name "vps-1" -ip "10.10.1.1/24" -groups "vps" # хост №2 ./nebula-cert sign -name "vps-2" -ip "10.10.2.1/24" -groups "vps"
Конфигурационные файлы хостов
- Берем конфигурационный файл из репозитория
curl -o config.yml https://raw.githubusercontent.com/slackhq/nebula/master/examples/config.yml
- Готовим конфиг для контроллера сети, он же
controller
cp config.yml config-controller.yaml
Раздел static_host_map
оставляем пустым, в разделе controller
выставляем параметр am_controller
в true
, а hosts
также оставляем пустым.
static_host_map: controller: am_controller: true hosts:
- Готовим конфиг для хостов
cp config.yml config.yaml
В разделе static_host_map
должен быть прописан внутренний и внешний адреса controller
сервера. По умолчанию используется udp
порт 4242
, не забываем оставить его открытым.
static_host_map: "10.10.0.1": ["<vps ip>:4242"]
В разделе controller
в hosts
прописываем внутренний адрес сервера controller
.
controller: am_controller: false interval: 60 hosts: - "10.10.0.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
Запускаем основной сервер controller
- Скачиваем бинарник под систему, на которой будет располагаться
controller
. - Переносим на сервер подготовленные ранее
ca.cert
,controller-1.crt
,controller-1.key
,config-controller.yaml
. - Поскольку в конфигурационных файлах указаны пути до рабочего каталога и файлов в нем (раздел
pki
), перенесем всю рабочую конфигурацию в этот каталог, соблюдая типовое наименование.
mkdir /etc/nebula mv ca.crt /etc/nebula/ca.crt mv controller-1.crt /etc/nebula/host.crt mv controller-1.key /etc/nebula/host.key mv config-controller.yaml /etc/nebula/config.yaml
- Стартуем
./nebula -config /etc/nebula/config.yaml
Запускаем присоединяемые сервера host
- Скачиваем, настраиваем и запускаем
nebula
на первом хосте (vps-1
). - Переносим на сервер подготовленные ранее
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.0.1 PING 10.10.0.1 (10.10.0.1) 56(84) bytes of data. 64 bytes from 10.10.0.1: icmp_seq=1 ttl=64 time=36.7 ms 64 bytes from 10.10.0.1: icmp_seq=2 ttl=64 time=36.5 ms 64 bytes from 10.10.0.1: icmp_seq=3 ttl=64 time=36.6 ms 64 bytes from 10.10.0.1: icmp_seq=4 ttl=64 time=36.6 ms
ping 10.10.1.1 PING 10.10.1.1 (10.10.1.1) 56(84) bytes of data. 64 bytes from 10.10.1.1: icmp_seq=1 ttl=64 time=36.6 ms 64 bytes from 10.10.1.1: icmp_seq=2 ttl=64 time=36.4 ms 64 bytes from 10.10.1.1: icmp_seq=3 ttl=64 time=36.8 ms 64 bytes from 10.10.1.1: icmp_seq=4 ttl=64 time=37.4 ms
ping 10.10.2.1 PING 10.10.2.1 (10.10.2.1) 56(84) bytes of data. 64 bytes from 10.10.2.1: icmp_seq=1 ttl=64 time=36.9 ms 64 bytes from 10.10.2.1: icmp_seq=2 ttl=64 time=37.4 ms 64 bytes from 10.10.2.1: icmp_seq=3 ttl=64 time=37.1 ms 64 bytes from 10.10.2.1: icmp_seq=4 ttl=64 time=36.8 ms