Dokumentacja Shadowsocks
Nawigacja
Format konfiguracji Shadowsocks
Plik konfiguracyjny
Shadowsocks przyjmuje konfiguracje formatu JSON:
{
„serwer”: „my_server_ip”,
„port_serwera”:8388,
„lokalny_port”:1080,
„hasło”: „barfu!”,
„metoda”: „chacha20-ietf-poly1305″
}
formacie JSON
- serwer : nazwa hosta lub adres IP serwera (IPv4/IPv6).
- server_port: numer portu serwera.
- local_port: numer portu lokalnego.
- hasło: hasło używane do szyfrowania transferu.
- metoda: metoda szyfrowania.
Metoda szyfrowania
Konfigurujemy nasze serwery i zalecamy korzystanie z szyfru AEAD chacha20-ietf-poly1305, ponieważ jest to najsilniejsza metoda szyfrowania.
Konfigurując własny serwer shadowsocks, możesz wybrać „chacha20-ietf-poly1305” lub „aes-256-gcm”.
URI i kod QR
Shadowsocks na Androida / IOS obsługuje również konfiguracje formatu URI zakodowane w BASE64:
ss://BASE64-ENCODED-STRING-BEZ-WYPEŁNIENIA#TAG
Zwykły identyfikator URI powinien mieć postać: ss://method:password@hostname:port
Powyższy identyfikator URI nie jest zgodny z RFC3986. Hasło w tym przypadku powinno być zwykłym tekstem, a nie zakodowanym procentowo.
Przykład: Używamy serwera pod adresem 192.168.100.1:8888 za pomocą bf-cfb sposób szyfrowania i hasło test/!@#:.
Następnie za pomocą zwykłego identyfikatora URI ss://bf-cfb:test/!@#:@192.168.100.1:8888, możemy wygenerować URI zakodowany w BASE64:
> console.log( „ss://” + btoa(„bf-cfb:test/!@#:@192.168.100.1:8888”) )
ss://YmYtY2ZiOnRlc3QvIUAjOkAxOTIuMTY4LjEwMC4xOjg4ODg
Aby ułatwić organizowanie i identyfikowanie tych identyfikatorów URI, możesz dołączyć tag po ciągu zakodowanym w BASE64:
ss://YmYtY2ZiOnRlc3QvIUAjOkAxOTIuMTY4LjEwMC4xOjg4ODg#example-server
Adresowanie
Shadowsocks używa adresów znalezionych w formacie adresu SOCKS5:
[typ 1-bajtowy][host o zmiennej długości][port 2-bajtowy]
Oto zdefiniowane typy adresów:
- 0x01 : host to 4-bajtowy adres IPv4.
- 0x03 : host to łańcuch o zmiennej długości, zaczynający się od długości 1 bajta, po którym następuje maksymalnie 255-bajtowa nazwa domeny.
- 0x04 : host to 16-bajtowy adres IPv6.
Numer portu to 2-bajtowa liczba całkowita bez znaku typu big-endian.
TCP
Klient ss-local inicjuje połączenie z ss-remote, wysyłając zaszyfrowane dane, zaczynając od adresu docelowego, po którym następują dane ładunku. Szyfrowanie będzie się różnić w zależności od użytego szyfru.
[adres docelowy][ładunek]
Pilot ss odbiera zaszyfrowane dane, a następnie odszyfrowuje i analizuje adres docelowy. Następnie tworzy nowe połączenie TCP z celem i przekazuje do niego dane ładunku. ss-remote otrzymuje odpowiedź od celu, a następnie szyfruje dane i przekazuje je z powrotem do ss-local, dopóki nie zostanie rozłączony.
W celu zaciemnienia, lokalni i zdalni powinni wysyłać dane uzgadniania z pewnym ładunkiem w pierwszym pakiecie.
UDP
ss-local wysyła zaszyfrowany pakiet danych zawierający adres docelowy i ładunek do ss-remote.
[adres docelowy][ładunek]
Po odebraniu zaszyfrowanego pakietu ss-remote odszyfrowuje i analizuje adres docelowy. Następnie wysyła nowy pakiet danych z ładunkiem do celu. ss-remote odbiera pakiety danych od celu i dołącza adres docelowy do ładunku w każdym pakiecie. Zaszyfrowane kopie są odsyłane z powrotem do ss-local.
[adres docelowy][ładunek]
Ten proces można sprowadzić do ss-remote wykonującego translację adresu sieciowego dla ss-local.
