Протокол SingLink 2.0

SingLink 2.0 — официальный сетевой транспортный протокол собственной разработки SingLinkVPN. Обозначение «2.0» указывает название и поколение протокола, а не версию клиентского приложения SingLinkVPN.

Протокол SingLink не только передаёт трафик на VPN-узел. Он также охватывает авторизацию учётной записи и узла, обработку DNS, интеллектуальную маршрутизацию, зашифрованные сеансы, инкапсуляцию TCP и UDP, проверку состояния соединения, смену сети и восстановление после сбоев.

Сейчас SingLink представлен рабочим протоколом SingLink 2.0 и предварительной версией SingLink Beta, ориентированной прежде всего на скорость. Во внутренних A/B-тестах стабильность SingLink 2.0 достигла 99,5%, а Beta — примерно 97%; при подходящих условиях сети и устройства пиковая скорость Beta превысила 1 Гбит/с.

Сравнение ключевых показателей: в заданной тестовой среде рабочая версия SingLink 2.0 продемонстрировала стабильность 99,5%. Beta достигла примерно 97%, но при подходящих условиях сети и устройства показала пиковую скорость свыше 1 Гбит/с. Эти результаты отражают разные приоритеты стабильности и скорости и не гарантируются для каждого устройства или сети.

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

Полные принципы работы протокола SingLink

Полную систему можно разделить на два контура:

Контур управления

Отвечает за:

• вход в учётную запись;

• проверку подписки;

• получение узлов;

• определение прав доступа к узлам;

• доставку конфигурации протокола;

• обновление правил;

• выбор Beta или 2.0.

Контур данных

Отвечает за:

• приём трафика приложений;

• разрешение DNS;

• установление защищённого соединения;

• инкапсуляцию и передачу TCP и UDP;

• поддержание соединения;

• обработку разрывов;

• возврат данных приложению.

Упрощённая последовательность выглядит так:

Пользователь входит в SingLinkVPN
        ↓
Получение разрешённых узлов и конфигурации протокола
        ↓
Клиент создаёт TUN / системный прокси
        ↓
Приём трафика приложений
        ↓
Проверка правил DNS и маршрутизации
        ↓
Выбор узла SingLink 2.0 или Beta
        ↓
Согласование возможностей протокола
        ↓
Проверка прав учётной записи и устройства
        ↓
Создание зашифрованного сеанса и сеансовых ключей
        ↓
Создание независимого логического потока для каждого соединения приложения
        ↓
Инкапсуляция данных TCP / UDP
        ↓
Отправка данных на узел SingLink
        ↓
Узел декапсулирует данные и обращается к целевому сайту
        ↓
Возврат данных и передача исходному приложению
        ↓
Непрерывное измерение задержки, потерь и состояния соединения
        ↓
Переподключение, восстановление или смена узла после сбоя

Этап 1: вход, получение узлов и конфигурации протокола

После запуска SingLinkVPN и входа пользователя клиент не должен немедленно и навсегда сохранять на устройстве адреса всех рабочих узлов, учётные данные и параметры протокола.

Более подходящая последовательность:

1. Клиент отправляет данные учётной записи.

2. Система учётных записей проверяет пользователя.

3. Система подтверждает тариф и права доступа к узлам.

4. Она возвращает доступные пользователю узлы.

5. Она возвращает краткосрочные данные для подключения.

6. Она возвращает текущую версию протокола и необходимую конфигурацию.

7. Клиент проверяет целостность конфигурации.

8. Конфиденциальная конфигурация сохраняется в защищённом системном хранилище.

Этот уровень главным образом определяет:

• действует ли подписка пользователя;

• доступны ли Beta или 2.0;

• имеет ли учётная запись права Pro, Max или Rich;

• какие страны и узлы доступны;

• истёк ли срок действия конфигурации;

• требуется ли обновить клиент.

Простое объяснение

Это похоже на проверку перед посадкой в скоростной поезд:

• кто вы;

• билет какого класса вы приобрели;

• на какой рейс вам разрешено сесть;

• остаётся ли билет действительным.

Рекомендуемые правила безопасности

SingLink не должен бессрочно полагаться на один постоянный статический пароль.

Более подходящая схема использует:

• краткосрочный токен подключения;

• одноразовый запрос;

• nonce устройства;

• ограничение срока действия;

• подписанную сервером конфигурацию узлов;

• механизм отзыва.

Тогда получение одной конфигурации подключения не предоставит постоянный доступ.

Этап 2: создание системной точки входа в сеть

Когда пользователь выбирает «Подключиться», SingLinkVPN сначала должен создать точку входа в сеть операционной системы.

Способ зависит от платформы:

После её создания данные, которые приложения обычно отправляли бы непосредственно в сеть, сначала поступают в клиент SingLinkVPN.

Например:

Приложение ChatGPT
    ↓
Сетевой стек операционной системы
    ↓
Интерфейс SingLink TUN
    ↓
Клиент SingLinkVPN

На этом этапе клиенту необходимо:

• создать виртуальный IP-адрес;

• настроить таблицу маршрутов;

• настроить DNS;

• исключить локальную сеть;

• не допустить возврата прокси-соединения в TUN.

Последний пункт особенно важен.

Без исключения маршрута трафик, посредством которого SingLinkVPN обращается к своему узлу, может сам вернуться в VPN и образовать цикл:

VPN-трафик
↓
Снова входит в VPN
↓
Повторно инкапсулируется
↓
Бесконечный цикл

Поэтому клиент должен явно исключить:

• собственный IP-адрес узла;

• необходимые интерфейсы управления;

• локальный шлюз;

• службы, к которым система должна обращаться напрямую.

Этап 3: разрешение DNS и проверка домена

Когда пользователь открывает chatgpt.com, устройству обычно сначала необходимо преобразовать доменное имя в IP-адрес.

Неправильная обработка DNS может привести к тому, что:

• DNS-запросы пойдут напрямую через локальную сеть;

• локальный DNS-резолвер вернёт неверный адрес;

• правила утратят исходный контекст домена;

• IPv6-трафик обойдёт VPN;

• утечка DNS сохранится, хотя VPN выглядит подключённым.

Клиент SingLink может использовать такую последовательность:

Приложение отправляет DNS-запрос
        ↓
Клиент перехватывает DNS
        ↓
Проверка правил домена
        ↓
Выбор локального DNS или защищённого удалённого DNS
        ↓
Получение результата IPv4 / IPv6
        ↓
Связывание домена с IP-адресом
        ↓
Выбор прямого доступа, прокси или блокировки

Локальные домены

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

Домены через прокси

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

Простое объяснение

DNS похож на поиск адреса.

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

Поэтому система протокола SingLink должна определять:

• перехватывает ли клиент DNS;

• какие DNS-запросы идут напрямую;

• какие DNS-запросы используют VPN;

• как обрабатываются IPv4 и IPv6;

• как долго кэшируются результаты DNS;

• удаляются ли устаревшие результаты DNS после смены сети.

Этап 4: интеллектуальная маршрутизация и выбор маршрута

После поступления DNS-запросов и трафика приложений клиент должен решить, как их обрабатывать.

Обычно существует три результата:

Напрямую
Через прокси
Блокировка

Напрямую

Трафик использует локальную сеть и не входит в туннель SingLink.

Подходит для:

• устройств локальной сети;

• местных сайтов;

• приложений, которым не нужен прокси;

• заданных пользователем списков разрешений.

Через прокси

Трафик поступает в протокол SingLink и перенаправляется узлом.

Подходит для:

• зарубежных сайтов;

• инструментов ИИ;

• международных социальных платформ;

• выбранных пользователем приложений.

Блокировка

Соединение отклоняется.

Подходит для:

