LKL 資訊更新 -- TCP segmentation offload , Shadowsocks, HAProxy, Python, IPv6

allientNekoallientNeko 话题数：161会员, 大佬
最后编辑于 April 2017 在 教程 #0

不...
你們應該謝謝的是
https://www.91yunbbs.com/discussion/comment/1158/#Comment_1158
https://www.91yunbbs.com/discussion/comment/1471/#Comment_1471
@linhua

一直都只有他在研究

過了一段時間後
問題出了很多
還是一個一個解吧....

--

首先是
1. LKL 可以直接跑 SSR python 嗎?
2. LKL 可以直接跑 ss-server 嗎?

A: 可以 ss-server 一直都是可以的，
而 SSR python 的話就要用上 這個版本的 so
https://drive.google.com/file/d/0B0D0hDHteoksejNVWFQ2RU81MTA/view
@linhua 找到之前LKL缺了兩個 hooks，加上recompile之後就可以了

那.... @linhua 提到的 神秘代號是什麼? 有效嗎?
那是 TCP segmentation offload
@linhua 提到的environment variable是

LD_PRELOAD="/root/liblkl-hijack.so" LKL_HIJACK_NET_QDISC="root|fq" LKL_HIJACK_SYSCTL=“net.ipv4.tcp_congestion_control=bbr;net.ipv4.tcp_wmem=4096 16384 30000000" LKL_HIJACK_NET_IFTYPE="tap" LKL_HIJACK_NET_IFPARAMS="tap0" LKL_HIJACK_NET_IP="10.0.0.2" LKL_HIJACK_NET_NETMASK_LEN="24" LKL_HIJACK_NET_GATEWAY="10.0.0.1" LKL_HIJACK_OFFLOAD="0x8883" haproxy -f ./haproxy.cfg

和原版比起來多了

LKL_HIJACK_SYSCTL="net.ipv4.tcp_congestion_control=bbr;net.ipv4.tcp_wmem=4096 16384 30000000"
LKL_HIJACK_OFFLOAD="0x8883"

解釋一下
首先

LKL_HIJACK_OFFLOAD="0x8883"
net.ipv4.tcp_wmem="4096 16384 30000000"

不是神秘代號

1.
LKL_HIJACK_OFFLOAD 在 LKL 上 README.md也有
https://github.com/lkl/linux
本身也有介紹可以用 0x8002
開啓 mergeable RX buffer 和 guest csum
TCP segmentation offload 可以減少CPU usage
很應該要用的
之前沒有說是因為 debug log 一直吐出
"PKT is likely truncated!" 的 message
再加上當時因為沒有測試清楚
以為也不會怎樣
所以就放棄了
TSO 是什麼東東?
https://zh.wikipedia.org/wiki/大段卸载
上 wiki 吧

解釋神秘代碼 0x8883:
0x8883
兩進制是
1000 1000 1000 0011
從右數起第一個位置 是1
第2, 8, 12, 16個位置 都是1

在 linux 的 source file 中可以看到
http://lxr.free-electrons.com/source/include/uapi/linux/virtio_net.h#L34

34 /* The feature bitmap for virtio net /
35 #define VIRTIO_NET_F_CSUM 0 / Host handles pkts w/ partial csum /
36 #define VIRTIO_NET_F_GUEST_CSUM 1 / Guest handles pkts w/ partial csum /
37 #define VIRTIO_NET_F_CTRL_GUEST_OFFLOADS 2 / Dynamic offload configuration. /
38 #define VIRTIO_NET_F_MTU 3 / Initial MTU advice /
39 #define VIRTIO_NET_F_MAC 5 / Host has given MAC address. /
40 #define VIRTIO_NET_F_GUEST_TSO4 7 / Guest can handle TSOv4 in. /
41 #define VIRTIO_NET_F_GUEST_TSO6 8 / Guest can handle TSOv6 in. /
42 #define VIRTIO_NET_F_GUEST_ECN 9 / Guest can handle TSO[6] w/ ECN in. /
43 #define VIRTIO_NET_F_GUEST_UFO 10 / Guest can handle UFO in. /
44 #define VIRTIO_NET_F_HOST_TSO4 11 / Host can handle TSOv4 in. /
45 #define VIRTIO_NET_F_HOST_TSO6 12 / Host can handle TSOv6 in. /
46 #define VIRTIO_NET_F_HOST_ECN 13 / Host can handle TSO[6] w/ ECN in. /
47 #define VIRTIO_NET_F_HOST_UFO 14 / Host can handle UFO in. /
48 #define VIRTIO_NET_F_MRG_RXBUF 15 / Host can merge receive buffers. */

