Full mesh vpn что это

Список Full-Mesh VPN решений

Многие интересуются Full-Mesh (или P2P) VPN, хотят использовать их для игр с друзьями, для связи удаленных офисов, серверов, да для чего угодно. Обычные VPN, вроде OpenVPN или PPTP, пропускают весь трафик через центральный сервер, а Full-Mesh соединяются непосредственно с нодами, зачастую пробивая NAT.

Со своими серверами (преимущественно для игр):

Tunngle
Basic и Premium. Только Windows.

VPN для игр, аналог Hamachi. Zero-config через сервер программы. Чат с возможностью передачи файлов, голосовой чат на основе Ventrillo и Mumble. Имеется мини-файрволл.
В бесплатной версии можно создавать комнату до 32 человек, которая удаляется
после 3 дней неактивности. Нельзя настравать мини-файрволл, он блокирует порты
1-1024 и все протоколы, кроме tcp, udp и icmp. Пробивает NAT.
Premium дает возможность создавать комнаты до 255 человек, скрывать комнаты из
каталога, изменять ник, использовать QoS, настраивать мини-файрволл,
использовать ник вместо ip (dns).

Social VPN
Open Source. Windows и Linux. C#.

Zero-config с XMPP в качестве бекенда, интеграция с Gtalk. Пробивает NAT, соединяется напрямую, или использует свои сервера, если это невозможно. Есть DNS.

Remobo
Free. Windows, Linux и MacOS.

Аналог Hamachi, zero-config через сервер программы. Имеется встроенный чат. Возможно использовать другие компьютеры в качестве прокси. Пробивает NAT.
Есть PRO-версия, которая отличается наличием демона с CLI.

Без своих серверов:

NeoRouter
Free. Windows, Linux, MacOS, FreeBSD, Android.

Есть portable-версия и веб-клиент. Поддержка IPv6, пробивает NAT.

Zero-config через Gtalk и Gmail. VPN, VNC, Шаринг, синхронизация и бекап файлов.
Генерация превью к картинкам, создание каталогов, стриминг аудио и видео (используется web-интерфейс).
Пробивает NAT, сервер-нода отсутствует.

P2PVPN
Open Source. Windows и Linux. Java.

VPN и чат между пирами. Используется BitTorrent (а конкретно трекер OpenBitTorrent) для поиска пиров вашей сети. NAT не пробивает, требует открытого порта хотя бы у одного участника сети, сервер-нода отсутствует.
Проект немного заглох, последяя версия вышла в 2010.

Wippien
Open Source. Windows и Linux.

Использует XMPP в качестве бекенда, интеграция с Gtalk. Пробивает NAT.

Для серверного использования:

tinc
Open Source. Windows, Linux, *BSD, MacOS, Solaris, iPhone.

Старый проект, легкое конфигурирование, сервер-ноды нет. Поддержка IPv6, пробивает NAT.

PeerVPN
Open Source, Linux и FreeBSD. Неофициальные порты для MacOS и Windows.

Поддержка IPv6, пробивает NAT.

Full-mesh VPN без публичных узлов?

В текущий момент юзаю tinc с одной публичной нодой на халявном инстансе AWS EC2, все остальные ноды за провайдерскими NAT-ами. Всё бы хорошо, всё работает, но триал скоро истекает, платить не хочу, да и сообщения от AWS на мыло «ваш лимит скоро будет исчерпан» немного нервируют: tinc служебным трафиком как раз примерно гигабайт в месяц жрёт. Хочу другое решение.

Смотрел на Zerotier, пока думаю остановиться на нём, но возникла мысля: а есть ли истинно децентрализованное решение, вообще не подвязанное на каких-то чужих серверах для установки соединений? Типа как поставил софтину на каждую ноду, бутстрапнул их ручками, а дальше оно само крутится, каждая нода поддерживает адреса всех остальных нод, и неважно, что ноды под NAT-ами, с динамическими адресами и вообще всё плохо. Понятно, что в плане стабильности всё будет куда хуже, чем когда у нас есть служебный сервер с публичным IP (особенно когда одну ноду выдернуть на недельку, а за это время у всех остальных адреса поменялись), но всё-таки: есть ли на свете что-то похожее?

tsmx ★
03.06.21 22:16:36 MSK

tinc-boot — full-mesh сеть без боли

Автоматическая, защищенная, распределенная, с транзистивными связями (т.е. пересылкой сообщений, когда нет прямого доступа между абонентами), без единой точки отказа, равноправная, проверенная временем, с низким потреблением ресурсов, 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.

С моей точки зрения, одной из сильнейших возможностей является пересылка сообщений при невозможности прямого соединения. При этом, таблицы маршрутизации строятся полностью автоматически. Даже узлы без публичного адреса могут пропускать трафик через себя.

