Multiple clients design

[clowwindy]

We have two approaches

1. Different clients binds different ports and have different IPs and tun devices
2. Same port, using builtin NAT (change src & dst IP in payload's IP header)

Also, we can generate pidfile, logfile, inft etc from conf filename automatically

[lsylsy2]

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

[clowwindy]

在 header 里存放加密的用户标识。

[lsylsy2]

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

[clowwindy]

这就是需要研究的地方，shadowsocks 也是这个原因目前协议不支持多用户

[cj1324]

header放里的用户标识，考虑不加密或者某个全局共享密钥加密？ 这样就可以找到对应用户预先配置的独立密钥。 解密完整数据。 不打算做dhcp的话就手动配置ip信息。保持原有的IP头通过udp发送到对应用户的tun设备上，应该就是正确的 。 缺点:客户端配置太复杂了

[clowwindy]

是的，光是用两个 key 已经太复杂了。 https://github.com/clowwindy/shadowsocks/issues/169

不加密又太容易被识别了。

[cj1324]

不知道密码学为何物， 要不拿服务端 tun IP + udp:addr:port 取hash 做共享密钥。 建议配置的时候做更改。 糗

[clowwindy]

这个默认密码太容易猜出来了。我觉得可以分两种情况，一种是只有一个用户，个人使用，这时只需要一个密码。如果有人想用多用户功能，再让他设一个共享密码和每个用户的密码。

[lsylsy2]

我对密码学只有很初步的认识，尝试做一点分析： 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也是定值长度）

[lsylsy2]

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

[clowwindy]

抱歉最近实在是太忙了，也就国庆期间比较有时间

如果服务器配制成单用户模式，就按照现在的来；如果配制成多用户模式，就用两个 key 来搞。重放攻击可以先不管，我们的目标是翻墙

用固定长度前缀当共享密钥的思路不错

[p0we7]

问一下 clowwindy ， 这个mtu问题解决好了吗 ？ 之前用过 sigmavpn 与 fastd 都不会设置mtu 导致一开始速度可以， 一分钟左右之后就没有速度了。

[myliyifei]

共享端口还是非常有意义的，最近发现电信只对几个常用端口正常速度22 80 443等（有意思的是3724 WOW端口也正常），其他端口限速和TCP重传很明显。