對應一下
有開的是
VIRTIO_NET_F_CSUM (第0個位置)
VIRTIO_NET_F_GUEST_CSUM (第1個)
VIRTIO_NET_F_GUEST_TSO4 (第7)
VIRTIO_NET_F_HOST_TSO4 (第11)
VIRTIO_NET_F_MRG_RXBUF (第15)
這幾個 就是 TCP segmentation offload

當然
如果有用 IPv6 的可以把 VIRTIO_NET_F_GUEST_TSO6 和 VIRTIO_NET_F_HOST_TSO6 打開來用
變成
1001 1001 1000 0011
轉成十六進制
0x9983

LKL_HIJACK_OFFLOAD="0x9983"

沒有的話 用 0x8883 就好了

2.
而 net.ipv4.tcp_wmem 是調 TCP send buffer 大小
這個上有詳細解釋
https://wwwx.cs.unc.edu/~sparkst/howto/network_tuning.php

3.
IPv6

一直被人吐槽沒有 IPv6
不是沒有

LKL_HIJACK_NET_IPV6
LKL_HIJACK_NET_NETMASK6_LEN
LKL_HIJACK_NET_GATEWAY6

這幾個就是 IPV6 對應的變數
而設定的方法和 UML 一樣

--

https://drive.google.com/file/d/0B0D0hDHteoksejNVWFQ2RU81MTA/view
使用 @linhua 老大補完的 LKL

LD_PRELOAD="/root/liblkl-hijack.so" \
LKL_HIJACK_NET_QDISC="root|fq" \
LKL_HIJACK_SYSCTL="net.ipv4.tcp_congestion_control=bbr;net.ipv4.tcp_wmem=4096 16384 30000000" \
LKL_HIJACK_NET_IFTYPE="tap" \
LKL_HIJACK_NET_IFPARAMS="tap0" \
LKL_HIJACK_NET_IP="10.0.0.2" \
LKL_HIJACK_NET_NETMASK_LEN="24" \
LKL_HIJACK_NET_GATEWAY="10.0.0.1" \
LKL_HIJACK_OFFLOAD="0x9983" \
python server.py -p 443 -k 自己喜歡的密碼 -m aes-256-cfb -O auth_sha1_v4 -o http_simple

就可以直接跑 LKL + python @linhua

UML, LKL, LKL+TSO的效能比較:
https://www.91yunbbs.com/discussion/229/lkl-uml-native-的比較-有用嗎?new=1

此话题使用的标签:
此话题使用的标签:

