Документация на Shadowsocks
навигация
Конфигурационен формат на Shadowsocks
Конфигурационен файл
Shadowsocks приема конфигурации на JSON формат:
{
“сървър”:”моят_сървър_ip”,
"Server_port": 8388,
"Local_port": 1080,
“парола”:”барфу!”,
„метод“: „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-КОДИРАН-НИЗ-БЕЗ-ПАДИНГ#ТАГ
Обикновеният URI трябва да бъде: ss://method:password@hostname:port
Горният URI не следва RFC3986. Паролата в този случай трябва да е обикновен текст, а не процентно кодирана.
Пример: Използваме сървър на 192.168.100.1:8888 използвайки bf-cfb метод на криптиране и парола тест/!@#:.
След това с обикновения URI ss://bf-cfb:тест/!@#:@192.168.100.1:8888, можем да генерираме BASE64 кодиран URI:
> 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.
