Конфиги в БД может быть и плохо. Лучше бы конфиг с зачатками скриптования и всякими include. Откнофигурировать сложную топологию в VPN это то ещё развлечение, а когда потом там нужно что-то изменить, то и вовсе больно.
Я себе под WireGuard/Amnezia сделал скриптовый язык поверх стандатного конфига, и это оказалось супер-удобно: текстовые ID клиентов и генерация их конфигов, разложенных по попаочкам и с осмысленными именами файлов, группы клиентов с шалобнными настройками, задание IP через инкремент от предыдущего и т.п. Я теперь даже не понимаю, как при сложной топологии это всё можно руками отконфигурировать и поддерживать.
Хорошая идея на перспективу. Для вайргард это оправдано. Я же сразу проектировал qeli с заделом на то, что сервер должен уметь пушить настройки на клиента, это очень удобно. Тем более что можно управлять этим через веб панель, а не кли. Еще полноценное апи добавить нужно, чтоб можно было гибко выбирать удобный способ конфигурирования, кли/веб/апи.
Веб панель это не обязательно хорошо. Это требует проброса портов и запуска всякого разного на сервере. Если это какое-то корпоративное использование или куча пользователей, то править текстовые файлы конфигураций может быть проще. Там и регулярные выражения и автозамены и скрипты всякие можно использовать.
И поэтому же json не так хорошо, как кажется. попробуйте написать json даже на 40+ пользователей, разбитый на разные группы. А потом попробуйте это как-то отрефакторить. Можно, но INI оказывается проще. С YAML всё неоднозначно - чем-то проще, чем-то сложнее.
поидее надо отконфигурировать настроки сами
Ох, сюда бы ещё докинуть каналы через DNS и через ICMP, разбиение пакетов а-ля byedpi и вообще интересно получится
Текущая версия - бета. Все хотелки сразу реализовать не возможно. Будем развиваться помаленьку)
Только не надо пытаться объять не объятное. По своему опыту, ICMP очень не надёжный канал, нормально работает только QUIC over ICMP. DNS ещё хуже.
навайбкодил проброс udp порта через icmp - работает идеально (айпи адрес без ограничений на тспу). проблемы могут быть из-за роутера (мой резал до 10кб\сек на сток прошивке, на openwrt стало нормально) или из-за провайдера (домашнего инета или хостера, лично не видел такое, но предполагаю что возможно)
Когда в мск вдруг врубили белые списки, я бы очень рад был любому каналу, лишь бы узнать адреса серверов которые работают
Сразу лайк за вот это все , помимо vpn
Начало 2000, чердаки, свичи, грозы
А так же чат и игры в “Я создал, подключаетесь!» , а так же сходки в реале 🙂
а что с ВПН?
А он тогда был редко нужен. Разве что поиграть по сети в игру, когда все за разными NATами сидят. На аутентификацию тогда забивали: если кто-то подключился без спроса, то просто изгоняли матюгами.
Если планируешь дальше развивать функционал, то я бы посоветовал следующее предусмотреть: 1. Работа через cloudflare proxy domen, 2. Связь нескольких vps через разные протоколы 3. Геомаршрутизация 4. Полноценная связь между устройствами внутри сети в рамках L3. 5. Продумать варианты запуска на роутерах
Сейчас тоже делаю аналогичный сервис и тоже на rust))
Для роутеров: есть для кинетика, но не тестировался на реальном железе. Надеюсь сообщество подключится и кто то это проверит.
Есть докер
https://github.com/litvinovtd/qeli/tree/main/release/docker
Хорошо бы для Open WRT сделать
будет
Бонус для DPI: несколько TLS-соединений к одному хосту — ровно то, что делает браузер, открывая 6+ параллельных TLS. То есть бондинг не только разгоняет, но и выглядит естественнее одного долгого потока.
Так ведь тспу именно так и блочит: с 7 соединения с отпечатком хрома на подозрительный айпи адрес - блок, возможно вам повезло с оператором или хостингом где этого нет. Тест могу отправить в лс
Очень интересный проект. На сервере можно ведь пробрасывать траффик на второй в цепочке сервер?
Это можно делать обычной маршрутизацией, полноценного управления цепочкой серверов пока не реализовано. Я не пытался конкурировать с Xray, а решал свою задачу связанности серверов. То есть мой продукт скорее про сеть, нежели про обход DPI. В этом фундаментальная разница.
Так ведь и чейн по сути не про обход dpi, а про исключение входной ноды из поля зрения любых методов блокировки, включая банальный блок по ip.
в конфиге можно задать:
[profile:reality-tls] obf.multipath.enabled = false # дефолт; бондинга нет вообще
или, если по какой-то причине enabled=true:
obf.multipath.max_streams = 1 # потолок = 1, сервер режет всё сверх
Таким образом можно либо выключить, либо подобрать безопасное число соединений.
На тест будет интересно посмотреть.
глупый вопрос (пока читается README):
а можно сделать на нем соединение point-to-point между парой линукс-серверов, просто запуская бинарник с конфигом, т.е. без всяких админок-настроек?
Получить на каждом сетевой интерфейс типа tun0 и пропускать в том числе ipv6 нативно?
Point-to-point между двумя бинарниками конечно можно. Веб гуй включается опционально через конфиг, если он не нужен не включайте, настраивайте конфигами без всяких админок. Гуи был добавлен исключительно для понижения порога входа, для не совсем опытных линукс пользователей.
IPv6 нативно внутри тоннеля — пока нет. Есть чем заниматься по мимо этого, до в6 руки не дошли.
Надеюсь что статья даст толчек и сообщество подключится к разработке, тестированию.
ок, уже пробую, пока только собираю бинарники (у вас нет в релизах под aarch64)
способы прокинуть ipv6 over ipv4 есть, это не критично, но бывает удобно.
отпишите по результатам)
Собирается, работает.
Есть зависимость от версии glibc - то есть готовый бинарник из релизов может не работать для разных версий Линукса, например.
а зачем оно работает
из текста (и на гитхабе) не понял - а что, клиента для linux нет?
.deb лежит в релизах - это не Линукс?
Docker?
https://habr.com/ru/articles/1052692/ или самому собрать по примеру?
клиент и сервер линукс в одном бинарнике
ага. ОК коли так, но из статьи это не понятно
Скажите, а per-app routing поддерживается? На телефонах крайне актуально. И что с устойчивостью к локальным пробам приложениями?
Per-app routing пока нет — есть split-tunnel по подсетям/маршрутам (через конфиг). Добавлю в планы.
На Android любой VPN видно прямо на телефоне. Система сама рисует иконку вверху, а приложения могут спросить у системы «идёт ли трафик через VPN?» и увидеть сам интерфейс туннеля. Тут рут нужен. Маскировка в qeli вообще про другое: чтобы тоннель не выделялся для того, кто смотрит трафик в сети, а не для приложений на самом телефоне. Это две разные задачи.
«Видеть наличие ВПН в системе» и «дёрнуть api гугла и получить выходной (а в 99% и входной) ip-адрес ВПН-сервера» это очень разные по последствиям вещи. Я бы у себя на телефоне вообще оставил только приложения, умеющие безопасно хранить логин-пароль от локального сокс прокси.
Согласен, разделение верное. Но на современном Android (с 10-й версии вроде) доступ к /proc/net закрыли, так что вытащить именно IP сервера из чужого приложения уже сильно сложнее.
А по сути ты за прокси-модель: приложение видит только локалхост, а не сервер. qeli же — L3-туннель. Просто разные задачи, я прячу туннель от наблюдателя в сети, ты — сервер от приложений на телефоне.
Локальный SOCKS-режим под твой сценарий вполне можно добавить опцией — подумаю. А per-app routing закроет соседний случай: просто не пускать любопытные приложения в туннель.
доступ к
/proc/netзакрыли, так что вытащить именно IP сервера из чужого приложения уже сильно сложнее.
curl --interface eth0 https://ifconfig.co
Если, конечно, там не цепочка из нод
Пока проект только в начале, прошу - рассмотрите возможность простого добавления индивидуального шифрования. Буквально хуки уровня:
void before_stream_write_user_hook(byte *inbuf, int inbuf_len, byte outbuf, int outbuf_len);
void before_stream_read_user_hook(byte inbuf, int inbuf_len, byte outbuf, int *outbuf_len);
А в хуке можно хоть шифровать поверх, хоть вставлять задержку в n микросекунд, хоть вставлять мусорные данные. Короче, чтобы с самого начала была заложена возможность быстрой смены сигнатур протокола.
Подумаю над этим, но обещать что добавлю в релиз, не буду.
Отличная работа. Я уже вовсю активно поддерживаю свой клиент YPN (с разделением туннеля, автоопределением куда надо лить трафик, а куда - нет и прочими удобствами) с закрытым исходным кодом (надеюсь, что не надо объяснять почему клиент с собственными плюшками по ML DPI не стоит вывешивать в открытый доступ) - и собрал практически все те же шишки на старте, но шёл другим путём - началось всё с того что решил переписать немного для себя Hiddify - ужаснулся количеству багов в sing-box / xray-core и провел сначала большое исследование, планирование и затем уже выпуск и тестирование - на собственной сборке панели YPNBox (с RNW под капотом, разными протоколами и т.п.).
Это длится уже полгода и я постоянно нахожу где что улучшить - тонкостей всегда остается много - особенно если делать под кросс-платформы (у меня тоже всё кроме iOS - Win/Linux/Console/MacOS/iOS - только под сборку готовность)
Я бы рекомендовал всё же подумать об открытости исходного кода для некоторых фишек и подумать в сторону модулизации (чтобы держать некоторые модули закрытыми для лишних ресерчей).
Так держать.
Спасибо! Про закрытость понимаю, это обосновано, спору нет. Но я сознательно держу всё открытым: для VPN закрытый код это сразу минус к доверию, а от обскурити толку немного — противник смотрит не в исходники, а в трафик, бинарник у него и так есть. И реверс никто не отменял. Плюс открытое быстрее обкатывается и шире расходится. Ну и это опенсорс все таки.
А вот совет про модуляризацию — в точку. Границы модулей у меня и так чёткие (транспорты, крипто, шейпинг — отдельно), так что если захочется потом держать какой-то экспериментальный модуль отдельно — архитектура позволит. Но на данном этапе задачи совершенно иные. Довести базовый функционал до стабильного релиза.
почти ничего не понял, т.к. ходил играть в CS в компьютерный клуб, а дома из сетей была только хлорка до общего телефонного аппарата коммуналки. но ваш one-liner поразил в самое ядро - все работает.
ждем развития 🍻