Finalmask: Add XICMP (relies on mKCP/QUIC or WireGuard)#5633
Conversation
|
|
这是因为 XICMP 自带分包还是就是不限制？ |
分包和 pktConn 一样交由 IP 层处理了，程序收到的是组好的，测试发 8000 那边也能收到 8000， |
|
|
|
|
|
XDNS 服务端有合包逻辑？
XDNS 也能这样吗 |
会尽量把包在限制内塞在一个 txt 记录里
不建议，xicmp 不需要经过公共服务器转发，行为可以自己管理，xdns 如果不发空响应可能让转发服务器做出未知行为 |
|
重新看了下 rfc echo id 和 echo seq 是两字节，api 给的 int 还以为是四字节， |
|
反正代码里取的 uint16() 最后都会截断到uint16去 不会报错 |
|
|
似乎是 break 了，xhttp reality 只配置 path mode 连不上旧版，只是卡住没有报错，还没看是什么原因， mode pactet-up stream-one stream-up 单独配置都可以连上，就 auto 不行 |
因为 linux 内核对 icmp echo 默认会回相同的 echo.Data，所以客户端会收到两份 reply，一份的 echo.Data 为发送过去的，一份为 xray 返回的，所以要确保返回的前 n 个字节与发送的前 n 个字节不同才能区分 想了一下可以随机一个字节塞前面，记录下 seq 与这个字节，返回再随机一个与这个不同的， |
|
|
|
|
|
|
echo request的响应和请求不一样本身就是特征了( |
|
|
|
|
这个不影响，就是有一份回复是和发出去的一样（来自 linux内核） |
|
|
|
|
|
|
|
话说你有想过过了nat之后id出去会不一样吗 然后双端设成一样的最后还是给扔了 |
|
不确定 nat 转发 icmp 是什么行为， 如果 id 在转发会变那只能靠 echo.Data 上加一层自己的头来确认， |
|
重构了下加了个 seqStatus，在轮转(poll)空 echo.Data 的情况下则不需要加字节区分 以及修改在客户端有数据时直接记录数据里的第一个字节，服务端生成一个不同的在前面， |
|
icmp 对端只有 ip 信息，原始 kcp 可以根据 ip port 来区分不同 session，改了下把 id 作为 port 模拟了这一行为， 不过理论上不模拟也没事，因为即使单IP多客户端 单个客户端也只会接收自己的那一个 id 数据， |
RPRX
changed the title
RPRX
changed the title
|
#5639 有人问 Finalmask 是否支持 WG 你测一下（有原生 UDP 特性）， 还有 SS AEAD/2022 的 UDP 你也测一下，VLESS Encryption 以后也要出原生 UDP |
ss 之前看过应该问题不大， |
|
|
{
"log": { "loglevel": "debug" },
"inbounds": [
{
"listen": "127.0.0.1",
"port": 1080,
"protocol": "socks",
"settings": {
"auth": "noauth",
"udp": true
}
},
{
"tag": "wg-in",
// "listen": "127.0.0.1",
"port": 1081,
"protocol": "wireguard",
"settings": {
"secretKey": "uJv5tZMDltsiYEn+kUwb0Ll/CXWhMkaSCWWhfPEZM3A=",
"peers": [
{
"publicKey": "6e65ce0be17517110c17d77288ad87e7fd5252dcc7d09b95a39d61db03df832a"
}
]
}
}
],
"outbounds": [
{
"protocol": "wireguard",
"settings": {
"secretKey": "uJv5tZMDltsiYEn+kUwb0Ll/CXWhMkaSCWWhfPEZM3A=",
"address": ["10.1.1.1", "fd59:7153:2388:b5fd:0000:0000:1234:0001"],
"peers": [
{
"publicKey": "6e65ce0be17517110c17d77288ad87e7fd5252dcc7d09b95a39d61db03df832a",
"endpoint": "127.0.0.1:1081"
}
],
"noKernelTun": true
}
},
{
"tag": "direct",
"protocol": "freedom"
}
],
"routing": {
"rules": [
{
"inboundTag": ["wg-in"],
"outboundTag": "direct"
}
]
}
} |
RPRX
changed the title
|
@LjhAUMEM Project X NFT https://etherscan.io/tx/0x65731430636ec0673e1763af01646db238f789c324dbfa321de2b3911f6fc97c
Finalmask 的下一步计划你看一下 https://t.me/projectXtls/1473 目前有人提到 MQTT、RDP、FakeSIP、Kafka，还有 STOMP https://t.me/projectXray/4633462 https://t.me/projectXray/4633467 Email 放草稿箱不发的话是 XDRIVE 的范畴，传输层，这种用别人家可靠服务的最好自带少点浪费的可靠传输和间隔控制吧，
|
3 participants
无 mtu 限制，quic 也可使用
需要 root 或者 CAP_NET_RAW 权限
逻辑与 xdns 相似，一发一收，但有两个区别
目前两个配置项
ip: 监听的 ip，默认 0.0.0.0
id: 只接收指定 echo.ID 的数据，不设置可能看到大量噪声
另外如果服务端机器内核没关闭对 icmp echo 的 reply 客户端就会看到两个 reply，一个来自内核一个来自 xray，用户态程序决定不了内核行为，你可能希望关闭内核的回复，当然不关闭对 xray 也是没影响的
配置示例
{ "log": { "loglevel": "debug" }, "inbounds": [ { "listen": "127.0.0.1", "port": 1080, "protocol": "socks", "settings": { "auth": "noauth", "udp": true } } ], "outbounds": [ { "protocol": "vless", "settings": { "address": "a.com", "port": 1081, "id": "5783a3e7-e373-51cd-8642-c83782b807c5", "encryption": "none" }, "streamSettings": { "network": "kcp", "finalmask": { "udp": [ { "type": "xicmp", "settings": { "id": 1234 } } ] } } } ] }{ "log": { "loglevel": "debug" }, "inbounds": [ { "listen": "127.0.0.1", "port": 1081, "protocol": "vless", "settings": { "clients": [ { "id": "5783a3e7-e373-51cd-8642-c83782b807c5" } ], "decryption": "none" }, "streamSettings": { "network": "kcp", "finalmask": { "udp": [ { "type": "xicmp", "settings": { "id": 1234 } } ] } } } ], "outbounds": [ { "protocol": "freedom" } ] }