• рекламных доменов;

• доменов отслеживания;

• вредоносных адресов;

• заданных пользователем списков блокировки.

Решение может учитывать:

• домен;

• IP-адрес;

• порт;

• приложение;

• географическое положение;

• тип протокола;

• пользовательские правила;

• глобальный режим или режим правил.

Простое объяснение

Этот этап напоминает организацию дорожного движения:

• местный транспорт едет по обычным дорогам;

• зарубежный транспорт въезжает на зашифрованную скоростную магистраль;

• опасному транспорту въезд запрещён.

Этап 5: выбор узла и протокола

Когда определено, что трафик должен идти через прокси, клиенту необходимо выбрать узел.

Выбор не может основываться только на названии страны. Следует также учитывать:

• тариф пользователя;

• использует ли узел 2.0 или Beta;

• находится ли узел в сети;

• задержку;

• потерю пакетов;

• нагрузку;

• расстояние до узла;

• местного оператора;

• местоположение назначения;

• поддержку UDP;

• совместимость клиента.

Ручной выбор

Пользователь выбирает узел в Японии, США, Сингапуре или другом месте.

Интеллектуальный выбор

Клиент выбирает подходящий узел по результатам проверок.

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

Например:

Хотя задержка у A ниже, потери и нагрузка высоки; при реальном использовании B может оказаться стабильнее.

Поэтому интеллектуальный выбор должен сочетать:

Задержка + потери + доля успешных подключений + нагрузка + предыдущие показатели

Этап 6: согласование возможностей протокола

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

Сначала необходимо согласовать возможности.

Согласовываться могут:

• версия SingLink;

• Beta или 2.0;

• поддержка TCP;

• поддержка UDP;

• IPv4 / IPv6;

• поддержка возобновления сеанса;

• поддержка мультиплексирования;

• максимальный размер кадра данных;

• стратегия Padding;

• интервал heartbeat;

• включение сжатия;

• размер MTU;

• поддержка повторного согласования.

Например:

Клиент:
Я поддерживаю SingLink 2.0
Я поддерживаю TCP, UDP и IPv6
Я поддерживаю Session Resume
Максимальный кадр: 64 КБ

Сервер:
Подтверждено использование SingLink 2.0
TCP и UDP доступны
Session Resume доступен
Фактический максимальный кадр: 32 КБ

В итоге стороны используют только взаимно поддерживаемые возможности.

Зачем требуется согласование?

Клиенты и узлы могут обновляться не в один день.

Если новый клиент отправит формат, который старый узел не распознаёт, соединение завершится сбоем.

В рабочей версии 2.0 по сравнению с Beta следует уделить больше внимания:

• обратной совместимости;

• откату версии;

• безопасному снижению функциональности при недоступности функции;

• явному отклонению несовместимых версий.

Этап 7: проверка личности

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

Рекомендуемые данные для проверки:

• краткосрочный токен;

• идентификатор учётной записи или авторизации;

• nonce клиента;

• версия протокола;

• идентификатор узла;

• запрошенные возможности;

• данные проверки целостности.

Упрощённый пакет аутентификации сообщает:

Кто я
Какой узел мне нужен
Какой протокол мне нужен
Случайный идентификатор этого соединения
Когда истекает срок моей авторизации
Были ли изменены данные

Серверу необходимо проверить:

1. был ли токен официально выдан;

2. не истёк ли срок действия токена;

3. не был ли токен отозван;

4. имеет ли пользователь доступ к узлу;

5. использовался ли nonce ранее;

6. не является ли запрос повторным воспроизведением;

7. разрешено ли этой версии клиента подключаться.

Защита от повторного воспроизведения

Злоумышленник может записать действительные данные аутентификации и повторно отправить их без изменений.

Поэтому данные аутентификации должны включать:

• одноразовый nonce;

• запрос сервера;

• короткий срок действия;

• запись об использованных учётных данных;