Рассмотрим ситуацию тремя серверами (Китай, РФ, Сингапур) и тремя клиентами (РФ, Китай и Филиппины):

• сервера имеют публичный адрес, клиенты за NAT’ом;
• РКН во время очередного бана вероятных прокси Телеграмма заблокировал всех хостеров кроме «дружественного» Китая;
• сетевая граница Китай РФ является нестабильной и может падать (из-за РКН и/или из-за Китайского цензора);
• соединения до Сингапура условно стабильные (личный опыт);
• Манила (Филиппины) ни для кого угрозой не является, а потому разрешена для всех (по причине удаленности от всех и всего).

На примере обмена трафиком между Шанхаем и Москвой рассмотрим сценарии работы Tinc (примерно):

1. Штатная ситуация: Москва russia-srv china-srv Шанхай
2. РКН закрыл соединение до Китая: Москва russia-srv Манила Сингапур Шанхай
3. (после 2) при отказе сервера в Сингапуре, трафик перекидывается на сервер в Китае и наоборот.

При возможности, Tinc пытается организовать прямое соединение между двумя узлами за NAT за счет «пробивки».

Краткая вводная в конфигурирование tinc

Tinc позиционируется как легкий в настройки сервис. Однако, что-то пошло не так — для создания нового узла минимально необходимо:

• описать настройку узла (тип, имя) ( tinc.conf );
• описать файл конфигурации (обслуживаемые подсети, публичные адреса) ( hosts/ );
• создать ключ;
• создать скрипт, задающий адрес узла и сопутствующие параметры ( tinc-up );
• желательно создать скрипт, очищающий созданные параметры после остановки ( tinc-down ).

В дополнении к этому, при подключении к существующей сети, необходимо получить существующие ключи узлов и предоставить свой.

Т.е: для второго узла

При использовании двухсторонней синхронизации (например unison ), количество дополнительных операций увеличивается до на N штук, где N — число публичных узлов.

Надо отдать должное разработчикам Tinc — для включения в сеть достаточно обменяться ключами
только с одним из узлов (bootnode). После запуска сервиса и подключения к участнику, tinc получит топологию
сети и сможет работать со всеми абонентами.

Однако, если загрузочный хост стал недоступен, а tinc перезапустился, то нет никакой возможности
подключится к виртуальной сети.

Более того, огромные возможности tinc в совокупности с академической документацией оного (хорошо описано, но мало примеров), дают обширное поле для совершения ошибок.

Причины создания tinc-boot

Если обобщить описанные выше проблемы, и сформулировать их как задачи, то мы получим:

1. необходима возможность создания нового узла с минимальными усилиями;
   • потенциально, необходимо сделать так, чтобы можно было дать среднему специалисту (эникею) одну небольшую строку для создания новой ноды и подключения к сети;
2. необходимо обеспечить автоматическое распределение ключей между всеми активными узлами;
3. необходимо обеспечить упрощенную процедуру обмена ключами между bootnod’ой и новым клиентом.

bootnode — узел с публичным адресом (см. выше);

За счет требования п.2, можно утверждать, что после обмена ключами между bootnode и новым узлом, и после
подключения узла к сети, распределение нового ключа произойдет автоматически.

Именно эти задачи и выполняет tinc-boot.

tinc-boot — это самодостаточное, не считая tinc , приложение с открытым исходным кодом, обеспечивающее:

• простое создание нового узла;
• автоматическое подключение к существующей сети;
• задание большинства параметров по-умолчанию;
• распределение ключей меду узлами.

Архитектура

Исполняемый файл tinc-boot состоит из четырех компонент: сервера начальной загрузки (bootnode), сервера управления распределением ключей и RPC команд управления к нему, а также модуль генерации узла.

Модуль генерации узла

Модуль генерации узла ( tinc-boot gen ) создает все необходимые файлы для успешного запуска tinc.

Упрощенно, его алгоритм можно описать так:

1. Определить имя узла, сеть, параметры IP, порт, маску подсети и т.п.
2. Нормализовать их (tinc имеет ограничение на некоторые значения) и создать недостающие
3. Проверить параметры
4. Если необходимо — установить tinc-boot в систему (отключаемо)
5. Создать скрипты tinc-up , tinc-down , subnet-up , subnet-down
6. Создать файл конфигурации tinc.conf
7. Создать файл узла hosts/
8. Выполнить генерацию ключа
9. Произвести обмен ключами с bootnode
   1. Зашифровать и подписать собственный файл узла с публичным ключом, случайный вектор инициализации (nounce) и имя узла при помощи xchacha20poly1305, где ключом шифрование является итог функции sha256 от токена
   2. Выполнить отправку данных по HTTP протоколу на bootnode
   3. Полученный ответ и заголовок X-Node , содержащий имя загрузочного узла, расшифровать, используя оригинальный nounce и по такому же алгоритму
   4. В случае успеха, сохранить полученный ключ в hosts/ и добавить запись ConnectTo в файл конфигурации (т.е. рекомендация куда подключаться)
   5. Иначе — воспользоваться следующим в списке адресом загрузочной ноды и повторить с п. 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 .

   Упрощенно, алгоритм можно описать так:

   1. Принять запрос от клиента
   2. Расшифровать и проверить запрос при помощи xchacha20poly1305, используя вектор инициализации, переданный при запросе, и где ключом шифрование является итог функции sha256 от токена
   3. Проверить имя
   4. Сохранить файл, если файла с таким именем еще нет
   5. Зашифровать и подписать собственный файл узла и имя, используя алгоритм, описанный выше
   6. Вернуться на п.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. Лицензия (вольный перевод) позволяет коммерческое (если вдруг кому-то надо) использование без открытия исходного продукта. Единственное требование — вносимые изменения обязаны быть переданы проекту.

   Полезные ссылки

   • Репозиторий
   • Документация по tinc

   Список Full-Mesh VPN решений

   Многие интересуются Full-Mesh (или P2P) VPN, хотят использовать их для игр с друзьями, для связи удаленных офисов, серверов, да для чего угодно. Обычные VPN, вроде OpenVPN или PPTP, пропускают весь трафик через центральный сервер, а Full-Mesh соединяются непосредственно с нодами, зачастую пробивая NAT.

   Со своими серверами (преимущественно для игр):

   Tunngle
   Basic и Premium. Только Windows.

   VPN для игр, аналог Hamachi. Zero-config через сервер программы. Чат с возможностью передачи файлов, голосовой чат на основе Ventrillo и Mumble. Имеется мини-файрволл.
   В бесплатной версии можно создавать комнату до 32 человек, которая удаляется
   после 3 дней неактивности. Нельзя настравать мини-файрволл, он блокирует порты
   1-1024 и все протоколы, кроме tcp, udp и icmp. Пробивает NAT.
   Premium дает возможность создавать комнаты до 255 человек, скрывать комнаты из
   каталога, изменять ник, использовать QoS, настраивать мини-файрволл,
   использовать ник вместо ip (dns).

   Social VPN
   Open Source. Windows и Linux. C#.

   Zero-config с XMPP в качестве бекенда, интеграция с Gtalk. Пробивает NAT, соединяется напрямую, или использует свои сервера, если это невозможно. Есть DNS.

   Remobo
   Free. Windows, Linux и MacOS.

   Аналог Hamachi, zero-config через сервер программы. Имеется встроенный чат. Возможно использовать другие компьютеры в качестве прокси. Пробивает NAT.
   Есть PRO-версия, которая отличается наличием демона с CLI.

   Без своих серверов:

   NeoRouter
   Free. Windows, Linux, MacOS, FreeBSD, Android.

   Есть portable-версия и веб-клиент. Поддержка IPv6, пробивает NAT.

   Zero-config через Gtalk и Gmail. VPN, VNC, Шаринг, синхронизация и бекап файлов.
   Генерация превью к картинкам, создание каталогов, стриминг аудио и видео (используется web-интерфейс).
   Пробивает NAT, сервер-нода отсутствует.

   P2PVPN
   Open Source. Windows и Linux. Java.

   VPN и чат между пирами. Используется BitTorrent (а конкретно трекер OpenBitTorrent) для поиска пиров вашей сети. NAT не пробивает, требует открытого порта хотя бы у одного участника сети, сервер-нода отсутствует.
   Проект немного заглох, последяя версия вышла в 2010.

   Wippien
   Open Source. Windows и Linux.

   Использует XMPP в качестве бекенда, интеграция с Gtalk. Пробивает NAT.

   Для серверного использования:

   tinc
   Open Source. Windows, Linux, *BSD, MacOS, Solaris, iPhone.

   Старый проект, легкое конфигурирование, сервер-ноды нет. Поддержка IPv6, пробивает NAT.

   PeerVPN
   Open Source, Linux и FreeBSD. Неофициальные порты для MacOS и Windows.

   Поддержка IPv6, пробивает NAT.

   Похожие публикации:

   1. Как называется wi fi сеть построенная на основе точки доступа
   2. Как подтвердить дату покупки airpods pro
   3. Как убрать значок загрузки на айфоне
   4. Что будет с стоимостью смартфоном самсунг декабрь