Documentazione Shadowsocks

Formato di configurazione di Shadowsocks

File di configurazione

Shadowsocks accetta le configurazioni del formato JSON:

{

    “server”:”mio_server_ip”,

    "Server_port": 8388,

    "porta_locale": 1080,

    “password”:”barfoo!”,

    “metodo”:”chacha20-ietf-poly1305″

}

Formato JSON

  • server : il nome host o l'IP del server (IPv4/IPv6).
  • server_port: numero di porta del server.
  • local_port: numero di porta locale.
  • password: una password utilizzata per crittografare il trasferimento.
  • metodo: metodo di crittografia.

Metodo di crittografia

Configuriamo i nostri server e ti consigliamo di utilizzare il cifrario AEAD chacha20-ietf-poly1305 perché è il metodo di crittografia più efficace. 

Se configuri il tuo server shadowsocks, puoi scegliere tra "chacha20-ietf-poly1305" o "aes-256-gcm".

URI e codice QR

Shadowsocks per Android/IOS accetta anche le configurazioni del formato URI codificato BASE64:

ss://BASE64-STRINGA-CODIFICATA-SENZA-PADDING#TAG

 

L'URI semplice dovrebbe essere: ss://method:password@hostname:port

L'URI precedente non segue RFC3986. La password in questo caso deve essere in testo normale, non codificata in percentuale.



Esempio: stiamo utilizzando un server a 192.168.100.1:8888 utilizzando bf-cfb metodo di crittografia e password test/!@#:

 

Quindi, con il semplice URI ss://bf-cfb:prova/!@#:@192.168.100.1:8888, possiamo generare l'URI con codifica BASE64: 

 

> console.log( “ss://” + btoa(“bf-cfb:test/!@#:@192.168.100.1:8888”) )

ss://YmYtY2ZiOnRlc3QvIUAjOkAxOTIuMTY4LjEwMC4xOjg4ODg

 

Per aiutare a organizzare e identificare questi URI, puoi aggiungere un tag dopo la stringa codificata BASE64:

ss://YmYtY2ZiOnRlc3QvIUAjOkAxOTIuMTY4LjEwMC4xOjg4ODg#example-server

Indirizzamento

Shadowsocks utilizza gli indirizzi trovati nel formato di indirizzo SOCKS5:

[tipo a 1 byte][host a lunghezza variabile][porta a 2 byte]

 

Ecco i tipi di indirizzo definiti:

  • 0x01 : l'host è un indirizzo IPv4 a 4 byte.
  • 0x03 : host è una stringa di lunghezza variabile, che inizia con una lunghezza di 1 byte, seguita da un nome di dominio di massimo 255 byte.
  • 0x04 : l'host è un indirizzo IPv16 a 6 byte.

 

Il numero di porta è un numero intero senza segno big-endian a 2 byte.

TCP

Il client ss-local avvia una connessione a ss-remote inviando dati crittografati a partire dall'indirizzo di destinazione seguito dai dati del payload. La crittografia sarà diversa a seconda della crittografia utilizzata.

[indirizzo di destinazione][payload]

Il telecomando ss riceve i dati crittografati, quindi decrittografa e analizza l'indirizzo di destinazione. Quindi crea una nuova connessione TCP alla destinazione e le inoltra i dati del payload. ss-remote riceve una risposta dalla destinazione, quindi crittografa i dati e li inoltra nuovamente a ss-local finché non viene disconnesso.

Per scopi di offuscamento, locale e remoto dovrebbero inviare i dati di handshake con un certo carico utile nel primo pacchetto.

UDP

ss-local invia il pacchetto di dati crittografato contenente l'indirizzo di destinazione e il payload a ss-remote.

[indirizzo di destinazione][payload]

Una volta ricevuto il pacchetto crittografato, ss-remote decrittografa e analizza l'indirizzo di destinazione. Quindi invia un nuovo pacchetto di dati con il payload alla destinazione. ss-remote riceve i pacchetti di dati dalla destinazione e antepone l'indirizzo di destinazione al payload in ciascun pacchetto. Le copie crittografate vengono rispedite a ss-local.

[indirizzo di destinazione][payload]

Questo processo può essere ridotto a ss-remote che esegue una traduzione dell'indirizzo di rete per ss-local.

Inizia la tua prova gratuita di 5 giorni