• привязку к сеансу.

Простыми словами:

Уже проверенный билет нельзя скопировать и повторно использовать без ограничений.

Этап 8: обмен ключами и зашифрованный сеанс

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

Рекомендуемая логика:

Клиент создаёт эфемерный ключ
        ↓
Сервер создаёт эфемерный ключ
        ↓
Обе стороны обмениваются открытыми данными
        ↓
Каждая сторона независимо вычисляет общий секрет
        ↓
Из общего секрета выводится несколько сеансовых ключей

Отдельные ключи следует выводить для:

• шифрования от клиента к серверу;

• шифрования от сервера к клиенту;

• обеспечения целостности данных;

• восстановления сеанса;

• защиты заголовков.

Не следует использовать один ключ для всех направлений и назначений.

Прямая секретность

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

Если постоянный ключ сервера утечёт позднее, это не должно позволить напрямую расшифровать все записанные ранее соединения.

Ротация ключей

Длительное соединение не должно бессрочно использовать один набор сеансовых ключей.

Ключи можно выводить заново с учётом:

• объёма переданных данных;

• продолжительности соединения;

• количества кадров;

• указания сервера.

Когда срабатывает одно из этих условий, соединение переходит на новые ключи.

Например:

После заданного количества ГБ
или
по истечении заданного периода
вывести новые ключи для каждого направления

Точные пороговые значения определяются по результатам тестов производительности и безопасности.

Этап 9: создание Session

После установления личности и ключей обе стороны создают SingLink Session.

Session может содержать:

• Session ID;

• версию протокола;

• параметры шифрования;

• максимальный размер кадра;

• интервал heartbeat;

• режим UDP;

• ограничение Stream;

• тайм-аут бездействия;

• возможность восстановления сеанса;

• политику Beta или 2.0.

Сервер возвращает подтверждение:

Личность подтверждена
Session установлен
Используется SingLink 2.0
TCP доступен
UDP доступен
Мультиплексирование доступно
Heartbeat включён

Клиент должен отправлять данные приложений только после получения подтверждения сервера.

Этап 10: создание Stream или независимого прокси-соединения

На этом этапе применяются две распространённые архитектуры:

Вариант 1: один Session переносит несколько Streams

Это напоминает подход AnyTLS:

SingLink Session
├─ Stream 1: ChatGPT
├─ Stream 2: YouTube
├─ Stream 3: Telegram
└─ Stream 4: браузер

Каждому Stream необходимы:

• Stream ID;

• адрес назначения;

• порт назначения;

• TCP или UDP;

• текущее состояние;

• окно отправки;

• окно приёма.

Преимущества:

• меньше повторных рукопожатий;

• ниже задержка подключения;

• меньше базовых соединений;

• эффективная обработка множества коротких соединений.

Риски:

• сбой одного Session может затронуть несколько Streams;

• одно базовое TCP-соединение может вызвать блокировку начала очереди;

• требуется полноценное управление потоком.

Вариант 2: каждый запрос приложения создаёт независимое соединение

ChatGPT → независимое соединение
YouTube → независимое соединение
Telegram → независимое соединение

Преимущества:

• разные потоки трафика изолированы;

• сбой одного соединения не влияет на остальные;

• более простая логика.

Недостатки:

• больше рукопожатий;

• выше накладные расходы на соединения;

• ниже эффективность при множестве коротких соединений.

Рекомендация

SingLink может использовать гибридный режим:

• мультиплексировать короткие соединения и обычный веб-трафик через Session;

• создавать независимые каналы для крупных загрузок и видео;

• отдельно обрабатывать UDP с низкой задержкой;

• не позволять одной высокоскоростной загрузке занять все Streams.

Этап 11: инкапсуляция кадров данных

Данные приложений нельзя без изменений помещать в транспортный канал. Их необходимо инкапсулировать в кадры протокола.

Концептуальный кадр SingLink может содержать:

