Автоматическая, защищенная, распределенная, с транзистивными связями (т.е. пересылкой сообщений, когда нет прямого доступа между абонентами), без единой точки отказа, равноправная, проверенная временем, с низким потреблением ресурсов, full-mesh VPN сеть c возможностью "пробивки" NAT — это возможно? Правильные ответы: Ссылка на пропуск вводной части К сожалению, информации о Tinc VPN на Хабре публиковалось немного, но пару релевантных статей все же можно найти: Из англоязычных статей можно выделить: Первоисточником лучше считать оригинальную документацию Tinc man Итак (вольная перепечатка с официального сайта), Tinc VPN это сервис (демон tincd) обеспечивающий функционирование приватной сети за счет тунелирования и шифрования трафика между узлами. Исходный код открыт и доступен под лицензией GPL2. Подобно классическим (OpenVPN) решением, созданная виртуальная сеть доступна на уровне IP (OSI 3), а значит, в общем случае, внесение изменений в приложения не потребуется. Ключевые особенности: Существует две ветки развития tinc: 1.0.x (почти во всех репозиториях) и 1.1 (вечная бета). В статье везде используется версия 1.0.x. С моей точки зрения, одной из сильнейших возможностей является пересылка сообщений при невозможности прямого соединения. При этом, таблицы маршрутизации строятся полностью автоматически. Даже узлы без публичного адреса могут пропускать трафик через себя.  Рассмотрим ситуацию тремя серверами (Китай, РФ, Сингапур) и тремя клиентами (РФ, Китай и Филиппины): На примере обмена трафиком между Шанхаем и Москвой рассмотрим сценарии работы Tinc (примерно): При возможности, Tinc пытается организовать прямое соединение между двумя узлами за NAT за счет "пробивки". Tinc позиционируется как легкий в настройки сервис. Однако, что-то пошло не так — для создания нового узла минимально необходимо: В дополнении к этому, при подключении к существующей сети, необходимо получить существующие ключи узлов и предоставить свой. Т.е: для второго узла  Для третьего  При использовании двухсторонней синхронизации (например unison), количество дополнительных операций увеличивается до на N штук, где N — число публичных узлов. Более того, огромные возможности tinc в совокупности с академической документацией оного (хорошо описано, но мало примеров), дают обширное поле для совершения ошибок. Если обобщить описанные выше проблемы, и сформулировать их как задачи, то мы получим: За счет требования п.2, можно утверждать, что после обмена ключами между bootnode и новым узлом, и после
подключения узла к сети, распределение нового ключа произойдет автоматически. Именно эти задачи и выполняет tinc-boot. tinc-boot — это самодостаточное, не считая tinc, приложение с открытым исходным кодом, обеспечивающее: Исполняемый файл tinc-boot состоит из четырех компонент: сервера начальной загрузки (bootnode), сервера управления распределением ключей и RPC команд управления к нему, а также модуль генерации узла. Модуль генерации узла (tinc-boot gen) создает все необходимые файлы для успешного запуска tinc.  Упрощенно, его алгоритм можно описать так: Для самого первого узла (т.е. когда нечего указывать в качестве загрузочного адреса), п.9 пропускается. Флаг --standalone. Пример 1 — создание первого публичного узла Публичный адрес — 1.2.3.4 sudo tinc-boot gen --standalone -a 1.2.3.4 Пример 1 — добавление не-публичного узла к сети Загрузочный узел будет взят из примера выше. На узле необходимо иметь запущенный tinc-boot bootnode (далее описано). sudo tinc-boot gen --token "MY TOKEN" http://1.2.3.4:8655 Модуль начальной загрузки (tinc-boot bootnode) поднимает HTTP сервер с API для первичного обмена ключами с новыми клиентами.  По-умолчанию, используется порт 8655. Упрощенно, алгоритм можно описать так: В совокупности, процесс первичного обмена ключами выглядит следующим образом:  Пример 1 — запуск узла загрузки Предполагается, что первоначальная инициализация узла была проведена (tinc-boot gen) tinc-boot bootnode --token "MY TOKEN" Пример 2 — запуск узла загрузки как сервис tinc-boot bootnode --service --token "MY TOKEN" Модуль распределения ключей (tinc-boot monitor) поднимает HTTP сервер с API для обмена ключами с другими узлами внутри VPN. Он закрепляется на выданный сетью адрес (порт по-умолчанию — 1655, конфликтов с несколькими сетями не будет, так как каждая сеть имеет/должна иметь свой адрес). Модуль запускается и работает полностью автоматически: работа с ним в ручном режиме не нужна. Этот модуль запускается автоматически при поднятии сети (в скрипте tinc-up) и автоматически останавливается при остановке (в скрипте tinc-down). Поддерживает операции: Дополнительно, каждую минуту (по-умолчанию) и при получении нового файла конфигурации делается индексация сохраненных узлов на предмет наличие новых публичных нод. При обнаружении узлов с признаком Address, добавляется запись в конфигурационный файл tinc.conf для рекомендации к подключению при перезапуске. Команды на запрос (tinc-boot watch) и отмену запроса (tinc-boot forget) файла конфигурации от других узлов выполняются автоматически при обнаружении нового узла (скрипт subnet-up) и остановке (скрипт subnet-down) соответственно. В процессе остановке сервиса, исполняется скрипт tinc-down в котором исполняется команда tinc-boot kill останавливающий модуль распределения ключей. Эта утилита создана под влиянием когнитивного диссонанса между гениальностью разработчиков Tinc и линейно растущей сложностью настройки новых узлов. Основными идеями в процессе разработки были: Немного хронологии: Во время разработки я активно тестировал на реальных серверах и клиентах (картинка из описания работы tinc выше взята из реальной жизни). Сейчас система работает без нареканий, а все сторонние VPN сервисы теперь отключены. Код приложения написан на GO и открыт под лицензией MPL 2.0. Лицензия (вольный перевод) позволяет коммерческое (если вдруг кому-то надо) использование без открытия исходного продукта. Единственное требование — вносимые изменения обязаны быть переданы проекту. Пул-реквесты приветствуются.