Shadowsocks dokumentaro
Navigado
Shadowsocks Agorda Formato
Agorda Dosiero
Shadowsocks prenas JSON-formatajn agordojn:
{
"servilo":"mia_servilo_ip",
"Servila_haveno": 8388,
"loka_haveno":1080,
“pasvorto”:”barfoo!”,
"metodo":"chacha20-ietf-poly1305"
}
Formato JSON
- servilo: via gastiga nomo aŭ servila IP (IPv4/IPv6).
- server_port: numero de pordo de la servilo.
- local_port: loka havenonumero.
- pasvorto: pasvorto uzata por ĉifri translokigon.
- metodo: metodo de ĉifrado.
Ĉifrada Metodo
Ni agordas niajn servilojn kaj rekomendas ke vi uzu la chacha20-ietf-poly1305 AEAD-ĉifron ĉar ĝi estas la plej forta metodo de ĉifrado.
Se vi agordas vian propran shadowsocks-servilon, vi povas elekti aŭ "chacha20-ietf-poly1305" aŭ "aes-256-gcm".
URI & QR-kodo
Shadowsocks por Android / IOS ankaŭ prenas BASE64-kodigitajn URI-formatajn agordojn:
ss://BASE64-ENCODED-STRING-WITHOUT-PADDING#TAG
La simpla URI devus esti: ss://metodo:pasvorto@gastigantonomo:porto
La supra URI ne sekvas RFC3986. La pasvorto en ĉi tiu kazo devus esti simpla teksto, ne procente kodita.
Ekzemplo: Ni uzas servilon ĉe 192.168.100.1:8888 uzante bf-cfb ĉifrada metodo kaj pasvorto testo/!@#:.
Tiam, kun la simpla URI ss://bf-cfb:test/!@#:@192.168.100.1:8888, ni povas generi la BASE64-koditan URI:
> console.log( "ss://" + btoa ("bf-cfb:test/!@#:@192.168.100.1:8888"))
ss://YmYtY2ZiOnRlc3QvIUAjOkAxOTIuMTY4LjEwMC4xOjg4ODg
Por helpi organizi kaj identigi ĉi tiujn URIojn, vi povas aldoni etikedon post la kodita ĉeno BASE64:
ss://YmYtY2ZiOnRlc3QvIUAjOkAxOTIuMTY4LjEwMC4xOjg4ODg#example-server
Direkti
Shadowsocks uzas la adresojn trovitajn en la SOCKS5-adresformato:
[1-bajta tipo][variablelonga gastiganto][2-bajta haveno]
Jen la adresspecoj difinitaj:
- 0x01 : gastiganto estas 4-bajta IPv4-adreso.
- 0x03 : gastiganto estas variablolonga ĉeno, komencante per 1-bajta longo, sekvata de maksimuma 255-bajta domajna nomo.
- 0x04 : gastiganto estas 16-bajta IPv6-adreso.
La havennumero estas 2-bajta big-endian sensigna entjero.
TCP
La ss-loka kliento iniciatas konekton al ss-remote sendante ĉifritajn datumojn komencante kun la cela adreso sekvita per la utilŝarĝaj datumoj. La ĉifrado estos malsama depende de la ĉifro uzata.
[cela adreso][utila ŝarĝo]
La ss-remoto ricevas la ĉifritajn datumojn, tiam deĉifras kaj analizas la celan adreson. Tiam ĝi kreas novan TCP-konekton al la celo kaj plusendas la utilajn datumojn al ĝi. ss-remote ricevas respondon de la celo tiam ĉifras la datumojn kaj plusendas ĝin reen al ss-local ĝis ĝi estas malkonektita.
Por malklarigceloj, lokaj kaj malproksimaj devus sendi la manpremdatenojn kun iu utila ŝarĝo en la unua pako.
UDP
ss-local sendas la ĉifritan datumpakaĵon enhavantan la cel-adreson kaj utilan ŝarĝon al ss-remote.
[cela adreso][utila ŝarĝo]
Post kiam la ĉifrita pakaĵeto estas ricevita, ss-remote deĉifras kaj analizas la cel-adreson. Ĝi tiam sendas novan datumpakaĵon kun la utila ŝarĝo al la celo. ss-remote ricevas la datumpakaĵojn de la celo kaj antaŭmetas la celadreson al la utila ŝarĝo en ĉiu pakaĵeto. Ĉifritaj kopioj estas resenditaj al ss-local.
[cela adreso][utila ŝarĝo]
Ĉi tiu procezo povas esti resumita al ss-remote faranta retadrestradukon por ss-local.