Версия
Тип кадра
Session ID
Stream ID
Порядковый номер
Флаги
Длина данных
Зашифрованные данные
Тег целостности

Возможные типы кадров:

Это рекомендация по проектированию протокола. Она не утверждает, что SingLink сейчас использует такие названия или битовые форматы.

Этап 12: обработка TCP-трафика

Для TCP-соединений, таких как сайты, API и загрузка файлов, SingLink должен сохранять:

• порядок данных;

• двунаправленную передачу;

• состояние закрытия;

• управление потоком;

• состояние ошибки.

Полная последовательность может выглядеть так:

Приложение создаёт TCP-соединение
        ↓
Клиент создаёт SingLink Stream
        ↓
Отправка домена и порта назначения
        ↓
Узел подключается к целевому сайту
        ↓
Узел сообщает об успехе или сбое
        ↓
Начинается двунаправленная пересылка

Нормальное закрытие

Когда приложение завершает соединение:

1. Клиент отправляет FIN.

2. Узел прекращает принимать данные в этом направлении.

3. Он ожидает завершения передачи в другом направлении.

4. Stream полностью закрывается.

5. Память и состояние соединения освобождаются.

Аварийное закрытие

Если назначение отклоняет соединение:

1. Узел возвращает ошибку.

2. Клиент сообщает приложению о сбое подключения.

3. Stream немедленно очищается.

4. Остальные Streams не затрагиваются.

Этап 13: обработка UDP-трафика

У UDP нет обычного TCP-соединения. Для каждой дейтаграммы необходимо сохранять:

• связь с источником;

• адрес назначения;

• порт назначения;

• длину данных;

• границу дейтаграммы;

• тайм-аут связи.

Например:

UDP Association ID
Адрес назначения
Порт назначения
Длина данных
Полезная нагрузка UDP

SingLink необходимо явно выбрать один из следующих подходов:

UDP через TCP

Дейтаграммы UDP передаются внутри TCP или надёжного Session.

Преимущества:

• проще проходить через сети, разрешающие только TCP;

• ниже вероятность потери данных;

• проще развёртывание.

Недостатки:

• потеря TCP блокирует последующие данные UDP;

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

Нативный UDP

UDP передаёт данные напрямую.

Преимущества:

• низкая задержка;

• подходит для игр, голосовой связи и QUIC;

• не подвержен блокировке начала очереди TCP.

Недостатки:

• некоторые сети ограничивают UDP;

• обработка NAT и межсетевых экранов сложнее.

Транспорт в стиле QUIC

Он основан на UDP, но предоставляет на уровне протокола:

• шифрование;

• повторную передачу;

• несколько Streams;

• управление перегрузкой;

• миграцию между сетями.

Он обеспечивает более полные технические возможности, но сложнее в реализации.

Разумным направлением для SingLink будет:

Автоматически выбирать нативный UDP, надёжную инкапсуляцию или другой совместимый режим в зависимости от сети и типа трафика.

Этап 14: управление потоком и обратное давление

Предположим, YouTube быстро загружает данные, а ChatGPT передаёт лишь небольшие объёмы текста.

Без управления потоком видео-Stream может заполнить канал и вызвать:

• замедление ответов ChatGPT;

• задержку DNS;

• зависание приложений;

• непрерывный рост потребления памяти.

Поэтому требуется два уровня управления потоком:

Уровень Session

Ограничивает объём неподтверждённых данных, который может переносить весь Session.

Уровень Stream

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

Простыми словами:

Один большой грузовик не может занять все полосы скоростной магистрали. Каждому Stream необходимо справедливое распределение транспортных ресурсов.

Рабочий протокол 2.0 может использовать более консервативное планирование, чем Beta, чтобы погоня за пиковой скоростью не нарушала работу других соединений.

Этап 15: сегментация, Padding и внешний вид трафика

Даже после шифрования данных наблюдатель может видеть:

• длину пакетов;

