Протокол Shadowsocks

Не туннель, а прокси: в чём практическая разница

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

Для пользователя это и плюс, и минус. Плюс: браузер идёт через прокси, а банковское приложение и локальный принтер — напрямую, без единой строки правил маршрутизации. Минус: приложение, которое не умеет работать с прокси, просто пойдёт мимо, и вы об этом не узнаете.

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

AEAD и редакция 2022

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

Редакция 2022 пошла дальше. В неё добавили защиту от повторной отправки перехваченных пакетов, привязку ключа сессии к времени и вывод ключа через BLAKE3 вместо простого преобразования пароля. Схемы этой редакции узнаются по именам вида 2022-blake3-aes-256-gcm.

Практический вывод: старые схемы вроде aes-256-cfb использовать не стоит вовсе, а между обычным AEAD и редакцией 2022 разумно выбирать вторую. Разница в скорости в пределах 2%, разница в устойчивости к активной проверке — существенная.

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

Туннель на UDP сводит весь трафик устройства в один поток. Когда пакет теряется, восстановление задевает всё сразу: страница в браузере, загрузка файла и голосовой звонок останавливаются одновременно, хотя проблема касалась одного фрагмента.

Shadowsocks держит для каждого соединения приложения отдельный поток к серверу. Потеря пакета в загрузке файла никак не влияет на голосовой звонок — они физически не связаны. На мобильной сети с 3–6% потерь это ощущается как более ровная работа при формально меньшей пиковой скорости.

Обратная сторона — при сотнях одновременных соединений накладные расходы растут: каждый поток требует своего рукопожатия и своего заголовка. Браузер с двумя десятками вкладок легко открывает 200–300 соединений, и на слабом роутере это заметно по загрузке процессора.

Ограничения, о которых стоит знать заранее

Поток Shadowsocks выглядит как последовательность случайных байтов без узнаваемого начала. Это защищает от простых правил по сигнатуре, но создаёт другую проблему: в обычном интернет-трафике потоков без структуры почти не бывает. Отсутствие признаков само по себе является признаком.

Второе ограничение — модель ключа. Секрет один на всё соединение, отдельных пользователей и индивидуального отзыва в протоколе нет. Если пароль утёк, меняется он у всех сразу. Многопользовательские схемы решают это надстройками на стороне сервера.

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