lsylsy2

所以这个PAC（对P大）优化方向就要改成科学上网和加速少数网站（比如医学部steam）了？

唔，可能外网无法访问这个页面： 完整列表如下： 网络号 主机掩码 网络掩码 network-number host-bits netmask --- 1.2.4.0 0.0.0.255 255.255.255.0 1.8.1.0 0.0.0.255 255.255.255.0 1.8.6.0 0.0.0.255 255.255.255.0 1.8.8.0 0.0.1.255 255.255.254.0 1.8.100.0 0.0.3.255 255.255.252.0 1.51.0.0 0.0.255.255 255.255.0.0 1.184.0.0 0.1.255.255 255.254.0.0...

大概看了下，是利用data/whiteiplist.pac 填入（处理成16进制的）IP段即可？ 不管是否为fakeip，pac返回proxy后都会在远端重新解析，那么我们是否可以： 删除掉fakeIpRange中所有不在cnIpRange中的数据？ 另外元旦开始（见v2ex上有讨论），墙的IP污染发生了变化（污染结果的IP数量大幅增加，不过似乎都在国外），如果fakeIpRange都不在cnIpRange，直接将其去掉应该影响也不大？ 还有就是cnIp16Range和subnetIpRangeList没太看懂，后者是用来判断内网，前者是……？

I've searched some issues and sof sites, it looks like systemd doesn't support globbing, so no meaning to solve at that stage (If I write configuration with no globbing, I...

Is there any discussion on this?

用方案2的话，如何判断IP变化的用户（比如ADSL）和不同的用户？

我没有太仔细研究协议……不过我猜是共享密钥，这样可以避免交换密钥的握手过程（openvpn被封的原因之一），那么就需要所有用户共享一个密钥？

我对密码学只有很初步的认识，尝试做一点分析： 1、整个数据包都需要被加密，然后这个加密不能留下特征，所以两台运行同版本shadowvpn的服务器（使用不同密钥）收发的数据包应当在数据内容上看不到任何相关性； 2、由于（1）为了避免有特征（2）shadowvpn的无连接特性，这个密钥只能通过其他方式分发，同时所有用户在这个部分必须使用同一个密钥（假如无法通过端口等下层协议分辨用户的话）。 shadowsocks那个issue的设计是可以接受并且没有明显问题的；最大的缺点就是用来加密IV1与userhash的内容的密钥需要所有使用这台服务器的人共享。问题应该并不是很大？这个头的长度不需要很长（因为IV1 + ver + userhash这段都是多余的负载，设计上就应该尽可能的缩短；而以我不多的密码学知识，密钥长度>数据长度是没有很大意义的），我们完全可以像openvpn生成static key一样提供一个自动生成随机密钥的工具，用户的密码前缀设置为这个串即可； ./shadowvpn --genkey generated key:123456abcdef7890 /server.json key:123456abcdef7890 {user:alice,pw:alicepass},{user:bob,pw:bobpass} /aliceclient.json {user:alice,pw:123456abcdef7890alicepass} 这样的形式；key的长度为一个定值即可（openvpn key也是定值长度）

另外，userhash是否应该是(IV1+user+pw)加密，避免重放攻击？（假设攻击人知道shared key）

我查询了一下openvpn的文档，其static key模式是stateless的；实现的也是点对点隧道，两侧配置文件中都需要指定自己与对端的IP，每个用户一个tun设备；这样看来这是一个没有现成方案的问题； - 独立密钥 - 服务端外网 IP & 服务端外网 Port 这两个显然是必须存在的； - 多用户情况下共享密钥 （如何区别两种密钥） 这个见 https://github.com/clowwindy/ShadowVPN/issues/7 ，可以考虑提供一个参数来生成【定长】的随机共享密钥，然后将其作为密码的前缀？实际使用时，写成AB形式，共享密钥为A，个人单独的密钥可以为B也可以为AB。 - 服务端 tun IP & 服务端 tun 子网掩码 - 客户端tun IP (本地生成可能冲突) -...