• интервалы отправки;

• продолжительность соединения;

• соотношение исходящего и входящего трафика;

• поведение при переподключении.

Поэтому протокол может изменять внешний вид трафика, например:

• разделять крупные данные на несколько кадров;

• объединять небольшие данные;

• добавлять переменный Padding;

• корректировать пакеты отправки;

• избегать одной фиксированной длины рукопожатия;

• периодически обновлять стратегию Padding.

Но важно понимать:

Padding не заменяет шифрование и не может гарантировать, что трафик всегда останется нераспознаваемым.

Избыточный Padding также приводит к:

• увеличению трафика;

• росту задержки;

• повышению нагрузки на процессор;

• напрасному расходованию лимита бесплатного тарифа.

Поэтому профиль 2.0 может адаптироваться:

• использовать низкие накладные расходы в обычных сетях;

• усиливать обработку внешнего вида в особых сетевых средах;

• сокращать ненужный Padding при высокоскоростной загрузке;

• применять подходящее заполнение к небольшим управляющим данным.

В Beta, напротив, дополнительные накладные расходы могут быть сокращены ради повышения пиковой скорости.

Этап 16: обработка MTU и размера пакетов

Добавление заголовков протокола и зашифрованных данных к TUN-трафику увеличивает размер пакета.

Превышение сетевого MTU может вызвать:

• фрагментацию IP;

• потерю пакетов;

• невозможность открыть сайты;

• нестабильную скорость;

• ситуацию, когда VPN подключён, но данные не передаются.

SingLink необходимо:

1. определить MTU TUN;

2. вычесть заголовки протокола;

3. вычесть накладные расходы шифрования;

4. учесть IPv4 и IPv6;

5. при необходимости разделить данные;

6. избегать ненужной фрагментации IP.

Именно поэтому один фиксированный размер пакета не подходит для всех сетей.

Рабочая версия 2.0 должна обеспечивать более полную межплатформенную совместимость MTU. Если Beta использует более агрессивные крупные кадры, в некоторых сетях она может работать быстрее, но быть менее стабильной в нестандартных сетях.

Этап 17: обработка задержки, потерь и перегрузки

Клиенту необходимо непрерывно отслеживать:

• задержку RTT;

• джиттер;

• потерю пакетов;

• скорость отправки;

• скорость приёма;

• неподтверждённые данные;

• ответ узла.

Нельзя полагаться на один Ping.

Например:

Норма: 60 мс
Временное увеличение: 120 мс
Устойчивое увеличение: 500 мс
Нет ответа: тайм-аут

Разные ситуации требуют разной обработки:

Переподключение после потери одного пакета сделало бы протокол менее стабильным.

Этап 18: heartbeat и проверка состояния

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

Можно использовать:

PING
↓
PONG

Heartbeat не должны быть слишком частыми.

Избыточная частота:

• расходует заряд аккумулятора;

• потребляет трафик;

• повышает нагрузку на сервер;

• создаёт постоянный временной признак.

Недостаточная частота:

• задерживает обнаружение отказавшего узла;

• заставляет приложения ждать дольше;

• замедляет восстановление после смены сети.

Поэтому частота heartbeat может адаптироваться к состоянию:

• при наличии обычного трафика не добавлять heartbeat;

• после периода бездействия начать редкие heartbeat;

• после смены сети временно участить проверки;

• после повторных сбоев отметить соединение как прерванное.

Этап 19: смена сети и восстановление сеанса

Когда телефон переключается с Wi-Fi на 5G, исходное соединение обычно становится недействительным.

Полная обработка должна выглядеть так:

Обнаружение смены сети
        ↓
Прекращение отправки новых данных через отказавший канал
        ↓
Получение нового локального IP-адреса и маршрута
        ↓
Повторное подключение к исходному узлу
        ↓
Отправка данных для восстановления сеанса
        ↓
Сервер проверяет прежний Session
        ↓
