Документація Shadowsocks
навігація
Формат конфігурації Shadowsocks
Файл налаштування
Shadowsocks приймає конфігурації формату JSON:
{
“server”:”my_server_ip”,
«порт_сервера»:8388,
“local_port”:1080,
“password”:”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-WITHOUT-PADDING#TAG
Звичайний URI має бути таким: ss://method:password@hostname:port
Наведений вище URI не відповідає RFC3986. Пароль у цьому випадку має бути простим текстом, а не у відсотковому кодуванні.
Приклад: ми використовуємо сервер за адресою 192.168.100.1:8888 використання bf-cfb метод шифрування та пароль тест/!@#:.
Потім за допомогою простого URI ss://bf-cfb:test/!@#:@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.
