Документация Shadowsocks
Навигация
Формат конфигурации Shadowsocks
Файл конфигурации
Shadowsocks принимает конфигурации формата JSON:
{
«сервер»: «мой_сервер_ip»,
«Server_port»: 8388,
"Local_port": 1080,
«пароль»: «barfoo!»,
«метод»: «chacha20-ietf-poly1305»
}
Формат JSON
- сервер: ваше имя хоста или IP-адрес сервера (IPv4/IPv6).
- server_port: номер порта сервера.
- local_port: номер локального порта.
- пароль: пароль, используемый для шифрования передачи.
- метод: метод шифрования.
Метод шифрования
Мы настраиваем наши серверы и рекомендуем вам использовать шифр chacha20-ietf-poly1305 AEAD, так как это самый надежный метод шифрования.
Если вы настраиваете свой собственный сервер shadowsocks, вы можете выбрать «chacha20-ietf-poly1305» или «aes-256-gcm».
URI и QR-код
Shadowsocks для Android/IOS также принимает конфигурации формата URI в кодировке BASE64:
ss://BASE64-ENCODED-STRING-БЕЗ-PADDING#TAG
Простой URI должен быть: ss://method:password@hostname:port
Приведенный выше URI не соответствует RFC3986. Пароль в этом случае должен быть простым текстом, а не процентным кодированием.
Пример: мы используем сервер по адресу 192.168.100.1:8888. через бф-кфб метод шифрования и пароль тест/!@#:.
Затем с помощью простого URI сс://bf-cfb:тест/!@#:@192.168.100.1:8888, мы можем сгенерировать URI в кодировке BASE64:
> console.log("ss://" + btoa("bf-cfb:test/!@#:@192.168.100.1:8888"))
ss://YmYtY2ZiOnRlc3QvIUAjOkAxOTIuMTY4LjEwMC4xOjg4ODg
Чтобы упростить организацию и идентификацию этих URI, вы можете добавить тег после строки в кодировке BASE64:
ss://YmYtY2ZiOnRlc3QvIUAjOkAxOTIuMTY4LjEwMC4xOjg4ODg#example-server
адресация
Shadowsocks использует адреса, найденные в формате адресов SOCKS5:
[1-байтовый тип][хост переменной длины][2-байтовый порт]
Вот определенные типы адресов:
- 0x01 : хост — это 4-байтовый IPv4-адрес.
- 0x03 : хост представляет собой строку переменной длины, начинающуюся с 1-байтовой длины, за которой следует максимальное 255-байтовое доменное имя.
- 0x04 : хост — это 16-байтовый IPv6-адрес.
Номер порта представляет собой 2-байтовое целое число без знака с обратным порядком байтов.
TCP
Клиент ss-local инициирует соединение с ss-remote, отправляя зашифрованные данные, начиная с целевого адреса, за которыми следуют данные полезной нагрузки. Шифрование будет отличаться в зависимости от используемого шифра.
[целевой адрес][полезная нагрузка]
ss-remote получает зашифрованные данные, затем расшифровывает и анализирует целевой адрес. Затем он создает новое TCP-соединение с целью и пересылает ему данные полезной нагрузки. ss-remote получает ответ от цели, затем шифрует данные и пересылает их обратно в ss-local до тех пор, пока он не отключится.
В целях запутывания локальные и удаленные должны отправлять данные рукопожатия с некоторой полезной нагрузкой в первом пакете.
UDP
ss-local отправляет зашифрованный пакет данных, содержащий целевой адрес и полезную нагрузку, на ss-remote.
[целевой адрес][полезная нагрузка]
После получения зашифрованного пакета ss-remote расшифровывает и анализирует целевой адрес. Затем он отправляет новый пакет данных с полезной нагрузкой на цель. ss-remote получает пакеты данных от цели и добавляет адрес цели к полезной нагрузке в каждом пакете. Зашифрованные копии отправляются обратно в ss-local.
[целевой адрес][полезная нагрузка]
Этот процесс можно свести к тому, что ss-remote выполняет трансляцию сетевых адресов для ss-local.