Восстановление логических Streams, которые можно восстановить
        ↓
Указание приложениям пересоздать TCP-соединения, которые восстановить нельзя

Важное ограничение:

Не каждое TCP-соединение приложения можно восстановить незаметно.

Протокол может восстановить:

• состояние Session;

• авторизацию узла;

• параметры протокола;

• некоторые Streams, состояние которых остаётся действительным.

Но если собственное TCP-соединение целевого сайта завершилось, приложению всё равно может потребоваться переподключение.

Поэтому мы не утверждаем:

Каждое приложение всегда переживёт смену сети без каких-либо перебоев.

Точнее будет сказать:

SingLink 2.0 сокращает время переподключения, восстанавливает состояние протокола и маршрутизации и стремится свести влияние на приложения к минимуму.

Этап 20: отказ узла и автоматическое переключение

Сбои узла можно разделить на:

Мягкий сбой

• рост задержки;

• периодическая потеря пакетов;

• временное отсутствие ответа;

• недоступность отдельных назначений.

Обработка:

• немного подождать;

• снизить нагрузку передачи;

• повторить измерение;

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

Жёсткий сбой

• узел недоступен;

• интерфейс аутентификации недоступен;

• продолжительный тайм-аут;

• узел выведен из эксплуатации.

Обработка:

1. Прекратить использовать исходный узел.

2. Выбрать альтернативу из списка доступных узлов.

3. Установить новый защищённый Session.

4. Восстановить DNS и маршруты.

5. Указать приложениям пересоздать необходимые соединения.

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

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

Этап 21: возврат данных и декапсуляция

Ответ целевого сайта проходит следующий путь:

Целевой сайт возвращает данные
        ↓
Узел SingLink принимает их
        ↓
Поиск соответствующих Session и Stream
        ↓
Инкапсуляция в кадр данных SingLink
        ↓
Шифрование и отправка клиенту
        ↓
Клиент проверяет целостность
        ↓
Расшифрование
        ↓
Демультиплексирование по Stream ID
        ↓
Запись в TUN или системный прокси
        ↓
Возврат исходному приложению

Клиенту необходимо проверить:

• не были ли изменены данные;

• верны ли порядковые номера;

• не является ли кадр дубликатом;

• существует ли ещё Stream;

• находится ли длина в допустимых пределах;

• не превышено ли окно приёма.

Недействительные данные нельзя передавать приложению напрямую.

Этап 22: нормальное отключение и безопасная очистка

Когда пользователь выбирает «Отключиться», клиент должен:

1. прекратить принимать новый трафик через прокси;

2. нормально закрыть активные Streams;

3. отправить узлу команду завершения Session;

4. удалить сеансовые ключи;

5. отозвать или удалить краткосрочные токены;

6. закрыть TUN;

7. восстановить системные маршруты;

8. восстановить DNS;

9. удалить ненужную временную конфигурацию.

Если клиент аварийно завершит работу, операционная система или следующий запуск также должны предусматривать процедуру восстановления, чтобы не оставить:

• недействительный системный прокси;

• неправильный DNS;

• остаточные маршруты;

• отсутствие доступа к интернету.

Подробные различия стратегий SingLink Beta и 2.0

В таблице ниже кратко описано техническое позиционирование SingLink Beta и SingLink 2.0.

Полный принцип обработки в одном абзаце

Сначала клиент SingLink берёт под контроль трафик устройства и выполняет обработку DNS, интеллектуальную маршрутизацию и выбор узла. Затем он проверяет права учётной записи и доступ к узлу, согласовывает с узлом возможности протокола и устанавливает временные ключи шифрования. После создания соединения TCP- и UDP-трафик каждого приложения инкапсулируется в независимое прокси-соединение или логический Stream и по защищённому каналу передаётся узлу, который обращается к целевому сайту. Во время передачи система непрерывно управляет окнами потоков, целостностью данных, задержкой, потерей пакетов, heartbeat и состоянием узла. При смене сети или отказе узла она заново устанавливает Session, восстанавливает маршруты или переключается на доступный узел.

