You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

172 lines
7.1 KiB

  1. Skip to [recipes](#recipes) for quick setup instructions
  2. # components
  3. `ss-local` provides SOCKS5 proxy with UDP associate support.
  4. socks5 ss plain
  5. --------> tcp:local_address:local_port ----> ss server -------> dest
  6. `ss-redir`. The REDIRECT and TPROXY part are to be provided by `ss-rules` script. REDIRECT is for tcp traffic (`SO_ORIGINAL_DST` only supports TCP). TPROXY is for udp messages, but it's only available in the PREROUTING chain and as such cannot proxy local out traffic.
  7. plain plain ss plain
  8. ---------> REDIRECT ------> tcp:local_address:local_port ----> ss server -----> original dest
  9. plain plain ss plain
  10. ---------> TPROXY -------> udp:local_address:local_port -----> ss server -----> original dest
  11. `ss-tunnel` provides ssh `-L` local-forwarding-like tunnel. Typically it's used to tunnel DNS traffic to the remote.
  12. plain ss plain
  13. ---------> tcp|udp:local_address:local_port ------> ss server -------> tunnel_address
  14. `ss-server`, the "ss server" in the above diagram
  15. # uci
  16. Option names are the same as those used in json config files. Check `validate_xxx` func definition of the [service script](files/shadowsocks-libev.init) and shadowsocks-libev's own documentation for supported options and expected value types. A [sample config file](files/shadowsocks-libev.config) is also provided for reference.
  17. Every section have a `disabled` option to temporarily turn off the component instance or component instances referring to it.
  18. Section type `server` is for definition of remote shadowsocks servers. They will be referred to from other component sections and as such should be named (as compared to anonymous section).
  19. Section type `ss_local`, `ss_redir`, `ss_tunnel` are for specification of shadowsocks-libev components. They share mostly a common set of options like `local_port`, `verbose`, `fast_open`, `timeout`, etc.
  20. We can have multiple instances of component and `server` sections. The relationship between them is many-to-one. This will have the following implications
  21. - It's possible to have both `ss_local` and `ss_redir` referring to the same `server` definition
  22. - It's possible to have multiple instances of `ss_redir` listening on the same address:port with `reuse_port` enabled referring to the same or different `server` sections
  23. `ss_rules` section is for configuring the behaviour of `ss-rules` script. There can only exist at most one such section with the name also being `ss_rules`
  24. redir_tcp name of ss_redir section with mode tcp_only or tcp_and_udp
  25. redir_udp name of ss_redir section with mode udp_only or tcp_and_udp
  26. ifnames only apply rules on packets from these ifnames
  27. --- for incoming packets having source address in
  28. src_ips_bypass will bypass the redir chain
  29. src_ips_forward will always go through the redir chain
  30. src_ips_checkdst will continue to have their destination addresses checked
  31. --- otherwise, the default action can be specified with
  32. src_default bypass, forward, [checkdst]
  33. --- if the previous check result is checkdst,
  34. --- then packets having destination address in
  35. dst_ips_bypass_file
  36. dst_ips_bypass will bypass the redir chain
  37. dst_ips_forward_file
  38. dst_ips_forward will go through the redir chain
  39. --- otherwise, the default action can be specified with
  40. dst_default [bypass], forward
  41. --- for local out tcp packets, the default action can be specified with
  42. local_default [bypass], forward, checkdst
  43. Bool option `dst_forward_recentrst` requires iptables/netfilter `recent` match module (`opkg install iptables-mod-conntrack-extra`). When enabled, `ss-rules` will setup iptables rules to forward through `ss-redir` those packets whose destination have recently sent to us multiple tcp-rst.
  44. ss-rules uses kernel ipset mechanism for storing addresses/networks. Those ipsets are also part of the API and can be populated by other programs, e.g. dnsmasq with builtin ipset support. For more details please read output of `ss-rules --help`
  45. Note also that `src_ips_xx` and `dst_ips_xx` actually also accepts cidr network representation. Option names are retained in its current form for backward compatibility coniderations
  46. # notes and faq
  47. Useful paths and commands for debugging
  48. # check current running status
  49. ubus call service list '{"name": "shadowsocks-libev"}'
  50. ubus call service list '{"name": "shadowsocks-libev", "verbose": true}'
  51. # dump validate definition
  52. ubus call service validate '{"package": "shadowsocks-libev"}'
  53. ubus call service validate '{"package": "shadowsocks-libev"}' \
  54. | jsonfilter -e '$["shadowsocks-libev"]["ss_tunnel"]'
  55. # check json config
  56. ls -l /var/etc/shadowsocks-libev/
  57. # set uci config option verbose to 1, restart the service and follow the log
  58. logread -f
  59. ss-redir needs to open a new socket and setsockopt IP_TRANSPARENT when sending udp reply to client. This requires `CAP_NET_ADMIN` and as such the process cannot run as `nobody`
  60. ss-local, ss-redir, etc. supports specifying an array of remote ss server, but supporting this in uci seems to be overkill. The workaround can be defining multiple `server` sections and multiple `ss-redir` instances with `reuse_port` enabled
  61. # recipes
  62. ## forward all
  63. This will setup firewall rules to forward almost all incoming tcp/udp and locally generated tcp traffic (excluding those to private addresses like 192.168.0.0/16 etc.) through remote shadowsocks server
  64. Install components.
  65. Retry each command till it succeed
  66. opkg install shadowsocks-libev-ss-redir
  67. opkg install shadowsocks-libev-ss-rules
  68. opkg install shadowsocks-libev-ss-tunnel
  69. Edit uci config `/etc/config/shadowsocks-libev`.
  70. Replace `config server 'sss0'` section with parameters of your own remote shadowsocks server.
  71. As for other options, change them only when you know the effect.
  72. config server 'sss0'
  73. option disabled 0
  74. option server '_sss_addr_'
  75. option server_port '_sss_port_'
  76. option password '********'
  77. option method 'aes-256-cfb'
  78. config ss_tunnel
  79. option disabled 0
  80. option server 'sss0'
  81. option local_address '0.0.0.0'
  82. option local_port '8053'
  83. option tunnel_address '8.8.8.8:53'
  84. option mode 'tcp_and_udp'
  85. config ss_redir ssr0
  86. option disabled 0
  87. option server 'sss0'
  88. option local_address '0.0.0.0'
  89. option local_port '1100'
  90. option mode 'tcp_and_udp'
  91. option reuse_port 1
  92. config ss_rules 'ss_rules'
  93. option disabled 0
  94. option redir_tcp 'ssr0'
  95. option redir_udp 'ssr0'
  96. option src_default 'checkdst'
  97. option dst_default 'forward'
  98. option local_default 'forward'
  99. Restart shadowsocks-libev components
  100. /etc/init.d/shadowsocks-libev restart
  101. Check if things are in place
  102. iptables-save | grep ss_rules
  103. netstat -lntp | grep -E '8053|1100'
  104. ps ww | grep ss-
  105. Edit `/etc/config/dhcp`, add a line to the first dnsmasq section like the following to let it use local tunnel endpoint for upstream dns query
  106. config dnsmasq
  107. ...
  108. list server '127.0.0.1#8053'
  109. Restart dnsmasq
  110. /etc/init.d/dnsmasq restart
  111. Check network on your computer
  112. nslookup www.google.com
  113. curl -vv https://www.google.com