评论

  • CyzaryCyzary 话题数：16会员, 大佬
    #1
    我好像..没看懂
    感谢大佬啦
  • ohmyaniohmyani 话题数：11会员
    最后编辑于 May 2017 #2

    谢谢大佬们的分享!
    最近遇到了一个问题，LKL状态下，ss-server启动用443端口（LKL和haproxy中也做了转发），用最新的AEAD（aes-256-gcm）协议，对ss进行debug发现：
    ERROR: failed to handshake with 10.0.0.2: authentication error
    ERROR: failed to handshake with 10.0.0.2: authentication error
    ERROR: block all requests from 10.0.0.2
    ERROR: block all requests from 10.0.0.2

    用aes-256-cfb就没问题；用其它端口的AES-GCM也没问题。

    请问，这种情况是不是因为haproxy不支持最新协议导致的？
    但看文档中有ssl-default-bind-ciphers RSA+AESGCM这一项
    haproxy.cfg里面只添加了bind *:443,并没指定协议和加密方式 。
    目前应该没有解决办法吧？

    @linhua @allientNeko

  • bubblesbubbles 话题数：36会员
    #3

    @ohmyani 说道：
    谢谢大佬们的分享!
    最近遇到了一个问题，LKL状态下，ss-server启动用443端口（LKL和haproxy中也做了转发），用最新的AEAD（aes-256-gcm）协议，对ss进行debug发现：
    ERROR: failed to handshake with 10.0.0.2: authentication error
    ERROR: failed to handshake with 10.0.0.2: authentication error
    ERROR: block all requests from 10.0.0.2
    ERROR: block all requests from 10.0.0.2

    用aes-256-cfb就没问题；用其它端口的AES-GCM也没问题。

    请问，这种情况是不是因为haproxy不支持最新协议导致的？
    但看文档中有ssl-default-bind-ciphers RSA+AESGCM这一项
    haproxy.cfg里面只添加了bind *:443,并没指定协议和加密方式 。
    目前应该没有解决办法吧？

    @linhua @allientNeko

    这个我前面遇到过，是你修改认证方式，或者客户端配置错误，客户端一直向服务端发送错误请求，服务端收到的全部是是haproxy10.0.0.2的地址，$$认证错误多次后会屏蔽这个IP，现在完全可以不用haproxy，使用新版的lkl http://soft.91yun.org/uml/lkl/liblkl-hijack.so
    然后参照我前面的配置，IPv6的话对照修改。
    https://www.91yunbbs.com/discussion/87/黑科技-不用換-kernel-不用uml-也可以bbr-linux-kernel-library-還有可能-bbr-lotserver/p7#Comment_1939

  • ohmyaniohmyani 话题数：11会员
    最后编辑于 May 2017 #4

    @bubbles 多谢你的指点。
    昨天进行的一键安装版本，当前在用的应该就是最新版的LKL。
    客户端配置应该没错，因为换了不同端口，就会正常传输数据。
    跳过haproxy用443端口AES-GCM模式，
    提示同上述类似:
    ERROR: failed to handshake with 202.120..: authentication error
    ERROR: failed to handshake with 202.120..: authentication error
    ERROR: block all requests from 202.120..
    ERROR: block all requests from 202.120..

    可能是LKL内核支持的问题。

  • allientNekoallientNeko 话题数：161会员, 大佬
    #5

    @ohmyani 说道：
    @bubbles 多谢你的指点。
    昨天进行的一键安装版本，当前在用的应该就是最新版的LKL。
    客户端配置应该没错，因为换了不同端口，就会正常传输数据。
    跳过haproxy用443端口AES-GCM模式，
    提示同上述类似:
    ERROR: failed to handshake with 202.120..: authentication error
    ERROR: failed to handshake with 202.120..: authentication error
    ERROR: block all requests from 202.120..
    ERROR: block all requests from 202.120..

    可能是LKL内核支持的问题。

    SS 的話就不要用 haproxy 中轉了
    直接上SS吧

  • TinyTiny 话题数：50会员, 大佬
    最后编辑于 May 2017 #6
    感谢分享
  • bubblesbubbles 话题数：36会员
    #7

    @ohmyani 这个提示是认证授权错误，检查你客户端和服务端的配置。

  • ohmyaniohmyani 话题数：11会员
    #8

    @bubbles 说道：
    @ohmyani 这个提示是认证授权错误，检查你客户端和服务端的配置。

    昨天进行测试没有通过，早上再一次直接启动lkl ss测试正常了，错误没重现。

    另外之前haproxy错误如下，最初5分钟内验证通过，过一会就认证错误了。

     root@~# ss-server -p 443 -k password -m aes-256-gcm -v
 2017-05-18 09:53:45 INFO: initializing ciphers... aes-256-gcm
 2017-05-18 09:53:45 INFO: tcp server listening at 0.0.0.0:443
 2017-05-18 09:53:45 INFO: running from root user
 2017-05-18 09:53:51 INFO: accept a connection
 2017-05-18 09:53:51 INFO: connect to www.youtube.com:443
 2017-05-18 09:53:51 INFO: accept a connection
 2017-05-18 09:53:51 INFO: connect to s.youtube.com:443
 2017-05-18 09:53:51 INFO: successfully resolved www.youtube.com
 2017-05-18 09:53:51 INFO: remote connected
 2017-05-18 09:53:51 INFO: successfully resolved s.youtube.com
 2017-05-18 09:53:51 INFO: remote connected
 2017-05-18 09:53:52 INFO: accept a connection
 2017-05-18 09:53:52 INFO: connect to tiles.services.mozilla.com:443
 2017-05-18 09:53:52 INFO: IPv6 resolv: valid domain but no data of requested type
 2017-05-18 09:53:52 INFO: successfully resolved tiles.services.mozilla.com
 2017-05-18 09:53:52 INFO: remote connected
 2017-05-18 09:53:52 INFO: accept a connection
 2017-05-18 09:53:52 INFO: connect to s.ytimg.com:443
 2017-05-18 09:53:52 INFO: successfully resolved s.ytimg.com
 2017-05-18 09:53:52 INFO: remote connected
 2017-05-18 09:53:54 INFO: accept a connection
 2017-05-18 09:53:54 INFO: connect to i.ytimg.com:443
 2017-05-18 09:53:54 INFO: accept a connection
 2017-05-18 09:53:54 INFO: connect to yt3.ggpht.com:443
 2017-05-18 09:53:54 INFO: successfully resolved yt3.ggpht.com
 2017-05-18 09:53:54 INFO: remote connected
 2017-05-18 09:53:54 INFO: successfully resolved i.ytimg.com
 2017-05-18 09:53:54 INFO: remote connected
 2017-05-18 09:53:58 INFO: accept a connection
 2017-05-18 09:53:58 INFO: connect to apis.google.com:443
 ......
 ......
 2017-05-18 09:57:36 INFO: current server connection: 14
 2017-05-18 09:57:36 INFO: server_recv close the connection
 2017-05-18 09:57:36 INFO: current remote connection: 13
 2017-05-18 09:57:36 INFO: current server connection: 13
 2017-05-18 09:57:37 INFO: server_recv close the connection
 2017-05-18 09:57:37 INFO: current remote connection: 12
 2017-05-18 09:57:37 INFO: current server connection: 12
 2017-05-18 09:57:38 INFO: accept a connection
 2017-05-18 09:57:38 ERROR: failed to handshake with 10.0.0.2: authentication error
 2017-05-18 09:57:38 INFO: current server connection: 12
 2017-05-18 09:57:38 INFO: accept a connection
 2017-05-18 09:57:38 ERROR: failed to handshake with 10.0.0.2: authentication error
 2017-05-18 09:57:38 INFO: current server connection: 12
 2017-05-18 09:57:39 INFO: accept a connection
 2017-05-18 09:57:39 ERROR: failed to handshake with 10.0.0.2: authentication error
 2017-05-18 09:57:39 INFO: current server connection: 12
 2017-05-18 09:57:40 INFO: server_recv close the connection
 2017-05-18 09:57:40 INFO: current remote connection: 11
 2017-05-18 09:57:40 INFO: current server connection: 11
 2017-05-18 09:57:40 INFO: accept a connection
 2017-05-18 09:57:40 ERROR: failed to handshake with 10.0.0.2: authentication error
 2017-05-18 09:57:40 INFO: current server connection: 11
 2017-05-18 09:57:41 INFO: accept a connection
 2017-05-18 09:57:41 ERROR: failed to handshake with 10.0.0.2: authentication error
 2017-05-18 09:57:41 INFO: current server connection: 11
 2017-05-18 09:57:41 INFO: accept a connection
 2017-05-18 09:57:41 ERROR: failed to handshake with 10.0.0.2: authentication error
 2017-05-18 09:57:41 INFO: current server connection: 11
 2017-05-18 09:57:41 INFO: server_recv close the connection
 2017-05-18 09:57:41 INFO: current remote connection: 10
 2017-05-18 09:57:41 INFO: current server connection: 10
 2017-05-18 09:57:43 INFO: server_recv close the connection
 2017-05-18 09:57:43 INFO: current remote connection: 9
 2017-05-18 09:57:43 INFO: current server connection: 9
 2017-05-18 09:57:43 INFO: server_recv close the connection
 2017-05-18 09:57:43 INFO: current remote connection: 8
 2017-05-18 09:57:43 INFO: current server connection: 8
 2017-05-18 09:57:43 INFO: server_recv close the connection
 2017-05-18 09:57:43 INFO: current remote connection: 7
 2017-05-18 09:57:43 INFO: current server connection: 7
 2017-05-18 09:57:43 INFO: server_recv close the connection
 2017-05-18 09:57:43 INFO: current remote connection: 6
 2017-05-18 09:57:43 INFO: current server connection: 6
 2017-05-18 09:57:44 INFO: server_recv close the connection
 2017-05-18 09:57:44 INFO: current remote connection: 5
 2017-05-18 09:57:44 INFO: current server connection: 5
 2017-05-18 09:57:44 INFO: accept a connection
 2017-05-18 09:57:44 ERROR: failed to handshake with 10.0.0.2: authentication error
 2017-05-18 09:57:44 INFO: current server connection: 5
 2017-05-18 09:57:45 INFO: accept a connection
 2017-05-18 09:57:45 ERROR: failed to handshake with 10.0.0.2: authentication error
 2017-05-18 09:57:45 INFO: current server connection: 5
 2017-05-18 09:57:45 INFO: accept a connection
 2017-05-18 09:57:45 ERROR: failed to handshake with 10.0.0.2: authentication error
 2017-05-18 09:57:45 INFO: current server connection: 5
 2017-05-18 09:57:50 ERROR: block all requests from 10.0.0.2
 2017-05-18 09:57:50 ERROR: block all requests from 10.0.0.2
 2017-05-18 09:57:50 ERROR: block all requests from 10.0.0.2
 2017-05-18 09:57:50 ERROR: block all requests from 10.0.0.2
 2017-05-18 09:57:51 ERROR: block all requests from 10.0.0.2
 2017-05-18 09:57:51 ERROR: block all requests from 10.0.0.2
 2017-05-18 09:57:51 ERROR: block all requests from 10.0.0.2
 2017-05-18 09:57:52 ERROR: block all requests from 10.0.0.2
 2017-05-18 09:57:52 ERROR: block all requests from 10.0.0.2
 2017-05-18 09:57:52 ERROR: block all requests from 10.0.0.2
 2017-05-18 09:57:53 ERROR: block all requests from 10.0.0.2
 2017-05-18 09:57:53 ERROR: block all requests from 10.0.0.2
 2017-05-18 09:57:53 ERROR: block all requests from 10.0.0.2
 2017-05-18 09:57:53 ERROR: block all requests from 10.0.0.2
 2017-05-18 09:57:53 ERROR: block all requests from 10.0.0.2
^C 2017-05-18 09:57:54 INFO: closed gracefully
 2017-05-18 09:57:54 INFO: current server connection: 4
 2017-05-18 09:57:54 INFO: current remote connection: 4
 2017-05-18 09:57:54 INFO: current server connection: 3
 2017-05-18 09:57:54 INFO: current remote connection: 3
  • ohmyaniohmyani 话题数：11会员
    #9

    @allientNeko 说道：

    @ohmyani 说道：
    @bubbles 多谢你的指点。
    昨天进行的一键安装版本，当前在用的应该就是最新版的LKL。
    客户端配置应该没错，因为换了不同端口，就会正常传输数据。
    跳过haproxy用443端口AES-GCM模式，
    提示同上述类似:
    ERROR: failed to handshake with 202.120..: authentication error
    ERROR: failed to handshake with 202.120..: authentication error
    ERROR: block all requests from 202.120..
    ERROR: block all requests from 202.120..

    可能是LKL内核支持的问题。

    SS 的話就不要用 haproxy 中轉了
    直接上SS吧

    昨天测试lkl-ss-GCM模式（无haproxy中转）报错，今天早上再次尝试通过。
    错误可能是运行环境问题导致。

登录或注册后才能评论。