Для понимания сути вопроса - немного истории:
Жила-была CRM, частная, корпоративная - хостилась на удаленном сервере у надежного хостера, сотрудники из разных филиалов заходили в нее и работали свою работу.
Никаких тысяч серверов, никакого кровавого энтерпрайза - всё тихо, мирно, почти по-домашнему.
И работало это долго, пока враги не начали ломать интернет.
У части пользователей пропадал доступ к сайту, работать они не могли - сначала помогал VPN, но потом враги начали бороться и с VPN.
Попробовали разнести точки входа по серверам по локациям, сохранив единую базу - враги начали блокировать межсерверные соединения.
А тут еще у одного знакомого вдруг сервер отключили (другие враги, не местные) - значит, надо забирать базу локально.
У другого знакомого локальный сервер поломался - значит, нужно делать удаленную резервную площадку.
Ну ок, системы разнесли, резервы понастроили - а как к ним обращаться, если напрямую нет соединения? Ну прокинули очередной VPN, повесили на какой-то IP адрес канала - а завтра этот канал не работает и этот адрес теперь недоступен, надо менять. Утро начинается не с кофе, утро начинается с проверки "что сегодня и как заблокировали".
Решение, конечно, нашлось, и я о нем писал: каждому серверу был выделен уникальный IP-адрес, не связаный ни с чем, ни с каналами, ни с провайдерами, все сервисы - на этих адресах, а маршрутизация между ними - средствами OSPF через временные по сути каналы связи. Отвалится один - не страшно, мы пойдем другим путем.
OpenVPN отвалился первым, WireGuard вторым, IPsec за пределами локальной сети так и не заработал, но этим, к счастью, варианты не ограничиваются.
Называть мы их не будем, когда приходится играть в карты с шулерами - лучше держать в рукаве десяток запасных тузов.
И вот, появился Qeli. Плюс в том, что в нем сразу предусмотрены несколько возможных протоколов, он один - как нож со сменными лезвиями.
Решено было добавить его в систему каналов. Во-первых, потестировать, а во-вторых - если не получится, ну, не получится, бывает.
По топологии - это “звезда”: к одному серверу может подключаться сразу несколько клиентов, и обмениваться трафиком. То есть, строго говоря, можно назначить один из узлов сервером - остальные подключатся к нему и будут через него работать.
Очевидный минус - между двумя “лучами” задержка суммируется - до сервера и от сервера.
Кроме того, получаем единую точку отказа: если что-то пойдет не так - связь потеряется у всех.
Но ведь можно каждый узел сделать сервером, и каждый же - клиентом для всех остальных.
Конечно, лютый оверинжиниринг, но и условия у нас, скажем так, далеки от лабораторных.
Основных проблем виделось две: много ручной работы по настройке, и разные версии ОС на серверах, а бинарник qeli привязан к конкретной версии GLIBC, для которой он был собран.
Начнем, конечно, со второй:
если создать docker контейнер с ОС нужной версии - программу можно запустить в контейнере!
docker run -ti --name qeli --privileged --network host -v /opt:/opt debian apt update apt upgrade apt install iproute2 cd /opt ./qeli server -c server.conf & ...
Заранее положив в /opt бинарник и конфиги.
Важный нюанс - нужно установить пакет iproute2, в котором утилита ip - иначе ничего не будет работать.
Серверный конфиг, например, такой:
[auth] require_client_key_proof = true bind_static_to_session = true brute_force.max_attempts = 5 brute_force.window_secs = 60 brute_force.lockout_secs = 300 [logging] level = info file = /var/log/qeli/server.log [web] enabled = false [profile:udp-obfs] enabled = true bind.address = 0.0.0.0 bind.port = MY_PORT bind.transport = udp tun.mtu = 1460 tun.queues = 0 tun.name = qserver # 240 netmask, nets 0_, 16_, 32, 48, 64, 80, 96, 112, 128, 141, 160, 176, 224, 240 tun.netmask = 255.255.255.240 pool.cidr = 192.168.168.32/28 tun.address = 192.168.168.33 pool.exclude = 192.168.168.33 routing.nat.enabled = false routing.forward_private = true routing.client_to_client = true dns.enabled = false obf.mode = obfs obf.obfs_key = MY_KEY obf.padding.enabled = false obf.heartbeat.enabled = true obf.heartbeat.interval_ms = 5000 obf.heartbeat.jitter_ms = 2000 perf.connection.max_clients = 64 perf.connection.handshake_timeout_secs = 10 perf.connection.idle_timeout_secs = 0
Заранее рассчитаны несколько подсетей для нескольких серверов:
Например, подсеть 192.168.168.128/28, адрес сервера будет 192.168.168.129 (128 + 1), адреса клиентов соответственно от 130 до 139, 140 бродкаст и 141 - следующая сеть.
Методика расчета простая: записываем биты последнего октета, из расчета "маска подсети - 24", в данном случае меняем 4 первых бита:
echo $(( 2#01110000 )) = 112 echo $(( 2#10000000 )) = 128 echo $(( 2#10010000 )) = 141
При старте нового сервера формируется новый серверный key, что-то типа такого: 88936461a63b49214745065699c7eac148a4260fcf4695f1dc1f7d710b71371b
Его можно получить командой:
./qeli show-identity
Также, нужно завести юзера:
./qeli add-client username
Можно указать сразу пароль, а можно получить некий случайный JKj6788sdfJJK2333
Юзеры с паролями сохраняются в /etc/qeli/users.conf.
В принципе, каталог /etc/qeli можно тоже копировать между серверами, подключая при запуске контейнера, это уменьшит количество операций по настройке, но почему-то решил делать для разных серверов разные
Теперь настраиваем конфиг клиента для этого сервера:
[qeli] server = SERVER_IP:MY_PORT proto = udp user = username pass = JKj6788sdfJJK2333 key = 88936461a63b49214745065699c7eac148a4260fcf4695f1dc1f7d710b71371b mode = obfs obfs_key = MY_KEY dev = qelialfa mtu = 1460 mtu_probe = false gateway = false route_local = true kill_switch = false allow_ipv6_leak = true dns = off autostart = false #post_up = /etc/qeli/up.sh #post_down = /etc/qeli/down.sh [logging] level = info file = /var/log/qeli/client.log
Сохраняем его в файл типа client-alfa.conf, и идем на следующий сервер.
Устанавливаем, настраиваем подсеть, порты, адреса, юзера и ключи, сохраняем файл client-bravo.conf.
И так далее для всех N серверов. Почти везде - копипаста.
А потом пишем скрипты запуска всего этого зоопарка, типа такого:
cd /opt setsid ./qeli server -c server.conf setsid ./qeli client -c client-alfa.conf setsid ./qeli client -c client-bravo.conf setsid ./qeli client -c client-charly.conf ...
Убираем только запуск сам-на-себя.
И запускаем:
docker start qeli docker exec qeli /opt/startup
Эти команды можно записать, например, в /etc/rc.local или какой другой стартап-скрипт.
Всё, первая часть выполнена: сервера связаны каждый с каждым, появилось по N-1 сетевых интерфейсов с соответствующими именами, пинги ходят туда-сюда.
Теперь нужно весь этот бардак упорядочить.
Имена интерфейсов на каждом узле известны, однотипны - qelialfa, qelibravo, и т.д.
Нужно только обьявить на интерфейсе lo уникальные IP-адреса и настроить связность по OSPF.
OSPF - это система обмена маршрутами к узлам сети между роутерами.
Роутер в данном случае - сам компьютер, узел сети, на котором запущены демоны маршрутизации - OSPF и BFD.
Демону OSPF указывается список интерфейсов и адресов, с которым он работает, и если с той стороны интерфейса слушает другой демон OSPF - они обмениваются сообщениями.
BFD контролирует активность интерфейсов.
Как-то так:
ospfd: - у меня есть узел 123.45.67.89, надо кому?
iface1: - принято, записал, 123.45.67.89 это к тебе, а у меня есть сеть 112.11.11.0/24
ospfd: - принято, эта сеть - к тебе
bfdd: - там похоже iface2 сдох, потыкай его палочкой
ospfd: - и правда, сдох. Через него работало 33.23.22.33, кто-нибудь знает как туда еще попасть? Никто? Вычеркиваем...
Для настройки OSPF можно использовать пакет frr в котором уже есть нужные демоны, и запускается он также в докере:
mkdir /etc/frr docker run -ti -v /etc/frr:/etc/frr --name frr --privileged --network host debian apt update apt upgrade apt install frr exit
Включаем нужных демонов, остальное не трогаем:
vim /etc/frr/daemons ospfd=y ospf6d=y bfdd=y
Запускаем, и делаем первичную настройку:
docker start frr docker exec frr /usr/lib/frr/frrinit.sh start docker exec frr vtysh configute terminal interface lo ip address 192.168.200.1/32 ipv ospf area 0 ipv6 ospf6 area 0 exit router ospf ospf router-id 1.4.0.1 maximum-path 1 exit router ospf6 ospf6 router-id 1.6.0.1 maximum-path 1 exit exit write memory exit
Теперь у нас OSPF подхватит и раздаст адреса на интерфейсе lo, но пока не указано кому.
И вот тут возникла неожиданная проблема:
Для работы OSPF нужно, чтобы линки между узлами пропускали мультикаст-пакеты, 224.0.0.1, причем в обе стороны. А qely версии 0.7.10 не пропускает.
Частично вопрос можно решить, обьявив в OSPF интерфейс как non-broadcast - но всё равно от сервера к клиенту пакеты с IP, отличающимся от подсети сервера, не проходят, а это значит что связи не будет.
Узлы будут знать, куда отправлять пакет - но его не пропустит qeli.
Но тут удачно вспомнилось существование протокола IPv6. Qeli его тоже не пропускает, но зато поверх линков можно создать ipv6-туннели, и делается это довольно просто:
ip tunnel add IF_NAME mode sit local LOCAL_QELI_IP remote REMOTE_QELI_IP ttl 255 ip link set dev IF_NAME up mtu 1440
Сделать это нужно на обоих сторонах линка, поменяв местами local и remote.
Параметр MTU должен быть на 20 байт меньше, чем MTU линка, а его задали как 1460.
У полученного интерфейса автоматически появляются link-local ipv6 адреса, по которым прекрасно работает OSPF, точнее OSPF6, для 6 версии протокола.
И теперь, если на узлах добавить эти интерфейсы в OSPF6 - установится связь.
Только уникальный адрес на интерфейсе lo должен быть из ipv6 - например, fd00:cafe::1, fd00:cafe::2 и т.п.
Соответственно, между ними заработает сеть ipv6, в которой каждый узел будет иметь свой заданный независимый адрес, что и требовалось.
Справедливости ради - можно создать туннели mode ipip, точно такие же - но для ipv4, и они тоже работают хорошо.
Но у них не будет link-local адресов, их нужно назначать вручную, и ничего не перепутать - и вот это довольно сложно автоматизировать для N серверов.
Что ж, это лишний повод попытаться перейти на ipv6, но пока просто автоматизируем это всё, потому что создавать ручками кучу линков - ну это такое себе.
За основу берем два факта:
Во-первых, у qeli есть функция получения списка активных коннектов.
./qeli list-client
получаем список текущих подключений с выданнными адресами, а свой адрес мы знаем, он 1 в той же подсети. Это позволяет создать половинки туннелей с серверной стороны.
Во-вторых, нам известен список возможных клиентских интерфейсов - мы их задавали в конфигах.
Можно получить локальный выданный адрес, а адрес сервера мы опять знаем, он 1 в той же подсети. Это позволит создать клиентские половинки туннелей.
Получаем созданные интерфейсы, и добавляем их в OSPF через командный инерфейс vtysh.
Остается совместить одно с другим
#!/bin/bash PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin; export PATH user='username' mtu=1440 ifaces="qelialfa qelibravo qelicharly qelidelta ..." docker exec qeli /ext/qeli list-clients | while IFS= read -r line ; do ip=$( echo $line | grep "$user" | awk '{ print $2}' ) if [ "x$ip" != "x" ]; then last_num=$( echo $ip | sed -E 's/^.*\.([0-9]+)/\1/') net_num=$(( ($last_num & 2#11110000) + 1 )) local_ip="192.168.168.$net_num" if_ip="qsit${last_num}" ip link show dev $if_ip if [ $? -ne 0 ]; then echo "create" ip tunnel add $if_ip mode sit local $local_ip remote $ip ttl 255 fi ip link set dev $if_ip up mtu $mtu docker exec frr vtysh \ -c "configure terminal" \ -c "interface $if_ip" \ -c "ipv6 ospf6 area 1" \ -c "ipv6 ospf6 priority 10" \ -c "ipv6 ospf6 bfd" \ -c "exit" \ -c "exit" fi done # clients for i in $ifaces ; do ip link set dev $i up if [ $? -eq 0 ] ; then ip=$( ip addr show dev $i | grep 'inet ' | awk '{ print $2 }' | sed 's/\/.*//' ) if [ "x$ip" != "x" ]; then last_num=$( echo $ip | sed -E 's/^.*\.([0-9]+)/\1/') net_num=$(( ($last_num & 2#11110000) + 1 )) server_ip="192.168.168.$net_num" # add to frr if_ip="qsit${last_num}" ip link show dev $if_ip if [ $? -ne 0 ]; then echo "create" ip tunnel add $if_ip mode sit remote $server_ip local $ip ttl 255 fi ip link set dev $if_ip up mtu $mtu docker exec frr vtysh \ -c "configure terminal" \ -c "interface $if_ip" \ -c "ipv6 ospf6 area 1" \ -c "ipv6 ospf6 priority 10" \ -c "ipv6 ospf6 bfd" \ -c "exit" \ -c "exit" fi fi done
И просто запускаем скрипт после установки соединений. Можно несколько раз, можно хоть каждую минуту - лишнее создаваться не будет.
Только не забыть добавить на lo интерфейс ipv6 адреса, типа fd00:cafe::1/128
Вторая часть, построение сети - готова: с любого узла проходят пинги на соседний fd00:cafe::x
Причем они проходят по шифрованному каналу, по наименьшему пути, и вообще оно работает "как-то само", особенно если начать отрубать то одно, то другое соединения - просто сеть перестраивается на лету.
Третья задача - дать доступ к этой сети нескольким машинам в локалке, сидящей где-то сбоку за одним из узлов.
Можно, конечно, в лоб: еще одно qeli-соединение, еще один туннель, который включится в общую сеть.
А можно по другому:
Во-первых, можно поднять в локальной сети свою ipv6-сеть, просто добавив адреса на шлюзе
ip addr add fd00:bebe::1/64 dev iface
и на целевой машине
ip addr add fd00:bebe::2/64 dev iface ip -6 route add default via fd00:bebe::1
а потом добавить на шлюзе правила в ospf:
docker exec frr vtysh configure terminal router ospf6 redistribute static exit ipv6 route fd00:bebe::/64 iface exit exit
Во-вторых, можно локально ipv6 не поднимать, добавить адрес прямо из серверной сети на целевую машину и настроить статический роутинг через link-local адрес интерфейса на шлюзе:
ip -6 addr show dev iface ... inet6 fe80::32a6:12ff:fe0e:951a/64 scope link ...
на целевой машине:
ip addr add fd00:cafe::beer/128 dev iface ip -6 add default via fe80::32a6:12ff:fe0e:951a dev iface
и потом добавить правила:
docker exec frr vtysh configure terminal router ospf6 redistribute static exit ipv6 route fd00:cafe::beer/128 iface exit exit
И так и этак будет работать: с машины в сеть, и из сети - на эту машину.
Зачем? Затем, что теперь эта машина может взаимодействовать с узлами нашей сети так, как будто все они находятся в одной локалке.
Например, на локальной машине может находиться бекенд вебсервера, "морда" которого находится на узле Alfa.
Для этого на Alfa устанавливаем, например, nginx и настраиваем upstream:
vim /etc/nginx/sites-available/alfa.com upstream beer { server [fd00:cafe::beer]:3000; } server { listen 80; server_name alfa.com; location / { return 301 https://$host$request_uri; } } server { listen 443 ssl; http2 on; server_name alfa.com; keepalive_timeout 70; ssl_certificate /root/.acme.sh/alfa.com_ecc/fullchain.cer; ssl_certificate_key /root/.acme.sh/alfa.com_ecc/alfa.com.key; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers HIGH:!aNULL:!MD5; location / { proxy_pass http://beer; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection ""; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-HTTPS 0; } }
Теперь при заходе на сервер alfa.com реальное соединение идет с бекендом на сервере Beer, который стоит где-то у вас совсем в другом месте, вовсе не на Alfa.
При этом сервер bravo.com тоже может быть реально на Beer. А может быть не на Beer, а на Beef, который стоит в совсем другой локации - но всё это для вас "локальная сеть".
Мало ли для чего может пригодиться локальная сеть большого радиуса действия...
А самое интересное тут, что ipv6 оказывается действительно удобен. И это даже в режиме "локальных" fd00-адресов.
