Автоматическая, защищенная, распределенная, с транзистивными связями (т.е. пересылкой сообщений, когда нет прямого доступа между абонентами), без единой точки отказа, равноправная, проверенная временем, с низким потреблением ресурсов, full-mesh VPN сеть c возможностью "пробивки" NAT — это возможно?
Правильные ответы:
- да, с болью, если вы используете tinc.
- да, легко, если вы используете tinc + tinc-boot
Ссылка на пропуск вводной части
Описание tinc
К сожалению, информации о Tinc VPN на Хабре публиковалось немного, но пару релевантных статей все же можно найти:
- Наш рецепт отказоустойчивого VPN-сервера на базе tinc, OpenVPN, Linux от компании Флант
- Список Full-Mesh VPN решений от уважаемого ValdikSS
Из англоязычных статей можно выделить:
- How To Install Tinc and Set Up a Basic VPN on Ubuntu 14.04 от компании Digital Ocean
- How to Set up tinc, a Peer-to-Peer VPN от компании Linode
Первоисточником лучше считать оригинальную документацию Tinc man
Итак (вольная перепечатка с официального сайта), Tinc VPN это сервис (демон tincd) обеспечивающий функционирование приватной сети за счет тунелирования и шифрования трафика между узлами. Исходный код открыт и доступен под лицензией GPL2. Подобно классическим (OpenVPN) решением, созданная виртуальная сеть доступна на уровне IP (OSI 3), а значит, в общем случае, внесение изменений в приложения не потребуется.
Ключевые особенности:
- шифрование, аутентификация и сжатие трафика;
- полностью автоматическое full-mesh решение, включающее в себя построение связей к узлам сети в режиме "все-со-всеми" или, если это неприменимо, пересылку сообщений между промежуточными хостами;
- "пробивка" NAT;
- возможность соединять изолированные сети на уровне ethernet (виртуальный switch);
- поддержка множества ОС: Linux, FreeBSD, OS X, Solaris, Windows и т.д.
Существует две ветки развития tinc: 1.0.x (почти во всех репозиториях) и 1.1 (вечная бета). В статье везде используется версия 1.0.x.
Tinc 1.1x предоставляет несколько новых ключевых особенностей: perfect forward security, упрощенное подключение клиентов (фактически заменяющий собойtinc-boot) и в целом более продуманный дизайн.
Однако, на текущий момент, на официальном сайте указана и выделена стабильная версия — 1.0.x, так что при использовании всех преимуществ ветки 1.1 стоит оценить все преимущества и недостатки использования не финальной версии.
С моей точки зрения, одной из сильнейших возможностей является пересылка сообщений при невозможности прямого соединения. При этом, таблицы маршрутизации строятся полностью автоматически. Даже узлы без публичного адреса могут пропускать трафик через себя.
Рассмотрим ситуацию тремя серверами (Китай, РФ, Сингапур) и тремя клиентами (РФ, Китай и Филиппины):
- сервера имеют публичный адрес, клиенты за NAT'ом;
- РКН во время очередного бана вероятных прокси Телеграмма заблокировал всех хостеров кроме "дружественного" Китая;
- сетевая граница Китай <-> РФ является нестабильной и может падать (из-за РКН и/или из-за Китайского цензора);
- соединения до Сингапура условно стабильные (личный опыт);
- Манила (Филиппины) ни для кого угрозой не является, а потому разрешена для всех (по причине удаленности от всех и всего).
На примере обмена трафиком между Шанхаем и Москвой рассмотрим сценарии работы Tinc (примерно):
- Штатная ситуация: Москва <-> russia-srv <-> china-srv <-> Шанхай
- РКН закрыл соединение до Китая: Москва <-> russia-srv <-> Манила <-> Сингапур <-> Шанхай
- (после 2) при отказе сервера в Сингапуре, трафик перекидывается на сервер в Китае и наоборот.
При возможности, Tinc пытается организовать прямое соединение между двумя узлами за NAT за счет "пробивки".
Краткая вводная в конфигурирование tinc
Tinc позиционируется как легкий в настройки сервис. Однако, что-то пошло не так — для создания нового узла минимально необходимо:
- описать настройку узла (тип, имя) (
tinc.conf); - описать файл конфигурации (обслуживаемые подсети, публичные адреса) (
hosts/); - создать ключ;
- создать скрипт, задающий адрес узла и сопутствующие параметры (
tinc-up); - желательно создать скрипт, очищающий созданные параметры после остановки (
tinc-down).
В дополнении к этому, при подключении к существующей сети, необходимо получить существующие ключи узлов и предоставить свой.
Т.е: для второго узла
Для третьего
При использовании двухсторонней синхронизации (например unison), количество дополнительных операций увеличивается до на N штук, где N — число публичных узлов.
Надо отдать должное разработчикам Tinc — для включения в сеть достаточно обменяться ключами
только с одним из узлов (bootnode). После запуска сервиса и подключения к участнику, tinc получит топологию
сети и сможет работать со всеми абонентами.
Однако, если загрузочный хост стал недоступен, а tinc перезапустился, то нет никакой возможности
подключится к виртуальной сети.
Более того, огромные возможности tinc в совокупности с академической документацией оного (хорошо описано, но мало примеров), дают обширное поле для совершения ошибок.
Причины создания tinc-boot
Если обобщить описанные выше проблемы, и сформулировать их как задачи, то мы получим:
- необходима возможность создания нового узла с минимальными усилиями;
- потенциально, необходимо сделать так, чтобы можно было дать среднему специалисту (эникею) одну небольшую строку для создания новой ноды и подключения к сети;
- необходимо обеспечить автоматическое распределение ключей между всеми активными узлами;
- необходимо обеспечить упрощенную процедуру обмена ключами между bootnod'ой и новым клиентом.
bootnode — узел с публичным адресом (см. выше);
За счет требования п.2, можно утверждать, что после обмена ключами между bootnode и новым узлом, и после
подключения узла к сети, распределение нового ключа произойдет автоматически.
Именно эти задачи и выполняет tinc-boot.
tinc-boot — это самодостаточное, не считая tinc, приложение с открытым исходным кодом, обеспечивающее:
- простое создание нового узла;
- автоматическое подключение к существующей сети;
- задание большинства параметров по-умолчанию;
- распределение ключей меду узлами.
Архитектура
Исполняемый файл tinc-boot состоит из четырех компонент: сервера начальной загрузки (bootnode), сервера управления распределением ключей и RPC команд управления к нему, а также модуль генерации узла.
Модуль генерации узла
Модуль генерации узла (tinc-boot gen) создает все необходимые файлы для успешного запуска tinc.
Упрощенно, его алгоритм можно описать так:
- Определить имя узла, сеть, параметры IP, порт, маску подсети и т.п.
- Нормализовать их (tinc имеет ограничение на некоторые значения) и создать недостающие
- Проверить параметры
- Если необходимо — установить tinc-boot в систему (отключаемо)
- Создать скрипты
tinc-up,tinc-down,subnet-up,subnet-down - Создать файл конфигурации
tinc.conf - Создать файл узла
hosts/ - Выполнить генерацию ключа
- Произвести обмен ключами с bootnode
- Зашифровать и подписать собственный файл узла с публичным ключом, случайный вектор инициализации (nounce) и имя узла при помощи xchacha20poly1305, где ключом шифрование является итог функции sha256 от токена
- Выполнить отправку данных по HTTP протоколу на bootnode
- Полученный ответ и заголовок
X-Node, содержащий имя загрузочного узла, расшифровать, используя оригинальный nounce и по такому же алгоритму - В случае успеха, сохранить полученный ключ в
hosts/и добавить записьConnectToв файл конфигурации (т.е. рекомендация куда подключаться) - Иначе — воспользоваться следующим в списке адресом загрузочной ноды и повторить с п. 2
- Вывести рекомендации по запуску сервиса
Преобразование через SHA-256 служит только для нормализации ключа до 32 байт
Для самого первого узла (т.е. когда нечего указывать в качестве загрузочного адреса), п.9 пропускается. Флаг --standalone.
Пример 1 — создание первого публичного узла
Публичный адрес — 1.2.3.4
sudo tinc-boot gen --standalone -a 1.2.3.4
- флаг
-aпозволяет указывать публично доступные адреса
Пример 1 — добавление не-публичного узла к сети
Загрузочный узел будет взят из примера выше. На узле необходимо иметь запущенный tinc-boot bootnode (далее описано).
sudo tinc-boot gen --token "MY TOKEN" http://1.2.3.4:8655
- флаг
--tokenзадает токен авторизации
Модуль начальной загрузки
Модуль начальной загрузки (tinc-boot bootnode) поднимает HTTP сервер с API для первичного обмена ключами с новыми клиентами.
По-умолчанию, используется порт 8655.
Упрощенно, алгоритм можно описать так:
- Принять запрос от клиента
- Расшифровать и проверить запрос при помощи xchacha20poly1305, используя вектор инициализации, переданный при запросе, и где ключом шифрование является итог функции sha256 от токена
- Проверить имя
- Сохранить файл, если файла с таким именем еще нет
- Зашифровать и подписать собственный файл узла и имя, используя алгоритм, описанный выше
- Вернуться на п.1
В совокупности, процесс первичного обмена ключами выглядит следующим образом:
Пример 1 — запуск узла загрузки
Предполагается, что первоначальная инициализация узла была проведена (tinc-boot gen)
tinc-boot bootnode --token "MY TOKEN"
- флаг
--tokenзадает токен авторизации. Он должен быть одинаковым у клиентов, подключающихся к узлу.
Пример 2 — запуск узла загрузки как сервис
tinc-boot bootnode --service --token "MY TOKEN"
- флаг
--serviceуказывает создать systemd сервис (по умолчанию, для данного примераtinc-boot-dnet.service) - флаг
--tokenзадает токен авторизации. Он должен быть одинаковым у клиентов, подключающихся к узлу.
Модуль распределения ключей
Модуль распределения ключей (tinc-boot monitor) поднимает HTTP сервер с API для обмена ключами с другими узлами внутри VPN. Он закрепляется на выданный сетью адрес (порт по-умолчанию — 1655, конфликтов с несколькими сетями не будет, так как каждая сеть имеет/должна иметь свой адрес).
Модуль запускается и работает полностью автоматически: работа с ним в ручном режиме не нужна.
Этот модуль запускается автоматически при поднятии сети (в скрипте tinc-up) и автоматически останавливается при остановке (в скрипте tinc-down).
Поддерживает операции:
GET /— отдать свой файл узлаPOST /rpc/watch?node=<>&subnet=<>— забрать файл от другого узла, предполагая наличие на нем запущенного аналогичного сервиса. По-умолчанию, попытки идут с таймаутом в 10 секунд, каждые 30 секунд вплоть до успеха или отмены.POST /rpc/forget?node=<>— оставить попытки (если они еще есть) забрать файл от другого узлаPOST /rpc/kill— завершает работу сервиса
Дополнительно, каждую минуту (по-умолчанию) и при получении нового файла конфигурации делается индексация сохраненных узлов на предмет наличие новых публичных нод. При обнаружении узлов с признаком Address, добавляется запись в конфигурационный файл tinc.conf для рекомендации к подключению при перезапуске.
Модуль распределения ключей (управление)
Команды на запрос (tinc-boot watch) и отмену запроса (tinc-boot forget) файла конфигурации от других узлов выполняются автоматически при обнаружении нового узла (скрипт subnet-up) и остановке (скрипт subnet-down) соответственно.
В процессе остановке сервиса, исполняется скрипт tinc-down в котором исполняется команда tinc-boot kill останавливающий модуль распределения ключей.
Вместо итого
Эта утилита создана под влиянием когнитивного диссонанса между гениальностью разработчиков Tinc и линейно растущей сложностью настройки новых узлов.
Основными идеями в процессе разработки были:
- если что-то может быть автоматизированно, оно должно быть автоматизировано;
- значения по-умолчанию должны покрывать как минимум 80% использования (принцип Парето);
- любое значение можно переопределить как при помощи флагов, так и при помощи переменных окружения;
- утилита должна помогать, а не вызывать желание призвать все кары небесные на создателя;
- использование токена авторизации для начальной инициализации — очевидный риск, однако, по мере возможности, он был сведен до минимума за счет тотальной криптографии и аутентификации (даже имя узла в ответном заголовке невозможно подменить).
Немного хронологии:
- Первый раз я воспользовался tinc более 4-ех лет назад. Изучил значительный объем материала. Настроил идеальную (в моем представлении) сеть
- Спустя пол-года, tinc был заменен в пользу zerotier, как более удобное/гибкое средство
- 2 года назад, я сделал Ansible playbook для развертывания tinc
- Через месяц мой скрипт сломался на инкрементальном развертывании (т.е. когда нельзя получить доступ ко всем узлам сети, а значит распределить ключи)
- Две недели назад, я написал bash-script скрипт, который явился прототипом для
tinc-boot - 3 дня назад после второй итерации, родилась первая (0.0.1 если быть точным) версия утилиты
- 1 день назад я свел установку новой ноды до одной строки:
curl -L https://github.com/reddec/tinc-boot/releases/latest/download/tinc-boot_linux_amd64.tar.gz | sudo tar -xz -C /usr/local/bin/ tinc-boot - В скором времени, будет добавлена возможность еще более простого подключения к сети (не в ущерб безопасности)
Во время разработки я активно тестировал на реальных серверах и клиентах (картинка из описания работы tinc выше взята из реальной жизни). Сейчас система работает без нареканий, а все сторонние VPN сервисы теперь отключены.
Код приложения написан на GO и открыт под лицензией MPL 2.0. Лицензия (вольный перевод) позволяет коммерческое (если вдруг кому-то надо) использование без открытия исходного продукта. Единственное требование — вносимые изменения обязаны быть переданы проекту.
Пул-реквесты приветствуются.
Полезные ссылки
Комментарии (38)
DaylightIsBurning
20.09.2019 21:31А где же пакеты для debian, centos, arch, openwrt?
sdm
21.09.2019 07:18Главный недостаток всех существующих решений mesh сетей именно отсутствие возможности простой настройки/установки на роутерах.
Именно на домашних роутерах таким решениям самое место.
LeshiyUrban Автор
21.09.2019 09:31Если скинете ссылки на какой-нибудь простой туториал по запаковке в openwrt, то я могу попробовать сделать в свободное время.
Sjam
21.09.2019 10:51Возможно эта статья поможет: openwrt.su/sborka/kompilyatsiya-otdelnogo-paketa-dlya-openwrt
или вот эта:
teamhelps.pp.ua/top/kompilyaciya-svoikh-prilozheniy-dlya-openwrt
maxim_ge
22.09.2019 13:37+1Очень интересно, большое спасибо за информацию про tinc! И tinc-boot — хорошая штука, судя по всему, попробуем. Плюсы во все кармы, однозначно.
PS: А какого размера сети реально работают на tinc? Быстрый поиск не дал результата, вдруг Вы в курсе…bervr
23.09.2019 15:40+1Судя по нашему опыту (который на версии 1.0) — хостов до 40, потом все плохо.
riv1329
23.09.2019 21:56Несколько лет назад тестировал tinc как «среду» между 10-ком филиалов на скорости 100Мбит/сек. Пару раз в месяц tinc зависал. Решилось принудительным перезапуском раз в сутки, но и после этого очень редко tinc зависал. Мы просто перезапускали его вручную. Сеть через tinc была резервной, в основном данные передавались через оптические соединения. Маршрутизацией управлял ospf с помощью которого происходило переключение с умершей оптики на tinc full-mesh соединение.
bervr
24.09.2019 07:26Возможно от режима работы еще зависит, мы работали на tun и примерно до 40 хостов все более-менее качало. Потом при росте количества хостов по непонятным причинам начинался мрак — то висло все, то отваливались хосты, что не могло не сказаться на маршрутах. А вот тут https://habr.com/ru/post/185624/ описан печальный опыт людей которые запускали на tap и в несколько потоков, но тоже отказались в итоге.
Klukonin
22.09.2019 14:54Грубо говоря, вы сосредоточились на версии 1.0 в которой применяется устаревший тип аутентификации и отсутствует поддержка
эллиптики.
А так же отказались от механизма инвайтов который делает ровно то же самое что и ваш сервис.
То есть, фактически, вы взяли с пыльной полки кактус и героически его съели.
Это я к тому что в версии 1.1 именно для данных целей был внедрён механизм инвайтов, а для деплоймента ключей остальных участников достаточно доверия к "boot" ноде.
То есть, это все решается просто использованием версии 1.1 с необходимыми параметрами в конфигурации.
Зачем в 2019 использовать устаревшую версию и героически пытаться пеиеизобрести то что уже сделано и работает?
LeshiyUrban Автор
22.09.2019 18:041.1 безусловно шаг вперёд. Напомните, пожалуйста, когда они в релиз планируют вывести?
Я то этого уже жду несколько лет.
Смею заметить, Ваша фраза про кактус несколько категорична. У меня нет ни малейшего желания изобретать велосипед. Однако пользоваться продуктом в нерелизной версии в вопросах безопасности — неоправданный (для меня) риск.
Так что либо кто-то принимает риск и пробует все новое (я так понимаю Ваш случай), либо кто-то (как я) используют проверенные решения и адаптируют их под нужные условия.
Klukonin
22.09.2019 18:29-1Это очень однобокое оправдание.
Не напомните сколько раз за этот год выходили патчи стабильной openssl?
Как же так, ведь это проверенное решение?
Tinc 1.0 по части механизмов аутентификации именно фундаментально уступает 1.1.
Потому мое сравнение с пыльной полкой и кактусом как раз кстати, я не просто так это написал.
В использовании RC нет ничего плохого. OpenWrt (как пример) последние стабильные релизы выпускали на основе ветки wireless-testing или backports в статусе RC.
Ubuntu уже много лет тащит пакеты из debian testing и experimental. Так что про риски и прочие это не более чем притянутые за уши аргументы.
Завтра случится очередной heartbleed и что, это повод не использовать новые "непроверенные" версии opensssl и сидеть на 1.0 ?
LibreOffice регулярно релизятся, а потом дают отмашку о том с какой минорной версии по их мнению "можно в продакшен".
Так что я вам рекомендую перестать фиксироваться на цифрах и смотреть больше на стабильность API. В этом плане Tinc 1.1 давно созрел.
А вот чтобы говорить об ограничениях, нестабильности или недостаточной готовности той или иной версии, требуется как минимум изучить примеры использования других людей, а ещё лучше приложиться самому и тоже протестировать. В таком случае это будет предметный разговор.
А сидеть на стуле и рассуждать "ну, они что-то не релизят и я опасаюсь" — это, пардон, балобольство.
Изменение циферки в версии это не причина того на сколько ПО стабильно, а следствие.
Klukonin
22.09.2019 21:13В вашем случае это не "использование проверенного решения и адаптация", а
1) Дублирование уже имеющейся, работающей и протестированной функциональности.
2) Подталкивание пользователей к использованию менее надёжного механизма аутентификации.
И все это сознательно, исключительно на поводу у собственных предрассудков, раз вы в курсе про существование версии 1.1.
Или вы не разобрались и не изучили работу механизма инвайтов и распространения ключей без непосредственного их добавления, на основании доверия к промежуточным нодам?
Просто бегло по верхам прочитали мануал, нашли фатальные недостатки и пошли писать?
Klukonin
22.09.2019 15:08К слову, версия 1.1 на данный момент есть даже в debian experimental. Не говоря о ppa и с сторонних репозиториях.
taurusbusy
23.09.2019 08:57+1 за версию 1.1. За всё время чтения статьи мне давал покоя вопрос «Зачем всё это, если есть tinc invite/join»? Запуск клиента — это 4 команды. Tinc join, ExperimentalProtocol yes, Subnet для текущего узла и tinc start.
Плюс tinc invite на условном «сервере».
По поводу доступности. Свежая FreeBSD:
# pkg search tinc
tinc-1.0.35_1 Virtual Private Network (VPN) daemon
tinc-devel-1.1pre17_3 Virtual Private Network (VPN) daemon
LeshiyUrban Автор
23.09.2019 09:11В целом я свою точку зрения высказал выше, но забыл добавить:
- 1.1pre17 — вышла 11 месяцев назад
- 1.0.36 — 3 недели назад. Часть комитов — бэкпорт из 1.1.
Klukonin
23.09.2019 11:34Бэкпорт о котором речь попал туда пол года надаз, а до этого, соответствено присутствовал в версии 1.1.
Последние коммиты — это исправления опечаток, выравнивание отступов и прочие вещи которые обычно делают коты когда у них других занятий нет.
Пройдите сюда и посмотрите что это за релиз
https://github.com/gsliepen/tinc/commits/master
Хватит мыслить как школьник и фапать на циферки.
Посмотрите к чему это привело. Я уже высказывался выше.
1) Дублирование функциональности
2) Навязывание пользователем устаревшего и менее безопасного протокола.LeshiyUrban Автор
23.09.2019 12:01Могу я Вас попросить все же не использовать подобного рода формулировки? "Фапать", "школьник" — не тот уровень диалога, который обычно ожидается на профессиональном ресурсе.
Мне кажется есть определенного уровня недопонимание:
- Я не навязываю никому и ничего — есть проблема: сложность настройки Tinc 1.0 в ряде ситуаций. Одно из решений — tinc-boot.
- В статье однозначно описывается взаимодействие с Tinc 1.0. Смысл обсуждать 1.1 — если в статье в явном виде описано ограничение на 1.0? Это вне рамках текста. Если есть желание пообщаться — можно перейти в личные диалоги.
- Я обосновал свое решение относительно 1.0. Вы и некоторые другие с ним не согласились. С моей точки зрение имеется паритет мнений. Дальнейшее обсуждение не имеет смысла (как мне кажется).
Я ни в коей мере не ограничиваю (и не навязываю) ни Вам лично, ни читателем единственное верное решение. Это сугубо личное решение каждого. Доводы "за" и "против" приведены. Далее — вопросы приоритетов и личных предпочтений.
Для меня лично, использовать в критичных местах (а вопросы безопасности я считаю критичными) версии продуктов, которые не помечены как стабильные не приемлемо. Можете считать это профессиональной деформацией.
taurusbusy
23.09.2019 13:01Самое забавное, что выход версии 1.1 был направлен именно на решение проблемы с безопасностью протокола, выявленной в версии 1.0.
Поэтому, вы себе противоречите.
Klukonin
23.09.2019 13:57- Одно из. Тут напрашивается картинка про конкурирующие стандарты. Вы просто сделали "свое". И при этом не решили никакой проблемы. Потому ваш результат заслуживает порицания.
- В статье описывается метод, прибитый гвоздями к устаревшей версии. С тем же успехом вы могли бы написать библиотеку, прибитую гвоздями к python 2.7 и при этом имеющуюся в версии 3.
Вы бы тоже утверждали что писали осознанно под 2.7 и явно ограничили это в статье, а критика подобного это "вне контекста"?
Нет, милейший, вы решили выложить свои наработки в открытый доступ и даже написали статью. "Выйти и поговорить" это другой формат, будьте готовы пояснить за свое решение публично - Вы ничего не обосновали. Все ваши доводы из разряда "потому что могу". Сравнения версий не проводилось, объективных аргументов в пользу выбора версии не приводилось. Только ваши фантазии и страхи.
Вы пытаетесь опровергнуть то чего я не говорил.
Вы ПОДТАЛКИВАЕТЕ пользователей к использованию менее безопасного протокола. И это даже еще хуже чем если бы вы что-то утверждали. Потому что в таком случае можно было бы оспорить или опровергнуть утверждения. А тут вы просто даете инструмент, который заведомо deprecated и еще вдобавок РЕАЛЬНО снижает безопасность решения вцелом. Но при этом он позиционируется как "то что избавит вас от боли".
Осознанно или по незнанию, но вы сделали ужасную вещь.
LeshiyUrban Автор
23.09.2019 14:48Можно пожалуйста доказательство того, что есть неисправленные уязвимости Tinc 1.0.36 и исправленные/недопущенные в 1.1? Это серьезное заявление, которое действительно имеет смысл в нашем обсуждение. Вы уже второй комментатор, который ссылается на это.
- Я не уловил, но как это относится к предмету обсуждения? Я же не свой VPN создавал, а обертку. Возможно вы имели ввиду, что есть другая функционально схожая обертка (для 1.0.x)? Буду признателен, если скинете ссылку.
- Как можно называть версию устаревший, если (а) обновления выходят регулярно, (б) нет другой версии этого же продукта в релизной версии? В Вашем примере про питон: версии py3-RC, не позиционировались как готовые решения для замены 2.7. Только с момента релиза.
- Тут есть фундаментальная проблема: с моей точки зрения, довод в пользу 1.0 — его стабильность и актуальность, 1.1 — не релиз (что подчеркивается на сайте). С одной стороны, я признаю Ваши аргументы в пользу 1.1 (функциональность, удобство и в целом более продуманный дизайн). С другой, Вы мои аргументы не признаете. Логический тупик для диалога. Ну или диалог превращается в монолог.
taurusbusy
23.09.2019 15:15+1Legacy protocol, который используется в версии 1.0:
This legacy authentication protocol has several weaknesses, pointed out by security export Peter Gutmann. First, data is encrypted with RSA without padding. Padding schemes are designed to prevent attacks when the size of the plaintext is not equal to the size of the RSA key. Tinc always encrypts random nonces that have the same size as the RSA key, so we do not believe this leads to a break of the security. There might be timing or other side-channel attacks against RSA encryption and decryption, tinc does not employ any protection against those. Furthermore, both sides send identical messages to each other, there is no distinction between server and client, which could make a MITM attack easier. However, no exploit is known in which a third party who is not already trusted by other nodes in the VPN could gain access. Finally, the RSA keys are used to directly encrypt the session keys, which means that if the RSA keys are compromised, it is possible to decrypt all previous VPN traffic. In other words, the legacy protocol does not provide perfect forward secrecy.
SPTPS, который используется в версии 1.1.LeshiyUrban Автор
23.09.2019 15:25Спасибо за детали.
Не считая perfect forward security — это отсылка на CVE-
2018-16758, которая исправлена после 1.0.34Klukonin
23.09.2019 15:49А почему вы считаете что можно забить на PFS и пользоваться legacy схемой когда перехват/кража ключа позволяет расшифровать ВЕСЬ собранный до этого трафик?
Это приемлемо во славу стабильного релиза?LeshiyUrban Автор
23.09.2019 15:56Нет, отнюдь. PFS это серьезный довод, чтобы присмотреться к 1.1 (даже если он и не в релизе).
Klukonin
23.09.2019 16:48Я считаю что есть смысл добавить это в стаью. Собствено, ради этого и я вступил в дискуссию, пытаясь хоть как-то указать на неконструктивность подхода "because I can" и недостаточно глубокое изучение вопроса.
Три момента заслуживающих внимания читателей:
1) В серсии 1.1 данная вункциональность уже реализована из коробки.
2) Методы аутентификации в версии 1.1 более безопасны, но обратно не совместимы с 1.0 и бэкпортированы не будут никогда.
3) Исходя из официальной документации 1.0 версия считается legacy, хотя для нее и выходят корректирующие релизы (прямо как gnupg, правда?) и тем кто заботится о безопасности следовало бы присмотреться к механизму инвайтов и новой версии Tinc.
Madnezz
23.09.2019 17:47Эх, такую бы штуку для wireguard
Klukonin
23.09.2019 19:00
Klukonin
23.09.2019 19:06Проблема WireGuard в том что это исключительно TUN (L3). В то время как TINC умеет и TUN (L3) и TAP (L2).
Работает в пространстве ядра (модуль).
Проблема Tinc в том что он прибит гвоздями к OpenSSL.
Работает в пространстве пользователя (демон).
То есть, чисто менеджерским взглядом будет казаться что это отличная перспектива. Но на деле это два абсолютно разных проекта.
Self_Perfection
24.09.2019 00:29В полной ли мере tinc — mesh?
Я так понимаю, что если два устройства, у которых в конфиге tinc стоит connectto = China внезапно окажутся подключены к одной wi-fi точке, то пакеты между ними всё равно будут ходить через Китай, разве нет?
Говорят для mesh yggdrasil хорош.LeshiyUrban Автор
24.09.2019 05:35Если включено локальное обнаружение пиров (tinc-boot включает его в конфиг) то будет напрямую общаться.
Да yggdrasil я смотрел и даже немного участвую в разработке/обсуждении.
Sjam
Вроде бы и хорошо, но есть но
1. ключи и настройки передаются поверх дикого интернета по незащищенному http?
2. все таки нужны публичные ноды?
3. было бы наверное интереснее, когда сеть работала бы в принципе без публичных нод, а вместо ip использовала адреса tox сети… И поиск нод велся бы используя публичные ноды tox и DHT, коими является любой клиент, бот, нода…
LeshiyUrban Автор
2, 3. Спасибо, так наверное можно сделать. Но нужно детально проработать
Sjam
ssl proxy особенно на роутере как-то весьма странно. Намного лучше когда сама утилита позволяет использовать защищенные каналы без дополнительных сторонних прослоек.
Так можно было бы и в через tor пустить поверх например HiddenService
LeshiyUrban Автор
Во-первых, все-же трафик зашифрованный и аутентифицированный, пусть и передаваемый по открытым каналам связи. Подменить или прочитать сообщение (не зная токен) нельзя.
Во-вторых, предположим будет возможность задавать сертификаты (это не сложно добавить). Тогда Вам либо (а) придется добавлять сертификаты в доверенные каждого устройства (при самоподписанном сертификате), либо (б) использовать честные сертификаты (let's encrypt например), что в Вашем контексте о роутере звучит необычно. С другой стороны, для серверов это имеет смысл.
Реализовать несложно. Если Вас не затруднит, можете, пожалуйста, оформить это как feature request на github?