Full mesh vpn что это

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 (примерно):

Штатная ситуация: Москва 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. Лицензия (вольный перевод) позволяет коммерческое (если вдруг кому-то надо) использование без открытия исходного продукта. Единственное требование — вносимые изменения обязаны быть переданы проекту.

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

Репозиторий
Документация по 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.

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

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

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

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

Remobo
Free. Windows, Linux и MacOS.

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

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

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

P2PVPN
Open Source. Windows и Linux. Java.

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.

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

да, с болью, если вы используете 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

шифрование, аутентификация и сжатие трафика;
полностью автоматическое full-mesh решение, включающее в себя построение связей к узлам сети в режиме «все-со-всеми» или, если это неприменимо, пересылку сообщений между промежуточными хостами;
«пробивка» NAT;
возможность соединять изолированные сети на уровне ethernet (виртуальный switch);
поддержка множества ОС: Linux, FreeBSD, OS X, Solaris, Windows и т.д.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Архитектура

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

Модуль генерации узла ( 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 байт

Пример 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 задает токен авторизации

Модуль начальной загрузки

По-умолчанию, используется порт 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 задает токен авторизации. Он должен быть одинаковым у клиентов, подключающихся к узлу.

Модуль распределения ключей

Модуль запускается и работает полностью автоматически: работа с ним в ручном режиме не нужна.

GET / — отдать свой файл узла
POST /rpc/watch?node=<>&subnet=<> — забрать файл от другого узла, предполагая наличие на нем запущенного аналогичного сервиса. По-умолчанию, попытки идут с таймаутом в 10 секунд, каждые 30 секунд вплоть до успеха или отмены.
POST /rpc/forget?node=<> — оставить попытки (если они еще есть) забрать файл от другого узла
POST /rpc/kill — завершает работу сервиса

Модуль распределения ключей (управление)

Вместо итого

Основными идеями в процессе разработки были:

если что-то может быть автоматизированно, оно должно быть автоматизировано;
значения по-умолчанию должны покрывать как минимум 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

full mesh VPN между пятью сетями

Чем бы таким замутить VPN-каналы каждый-с-каждым между пятью сетками в разных местах?
Сейчас на каждом узле подняты по 4 openvpn-демона один-к-одному, хочется уменьшить число сущностей.

Как вариант — переделка текущей схемы на такую: на каждом узле 2 клиентских подключения (демона в client-mode) на 2 разных сервера и прием 2 клиентских подключений на себя на один сервер (т.е. демон в server-mode).
Т.о. образом уменьшаем число демонов на 1 штук.

Можно ли лучше? Стоит ли связываться с IPSEC’ом?

Шифрование нужно, VPN бегает через интернет, ОС на шлюзах — Debian Etch.

PS. Предполагается использование основного/резервного канала на каждом сервере с непредсказуемыми заранее переключениями, так что тут могут быть потенциальные грабли для работы VPN (какие — пока точно не понимаю, но они точно будут).

Update:
в идеале, хотелось бы получить одного демона на машину (ну или один конфиг/скрипт настройки и т.д.), т.е. узлы должны быть, видимо равноправны: указал список пиров и некие общие настройки типа ключей, и все собралось

Территориально-распределенные VPN-сети

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

Аренда каналов у провайдера: Распространенный и надежный вариант. Провайдер предоставляет в аренду выделенные физические или логические каналы связи. Такие каналы часто называют «точка-точка»

Достоинства:

Простота подключения и использования – обслуживание оборудования и каналов полностью возлагается на провайдера;
Гарантированная ширина канала – скорость передачи данных всегда соответствует заявленной провайдером;

Безопасность и контроль – компания не может контролировать оборудование на стороне провайдера.

Построение собственных (физических) магистралей связи: Надежное и затратное решение, поскольку построение физического канала связи полностью возлагается на компанию. При таком решении компания полностью контролирует и обслуживает построенные каналы

Достоинства:

Гибкость – возможность развертывания каналов, отвечающих всем необходимым требованиям;
Безопасность и контроль – полный контроль канала, поскольку он принадлежит компании;

Развертывание – построение таких частных каналов трудоемкое и затратное решение. Прокладка километров оптики по столбам может встать в круглую сумму. Даже если не брать в расчет получение разрешений всех гос. инстанций;
Обслуживание – обслуживание канала полностью возлагается на компанию, поэтому в штате должны быть высококвалифицированные специалисты для обеспечения его работоспособности;
Низкая отказоустойчивость – внешние оптические линии связи часто подвергаются неумышленным повреждениям (строительная техника, коммунальные службы, итд). Время обнаружения и исправления оптической линии связи может занять несколько недель.
Ограничено одной локацией – прокладывать внешние оптические линии связи актуально только в случае, если объекты расположены в пределах нескольких десятков километров. Тянуть связь в другой город на сотни и тысячи километров не представляется возможным из соображений здравого смысла.

Построение защищенного канала через Интернет (VPN): Такое решение является относительно бюджетным и гибким. Для объединения удаленных офисов достаточно подключения к Интернету и сетевого оборудования с возможностью создания VPN соединений

Достоинства:

Низкая стоимость – компания платит только за доступ в Интернет;
Масштабируемость – для подключения нового офиса необходимо наличие Интернета и маршрутизатора;

Пропускная способность канала – скорость передачи данных может варьироваться (нет гарантированной полосы пропускания);

В этой статье более подробно будет рассмотрен последний пункт, а именно — какие преимущества предоставляет бизнесу технология VPN.
Виртуальная частная сеть (VPN) – совокупность технологий обеспечивающих защищенное соединение (туннель) двух и более удаленных локальных сетей через публичную сеть (прим. Интернет).

Уникальные преимущества территориально распределенных VPN-сетей

Защита передаваемого трафика: передавать трафик по VPN туннелю безопасно при использовании криптостойких протоколов шифрования (3DES, AES). Помимо шифрования обеспечивается проверка целостности данных и подлинности отправителя, исключая возможность подмены информации и подключения злоумышленника.

Надежность соединения: ведущие производители оборудования совершенствуют технологии VPN подключений, обеспечивая автоматическое восстановление VPN туннелей в случае кратковременного выхода из строя соединения к публичной сети.
Мобильность и удобство подключения: к локальной сети компании можно подключиться из любой точки мира и практически с любого современного устройства (смартфон, планшетный компьютер, ноутбук), при этом соединение будет защищено. Большинство производителей мультимедийных устройств добавили поддержку VPN в свою продукцию.

Резервирование и балансировка нагрузки: если вы используете двух провайдеров при подключении к сети Интернет (для балансировки/отказоустойчивости), то возможна балансировка трафика VPN туннелей между провайдерами. В случае выхода из строя одного из провайдеров, туннель будет использовать резервное соединение.

Приоритезация трафика: возможность управления трафиком с помощью QoS — приоритезация голосового, видео-трафика в случае высокой нагрузки на туннель.

VPN-сети в бизнесе

Единая сеть

Объединение территориально распределенных локальных сетей компании в единую сеть (подключение филиалов к главному офису) значительно упрощает взаимодействие и обмен данными внутри компании, снижая затраты на обслуживание. Любые корпоративные системы требуют единого сетевого пространства для работы сотрудников. Это может быть IP телефония, системы бухгалтерского и финансового учета, CRM, видеоконференцсвязь, и т.д.

Мобильный доступ

Независимо от расположения сотрудника, при наличии интернета и ноутбука/смартфона/планшета, сотрудник может подключиться к внутренним ресурсам компании. Благодаря этому преимуществу у сотрудников имеется возможность выполнять работу и оперативно решать задачи, находясь за пределами офиса.

Объединение сетей разных компаний

Нередко необходимо объединить сети бизнес-партнеров, при этом такое объединение можно организовать как с ограничением, так и без ограничения доступа к внутренним ресурсам каждой из компаний. Такое объединение упрощает взаимодействие между компаниями.

Удаленное управление IT-инфраструктурой

Благодаря защищенному удаленному доступу к оборудованию IT-инфраструктуры компании, администратор способен в кратчайшие сроки решать поставленные задачи и реагировать на возникшие проблемы.

Качество обслуживания

Трафик видеоконференций, IP-телефонии и некоторых других приложений требует гарантированную ширину канала. Благодаря использованию QoS в VPN туннелях например можно объединить IP-телефонию локальной сети компании и удаленного офиса.

Сферы применения распределенных VPN-сетей и корпоративных сетей передачи данных (КСПД)

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

Решения для малого бизнеса. Зачастую требования для такого решения – это возможность подключения удаленных пользователей (до 10) к внутренней сети и/или объединение сетей нескольких офисов. Такие решения являются простыми и быстрыми в развертывании. Для такой сети рекомендуется наличие резервного канала со скоростью ниже либо такой же как у основного. Резервный канал является пассивным и используется только в случае отключения основного (VPN туннель автоматически строится по резервному каналу). Резервирование пограничного оборудования для таких решений применяется редко и зачастую необоснованно.

Передаваемый по туннелю трафик – трафик внутренних приложений (почта, веб, документы), голосовой трафик.

Потребность в резервировании канала: средняя

Потребность в резервировании оборудования: низкая

Решения для среднего бизнеса. Наряду с подключением удаленных сотрудников (до 100), сетевая инфраструктура должна обеспечивать подключение нескольких удаленных офисов. Для таких решений резервирование Интернет канала обязательно, при этом пропускная способность резервного канала должна быть сопоставима со скоростью основного канала. Во многих случаях резервный канал активный (осуществляется балансировка нагрузки между каналами). Рекомендуется резервировать оборудование критически важных узлов сети (прим. пограничный роутер центрального офиса). Топология VPN сети – звезда или partial mesh.

Передаваемый по туннелю трафик – трафик внутренних приложений (почта, веб, документы), голосовой трафик, трафик видеоконференций.

Потребность в резервировании канала: высокая

Потребность в резервировании оборудования: средняя

Решения для крупного бизнеса, распределённая сеть филиалов. Такие сети достаточно больших масштабов сложны в развертывании и поддержке. Топология такой сети с точки зрения организации VPN туннелей может быть: звезда, partial mesh, full mesh (на схеме приведен вариант full mesh). Резервирование канала обязательно (можно больше 2х провайдеров), как и резервирование оборудования критических важных узлов сети. Все, либо несколько каналов активны. В сетях такого уровня нередко применяются выделенные физические каналы (leased lines) или VPN предоставляемый провайдерами. В такой сети необходимо предусмотреть максимальную надежность и отказоустойчивость с целью минимизирования простоя бизнеса. Оборудование для таких сетей – флагманская линейка энтерпрайз класса или провайдерское оборудование.

Потребность в резервировании канала: высокая

Потребность в резервировании оборудования: высокая

Образовательные учреждения. Для образовательных учреждений характерно подключение к центру управления сетями. Объем трафика чаще всего не высокий. Требования к резервированию выставляются в редких случаях.

Медицинские учреждения. Для медицинских учреждений стоит острый вопрос надежности и высокой отказоустойчивости каналов связи и оборудования. Во всех филиалах территориально распределённой сети используются резервируемое каналообразующее оборудование и несколько провайдеров.

Решения для ритейла (сети магазинов). Сети магазинов отличаются массовостью локаций (это могут быть тысячи магазинов), и относительно не высоким трафиком до главного офиса (ЦОД). Резервирование оборудования в магазинах чаще всего не целесообразно. Достаточно зарезервировать подключение к провайдеру (в формате «второй провайдер на подхвате»). Однако требования к оборудованию, которое стоит в ЦОД (главном офисе) высокие. Так как эта точка терминирует на себе тысячи VPN туннелей. Необходим постоянный мониторинг каналов, системы отчетности, соблюдение политик безопасности, и т.д.

Внедрение распределенных VPN-сетей и корпоративных сетей передачи данных (КСПД)

Выбор необходимого оборудования и правильное внедрение сервиса – это сложная задача, требующая высокой экспертизы от исполнителя. Компания ЛанКей много лет выполняет сложнейшие проекты и имеет огромный опыт в подобных проектах.

Примеры некоторых проектов по внедрению КСПД и VPN, реализованных компанией ЛанКей

Производитель оборудования: Cisco
Решение: обеспечение подключения удаленных работников к ресурсам корпоративной сети по защищенным каналам с использованием технологии Cisco Anyconnect.

Производитель оборудования: Cisco
Решение: Объединение по защищенному туннелю корпоративной сети и облачных серверов для предоставления сотрудникам различных сервисов (почта, документооборот, телефония). Помимо этого решение позволяло подключаться к корпоративной сети и использовать облачные сервисы удаленным сотрудникам.

Производитель оборудования:Juniper
Решение: осуществлено подключение к сети интернет и построение VPN тунелей в офисах, находящихся в Москве и Женеве.

Сетевые решения

Беспроводные сети (Wi-Fi)
ЛВС
VPN

AVAYA
Cisco
Ericsson-LG
Panasonic
Агат-РТ
Nec
Ericsson
Audiocodes
Как выбирать АТС

AVAYA Unified Communication
Call-центры на основе АТС Panasonic
Создание единой корпоративной телефонной сети
DECT-системы, микросотовые сети

ВКС ВидеоМост
AVAYA Radvision
Polycom

Jabra

Что такое Mesh Wi-Fi?

Wi-Fi Mesh система для всего дома

На протяжении многих лет Mesh Wi-Fi использовался преимущественно в бизнесе, где безопасность сети критически важна. Недавно Mesh Wi-Fi стал доступен для обычных пользователей, благодаря чему у них появился доступ к безопасному высокоскоростному Wi-Fi с широким радиусом действия.

В этой статье мы расскажем, что такое Mesh Wi-Fi, для чего он нужен, и поделимся кое-какими полезными советами для начала работы.

Что такое Mesh Wi-Fi?
Кому пригодится Mesh Wi-Fi?
Каковы преимущества Mesh Wi-Fi?
Как работает Mesh Wi-Fi?
В чём разница между Mesh Wi-Fi и усилителями Wi-Fi сигнала?
Особенности Mesh Wi-Fi
Заключение
Часто задаваемые вопросы про Mesh Wi-Fi
Deco Mesh Wi-Fi vs. Google Wifi
Безопасность домашней сети с Deco Mesh Wi-Fi

Что такое Mesh Wi-Fi?

Mesh маршрутизаторы вокруг дома

Mesh Wi-Fi — это домашняя Wi-Fi система, созданная для устранения зон со слабым сигналом и обеспечения непрерывного покрытия Wi-Fi во всём доме.
Mesh-системы обеспечивают более высокую скорость, широкое покрытие и надёжное соединение для устройств, подключённых к сети. В то время как обычные роутеры раздают Wi-Fi из одной точки, у систем Mesh Wi-Fi их несколько.

Устройство, подключённое к модему, является основным (главным роутером или шлюзом). Остальные устройства (называемые «узлами») принимают и ретранслируют сигнал основного устройства. В результате получается эффективная Wi-Fi сеть с мощным сигналом, которая состоит из нескольких модулей.

Кому пригодится Mesh Wi-Fi?

Mesh Wi-Fi создан для тех, у кого дома слабое или неполное Wi-Fi покрытие, а также для тех, кому нужна несложная Wi-Fi система, которую легко настроить самому.

Поскольку у обычных роутеров зона вещания ограничена, зачастую они не могут полностью покрыть большие дома или дома с несколькими этажами. Если площадь дома составляет 280 кв. м, в нём два или более этажей, есть внутренние стены из кирпича или у него необычная планировка, тогда роутер с Mesh Wi-Fi не будет лишним.

Mesh Wi-Fi также отлично подойдёт для тех, кто заинтересован в мощной Wi-Fi системе, но не хочет возиться со сложной установкой и настройкой, требующимися для большинства обычных роутеров.

Каковы преимущества Mesh Wi-Fi?

У традиционных роутеров зона охвата ограничена. Добавление усилителя Wi-Fi сигнала может с этим помочь, однако взамен на подключение усилители Wi-Fi сигнала жертвуют скоростью, в то время как Mesh Wi-Fi сочетает в себе всё самое лучшее — высокую скорость и широкую зону охвата.

Одна сеть на весь дом

Два роутера Deco, обеспечивающих Mesh WiFi в нескольких точках дома

Mesh Wi-Fi роутер позволяет забыть о входе в новую сеть каждый раз, когда вы поднимаетесь на этаж выше, и не терять подключения к единой надёжной сети, где бы вы ни были. Умная технология Mesh позволяет оставаться в сети, даже когда один из Mesh-узлов (модулей) даёт сбой.

Стабильное подключение на большом расстоянии

На рисунке показано приложение Deco, показывающее, где разместить маршрутизатор

Mesh-роутер обеспечивает мощное и стабильное соединение во всём доме. Каждый модуль Mesh использует сигнал других узлов, поэтому Wi-Fi подключение будет одинаково хорошим как на чердаке, так и в подвале.

Простая настройка и управление

Mesh WiFi для нескольких устройств

Большинство Mesh-роутеров в продаже сегодня поддерживают простую установку и управление сетью, позволяя переключать настройки сети, проверять скорость и включать родительский контроль.

Управление умным домом

Как работает Mesh Wi-Fi?

Диаграмма Deco, показывающая продукты Deco с возможностями Mesh WiFi

Для создания Mesh Wi-Fi сети используется два или более модулей Mesh Wi-Fi. Один модуль подключается к интернету, а остальные размещаются по всему дому для создания мощной Wi-Fi сети. В отличие от стандартных роутеров, эти модули являются частью единой сети с одним SSID и паролем. Поэтому для настройки и расширения Mesh-сети достаточно просто добавлять новые модули.

Модули Mesh необходимы для эффективной работы Wi-Fi, поскольку они образуют последовательную цепочку с другими модулями в сети. Сигнал будет хорошим даже у самых отдалённых от роутера модулей. Модули взаимодействуют друг с другом для определения лучшего диапазона для ваших устройств, а также для перенаправления трафика в случае сбоя одного из модулей.

В чём разница между Mesh Wi-Fi и усилителями Wi-Fi сигнала?

Несмотря на то, что Mesh Wi-Fi и усилители Wi-Fi сигнала могут показаться одинаковыми по своей функции, есть некоторые ключевые различия.

У устройств Mesh Wi-Fi есть протоколы роуминга (чтобы вы оставались в одной сети при переключении между модулями) и Mesh-технологии, такие как самовосстановление (Self-Healing) и адаптивная маршрутизация, поддерживающие стабильность сети.

При использовании усилителей Wi-Fi сигнала для сохранения хорошего подключения при значительном отдалении от роутера происходит подключением к новой сети.

Большинство усилителей Wi-Fi вещают отдельные сети Wi-Fi — с Mesh-устройствами волноваться об этом не придётся. Каждый Mesh‑модуль, по сути, является роутером, в то время как усилители Wi-Fi сигнала просто дублируют сигнал основного роутера.

Wi-Fi сигнал Mesh Wi-Fi быстрее и эффективнее, чем сигнал усилителей Wi-Fi.

Примечание: хоть наш Deco M3 (3-pack) и использует Mesh-модули, похожие на усилители Wi-Fi сигнала, они не взаимозаменяемы. В работе этих Mesh-модулей используется схожая технология и логика для создания мощной Mesh Wi-Fi сети, которая усилителям Wi-Fi сигнала не по силам.

Особенности Mesh Wi-Fi

Одно имя. Один пароль

Диаграмма, показывающая роутер Deco, обеспечивающий высокоскоростной Wi-Fi для игровой системы

Mesh Wi-Fi позволяет подключаться к сети, используя одно имя сети и один пароль, чтобы пользоваться бесшовным Wi-Fi во всём доме.

Бесшовный роуминг

Бесшовный роуминг позволяет оставаться в сети независимо от того, где вы находитесь в доме. Переключение от одного Mesh‑узла к другому происходит настолько плавно, что это будет незаметно даже просмотре потокового или видеозвонке.

Адаптивная маршрутизация

Деко-роутер, демонстрирующий возможности самовосстановления

Mesh Wi-Fi роутеры используют адаптивную маршрутизацию для автоматического выбора наилучшего маршрута и частотного диапазона при передаче данных для сохранения постоянной максимально возможной скорости.

Самовосстановление (Self-Healing)

Заключение

С момента своего возникновения Mesh Wi-Fi далеко продвинулся и был восторженно принят потребителями за своё удобство, а также простоту использования и установки. Перейдите на страницу Mesh-устройств TP-Link, чтобы увидеть все Mesh-роутеры Deco.

Часто задаваемые вопросы про Mesh Wi-Fi

Нужно ли покупать новый роутер, чтобы пользоваться Mesh Wi-Fi?

Нет, не нужно! Для использования Mesh Wi-Fi можно бесплатно обновить прошивку имеющегося совместимого роутера TP-Link до OneMesh и выполнить сопряжение с совместимым Mesh-усилителем или Powerline-адаптерами.
Перейдите в раздел совместимых роутеров TP-Link, чтобы увидеть все подходящие модели.

Будет ли работать Mesh Wi-Fi, если в доме кирпичные или бетонные стены либо стены с нанесённой штукатуркой?

Да! Mesh Wi-Fi системы будут работать в домах с такими стенами. Однако из-за факторов окружающей среды качество подключения большинства роутеров (включая Mesh Wi-Fi роутеры) может упасть.
Если стены в доме слишком толстые, возможно, лучше использовать Powerline-адаптеры.

Работает ли Mesh Wi-Fi со старыми устройствами?

Где можно найти Mesh Wi-Fi устройства?

Mesh-устройства продаются в магазинах электроники: Ситилинк, Регард, DNS, Эльдорадо, М.Видео и т. д.

Продаёт ли TP-Link Mesh Wi-Fi устройства?

Да, продаём! Перейдите в раздел Mesh-устройств TP-Link, чтобы увидеть все наши Mesh-роутеры.

Наши самые популярные Mesh Wi-Fi устройства относятся к линейке устройств Deco. С нашими роутерами Deco вы сможете настроить сеть в считанные минуты, без труда управлять настройками сети через приложение, получить бесшовное покрытие во всём доме, а также воспользоваться всеми вышеперечисленными преимуществами.

Deco Mesh Wi-Fi vs. Google Wifi

У нас за спиной два десятка лет опыта работы в мировой сфере сетевых технологий, поэтому нам известен рецепт отличного Wi-Fi. Так что нет ничего удвительного в том, что Deco превосходит по производительности Google Wifi — как по зоне охвата, так и по скорости Wi-Fi***.

Deco
Google Wifi

Deco Mesh WiFi vs Google WiFi

Первый этаж
Второй этаж

Есть покрытие
Нет покрытия

Сравните статистику

Комната	Deco	Google Wifi
Гостиная	334,91 Мбит/с	173,86 Мбит/с
Домашний офис	1004,76 Мбит/с	795,11 Мбит/с
Спальня	394,60 Мбит/с	307,50 Мбит/с
Домашний кинотеатр	608,80 Мбит/с	365,62 Мбит/с

1. Согласно исследованию, проведённому в 2018 году компанией Allion USA в двухэтажном доме площадью 280 кв. м. Индивидуальные показатели могут варьироваться в зависимости от используемых в доме строительных материалов, планировки, условий сети, ограничений клиентов и помех.

Full mesh vpn что это

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

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

Описание tinc

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

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

Архитектура

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

Модуль начальной загрузки

Модуль распределения ключей

Модуль распределения ключей (управление)

Вместо итого

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

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

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

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

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

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

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

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

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

Описание tinc

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

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

Архитектура

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

Модуль начальной загрузки

Модуль распределения ключей

Модуль распределения ключей (управление)

Вместо итого

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

full mesh VPN между пятью сетями

Территориально-распределенные VPN-сети

Уникальные преимущества территориально распределенных VPN-сетей

VPN-сети в бизнесе

Сферы применения распределенных VPN-сетей и корпоративных сетей передачи данных (КСПД)

Внедрение распределенных VPN-сетей и корпоративных сетей передачи данных (КСПД)

Примеры некоторых проектов по внедрению КСПД и VPN, реализованных компанией ЛанКей

Что такое Mesh Wi-Fi?

Что такое Mesh Wi-Fi?

Кому пригодится Mesh Wi-Fi?

Каковы преимущества Mesh Wi-Fi?

Одна сеть на весь дом

Стабильное подключение на большом расстоянии

Простая настройка и управление

Управление умным домом

Как работает Mesh Wi-Fi?

В чём разница между Mesh Wi-Fi и усилителями Wi-Fi сигнала?

Особенности Mesh Wi-Fi

Одно имя. Один пароль

Бесшовный роуминг

Адаптивная маршрутизация

Самовосстановление (Self-Healing)

Заключение

Часто задаваемые вопросы про Mesh Wi-Fi

Нужно ли покупать новый роутер, чтобы пользоваться Mesh Wi-Fi?

Будет ли работать Mesh Wi-Fi, если в доме кирпичные или бетонные стены либо стены с нанесённой штукатуркой?

Работает ли Mesh Wi-Fi со старыми устройствами?

Где можно найти Mesh Wi-Fi устройства?

Продаёт ли TP-Link Mesh Wi-Fi устройства?

Deco Mesh Wi-Fi vs. Google Wifi

Добавить комментарий Отменить ответ