clowwindy
Simply client configuration
客户端配置：
必须
- 独立密钥
- 服务端外网 IP & 服务端外网 Port
- 服务端 tun IP
可选
- 多用户情况下共享密钥 （如何区别两种密钥）
- 服务端的dns server (优化网络)
兼容系统考虑子网掩码可能是255.255.255.254 多用户的情况需要做手动NAT
为了兼容不同的系统（包括 Android），使用点对点 TUN，这就要求每对服务器/客户端的虚拟 IP 都是单独的一对，分别属于不同的子网，多个客户端不能在一个内网里。
比如：
- 10.8.0.1 - 10.8.0.2 / 255.255.255.254
- 10.8.0.3 - 10.8.0.4 / 255.255.255.254
- 10.8.0.5 - 10.8.0.6 / 255.255.255.254
另一种方式是绕开系统的 NAT，自己做 NAT，就像 OpenVPN 一样。缺点是影响性能。
我查询了一下openvpn的文档，其static key模式是stateless的；实现的也是点对点隧道，两侧配置文件中都需要指定自己与对端的IP，每个用户一个tun设备；这样看来这是一个没有现成方案的问题；
- 独立密钥
- 服务端外网 IP & 服务端外网 Port
这两个显然是必须存在的；
- 多用户情况下共享密钥 （如何区别两种密钥）
这个见 https://github.com/clowwindy/ShadowVPN/issues/7 ，可以考虑提供一个参数来生成【定长】的随机共享密钥，然后将其作为密码的前缀？实际使用时，写成AB形式，共享密钥为A，个人单独的密钥可以为B也可以为AB。
- 服务端 tun IP & 服务端 tun 子网掩码
- 客户端tun IP (本地生成可能冲突)
- 服务端的dns server (优化网络)
当一台server与多个client连接时，因为冲突问题，服务器与客户端的tun IP应当是同时需要存在的；而想要在stateless的情况下获取这些，大概只能在上层跑一个DHCP服务器了（DHCP同时能够获取dns server）。
DHCP可以在内部做，也可以利用外部程序；利用外部程序的话，包括DHCP、NAT等都交给了外部，shadowvpn实际上就只做了一个二层的bridge？（完全可以算一个可选方案） 在内部做的话，DHCP和NAT两个基本是绑定的，很难NAT利用外部，DHCP内部处理。 内部做NAT与DHCP的话还有一个优点；就是单server多client的话，不需要server建立许多许多的tun设备，对性能也是一个帮助。
这其实是shadowvpn的一个定位问题； 1、在能够透过G*W的情况下，尽一切可能精简，提高性能；在这种情况下，做成bridge可能是一个结果； 2、支持单server、多client，存在被用作商业服务的可能（一台server为100~1K乃至更高数量的client提供服务，shadowsocks的话单服务器数百用户应当已有实例），那么我们此时是否可以大胆认为server的处理能力不会差到路由器MIPS的级别，消耗计算能力换取DHCP与NAT的功能以及免去大量tun设备的问题（没有实际测试，但是设备数量多到一定程度的话对系统应当也有消耗）。
想了一个测试环境： 程序A：创建10K个tun设备，IP分别为10.0.0.1~10.x.x.x中的若干个奇数IP；对端IP为对应的本机IP+1； 程序B：向各个”对端IP“随机发包，可以直接发UDP/ICMP，内容无所谓。 程序A收到数据之后可以： 1、什么都不做 2、模拟ss/sv的方式写log 3、echo回去（UDP包的话程序B不用理会，直接忽略） 4、按照SV的格式进行加密解密 or将234组合。 这样应当是一个不错的测试样例？ 另外，ss的数据应当是所有人共用一个端口、一个密码的数据吧？sv多用户的话，由于不同用户IP不同，必须做NAT、用户认证等处理，也许会有额外开销。
刚才思考了一下，将shadowvpn本身做成一个bridge，利用其它工具来做DHCP、NAT、DNS等会是一个好方案。 优点： 1、扩展性高，不必重新造轮子，对IPv6之类的支持也能更好（IPv6毕竟是将来的趋势） 2、若两端都是openwrt类低端硬件，依旧可以很简单的实现一个ipv4的点对点tunnel，同时低端硬件实现复杂功能这个”需求“就不靠谱；而单x86 linux server对大量client的情况下，server配置较为复杂是可以接受的（现有常见VPN除了openvpn，NAT模式基本都需要ppp之类的其它软件来做，vpn本身只是bridge），做成标准DHCP协议的话client端依旧非常轻量、简洁。 3、定位在路由器的话，chnroute、dnsmasq选择解析也都是要做的吧？这些也很难放进来的；还不如一起丢出去，好好设计个接口。
@clowwindy windy,請問一下除了chnroute還有哪裡可以更新到整個大陸的和香港的ip段呢，因為最近發現很多像阿里雲這些好多地方機房都沒有包含在chnroutes裡面
@Jokder
curl 'http://ftp.apnic.net/apnic/stats/apnic/delegated-apnic-latest' | grep ipv4 | grep CN | awk -F\| '{ printf("%s/%d\n", $4, 32-log($5)/log(2)) }' > chnroute.txt