一、通过请求IP设定口IP
首先我们看下SSS数据包的走向：
A: 用户发出加密请求到SSS服务器
B: SSS服务器解密请求后转发到目标服务器
C: 目标服务器回应SSS服务器
D: SSS服务器加密回应返回给用户然后解密后使用
其中步骤B是影响出口IP的关键步骤，需要制定iptables规则修改源ip
理论上做SNAT处理即可，但SSS转发用户请求时端口由系统随机分配，目标服务器、端口不可预测。
简单说，从SSS出去的数据包，已经不是用户发出的那个包了，在sourcePort、destIP、destPort都不可控的情况下去修改sourceIP
结论：不可行
二、iptables Owner Match 方案
SSS作者clowwindy在#131给了参考方案：https://github.com/shadowsocks/shadowsocks/issues/131
通过iptables的Owner match来实现，前提是用不同的用户启动多个不同的SSS实例
Owner match支持–uid-owner、–pid-owner、–sid-owner、–cmd-owner匹配
很可惜我的vps上不支持–pid-owner，需要编译内核，遂放弃，决定采用 –uid-owner模式
思路是建几个用户分别启动SSS实例，并使用不同的端口(如1081、1082、1083)，再做简单的端口重定向
第一步、建立用户
第二步、多SSS实例配置
分别给实例指定不同的配置文件config1081.json、config1082.json、config1083.json，启动脚本如下
到此，多出口IP已经完成，SSS服务器上现有3个出口IP和N个不同的SSS组合，比如：
192.168.0.1:1081、192.168.0.2:1082、192.168.0.3:1083、192.168.0.1:1082、192.168.0.1:1083等等
作为轻微强迫症患者，实在受不了，想简化一下，只留一个1081对外开放:
192.168.0.1:1081(出口192.168.0.1)、192.168.0.2:1081(出口192.168.0.2)、192.168.0.3:1081(出口192.168.0.3)
第四步、简化
思路：禁止1082、1083的对外开放，并做个转发，192.168.0.2:1081 转发到 192.168.0.2:1082， 192.168.0.3:1081 转发到 192.168.0.3:1083