Главное различие между Beta и 2.0:

SingLink Beta агрессивнее стремится к пиковой скорости. SingLink 2.0 сохраняет высокую скорость передачи, одновременно предоставляя более полную совместимость, проверку состояния, классификацию сбоев, восстановление сеанса и межплатформенную обработку, благодаря чему достигается более высокая стабильность.

Часто задаваемые вопросы

Что такое SingLink 2.0?

SingLink 2.0 — официальный сетевой транспортный протокол, разработанный SingLinkVPN. Он выполняет проверку личности, устанавливает зашифрованные сеансы, инкапсулирует трафик, передаёт TCP и UDP, проверяет состояние соединения и восстанавливается после сбоев.

Является ли SingLink 2.0 версией приложения?

Нет. SingLink 2.0 — официальное название протокола. Версии клиентов для Windows, macOS, Android и iOS используют отдельную систему нумерации.

В чём разница между SingLink Beta и 2.0?

Beta — предварительная версия протокола с приоритетом скорости, пиковая скорость которой в подходящих условиях может превышать 1 Гбит/с. 2.0 — рабочий протокол, уделяющий особое внимание скорости, стабильности, межплатформенной совместимости и восстановлению после разрыва соединения.

Какова стабильность SingLink 2.0?

Во внутреннем A/B-тесте SingLinkVPN при заданных условиях стабильность SingLink 2.0 достигла 99,5%, а Beta — примерно 97%.

Как SingLink обрабатывает сетевой трафик?

Сначала клиент берёт под контроль системный трафик, обрабатывает DNS и выполняет интеллектуальную маршрутизацию. Затем он проверяет права учётной записи и доступ к узлу, устанавливает зашифрованный Session, инкапсулирует данные TCP или UDP и отправляет их узлу.

Как SingLink обрабатывает разрывы соединения?

Система непрерывно проверяет задержку, потерю пакетов, heartbeat и состояние узла. После сбоя она может заново установить Session, восстановить маршруты или переключиться на доступный узел.

Чем SingLink отличается от VLESS?

VLESS главным образом определяет идентификацию, команды и перенаправление к назначению. SingLink объединяет идентификацию, маршрутизацию, права доступа к узлам, транспортную политику, проверку состояния и восстановление после сбоев в более широкой системе протокола.

Чем SingLink отличается от AnyTLS?

AnyTLS в основном переносит Session и несколько Streams через TLS-соединение. Роль SingLink в продукте шире: она также охватывает интеллектуальную маршрутизацию, права подписки, планирование узлов и восстановление соединения. Фактическая реализация Session и Stream должна быть подтверждена официальной технической документацией.

Кто может использовать SingLink 2.0?

Рабочие узлы протокола SingLink 2.0 доступны на тарифах Pro, Max и Rich. Протокол Beta доступен на всех тарифах, включая бесплатный план. Фактические права следует проверять по данным последней версии клиента.

Полностью ли открыт исходный код SingLink 2.0?

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

Источники и дополнительные материалы

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

Дополнительные материалы: полное руководство по бесплатному тарифу SingLinkVPN, план открытия исходного кода SingLinkVPN и отчёт об аудите безопасности SingLinkVPN за 2026 год.

Техническое примечание: показатели 99,5%, примерно 97% и свыше 1 Гбит/с представляют собой соответственно внутренние результаты A/B-тестов стабильности и результаты измерения пиковой пропускной способности при заданных условиях. Они не означают, что в каждом регионе, на каждом устройстве, у каждого оператора, в каждой сети или в любое время результат будет одинаковым. Конкретные алгоритмы шифрования, форматы пакетов, механизмы Session и Stream должны быть подтверждены будущими официальными техническими документами SingLink и опубликованным исходным кодом.