UDP noise #3711
UDP noise #3711
Conversation
|
This idea was discussed privately with OP for a while. To clarify, the added noise packets work for some protocols and disrupt others, but for QUIC/H3 it allegedly works with CDN (although I have not tested it myself) I think it would be too much maintenance effort to add specialized support for "fake clienthello", "fake wireguard", "fake voip", etc. Just let the user specify a bytestring directly, and that bytestring will be written as-is. They can write their own clienthello, or copy from some template. Anyway, I think the idea is good. |
I don't think this would disrupt anything(unless the transport has issues with dialer proxy,if u are talking about the line where I check for port 53 it wasn't because it disrputs dns,without that if condition the udp dns was fine I just added just to be safe),I tried with vless-splithttp quic and wireguard,both worked fine,About the packet type I think it is best to have two modes:1-the one u said with a user input string 2-a random generated byte that user would choose the min and max length for that byte |
|
Looks like rprx would like to merge, see what can we do |
I undrestand why u say this,u might be right the second u merge it people will use it and providers will just throttle udp for cloudflare,but it is not just about using it with cloudflare ,imagine I want to use a free wireguard service (I am not talking about warp,this one is already throttled heavily but there are others too,don't want to name them here) there is no way I can use them normaly but with this trick it works,basicly more people will have access to free proxy services,this is not a full solution but for a lot of times it could be usefull,and lastly they might throttle cloudflare but what if i want to use this with another cdn?amazon(this one almost never gets QOSed atleast where I live and I think it supports quic too) and I am not saying everyone should go and use amazon I am saying "if" anyone wants to use it this can help , as I mentioned it is not a full solution ,Best of luck to all the developers of this project |
|
Any how it is useful may be we will merge it privately. |
|
My take is we can do if change is clean and organized in one place. |
|
It's a good option for SplitHTTP for CDN, but not for QUIC, as they already have Obfuscation options
Agree, but base64url is better than bytestring |
So it is possible to do the same for non-HTTP/non-TLS TCP connections like VMESS+TCP ? |
dragonbreath2000
force-pushed
the
udp-noise
branch
from
ed9d275
to
f467c79
Compare
|
seam to be working {
"protocol": "freedom",
"settings": {
"noise":{
"packet":"rand:5-10", //str:higfw
"delay":"5-10"
}
},
"tag": "direct"
},I wrote two types of packet: |
赞同 |
|
You can make it more advanced, to make firewalls unable to block it easily |
|
我认为现在的代码应该精简一些 最开始那一版就可以 加上json设置delay和随机字节长度就行了 这东西非常非常容易被滤掉 搞得再高精尖对面patch一下有问题的udp conn track就毙掉了 不用搞得太复杂 还搞个浮动 |
proxy/freedom/freedom.go
Outdated
| if b.UDP != nil { | ||
| if w.Writer.UDPOverride.Address != nil { | ||
| b.UDP.Address = w.Writer.UDPOverride.Address | ||
| } | ||
| if w.Writer.UDPOverride.Port != 0 { | ||
| b.UDP.Port = w.Writer.UDPOverride.Port | ||
| } | ||
| if w.Writer.Handler.config.hasStrategy() && b.UDP.Address.Family().IsDomain() { | ||
| ip := w.Writer.Handler.resolveIP(w.Writer.Context, b.UDP.Address.Domain(), nil) | ||
| if ip != nil { | ||
| b.UDP.Address = ip | ||
| } | ||
| } | ||
| destAddr, _ := net.ResolveUDPAddr("udp", b.UDP.NetAddr()) | ||
| if destAddr == nil { | ||
| b.Release() | ||
| continue | ||
| } | ||
| n, err = w.Writer.PacketConnWrapper.WriteTo(b.Bytes(), destAddr) |
There was a problem hiding this comment.
something is off, why does the noisewriter need to deal with ip resolution? it already wraps PacketWriter which has the same logic
proxy/freedom/freedom.go
Outdated
| _, _ = w.Writer.PacketConnWrapper.Write(noise) | ||
|
|
||
| if w.Writer.config.Noise.DelayMin != 0 { | ||
| time.Sleep(time.Duration(randBetween(int64(w.Writer.config.Noise.DelayMin), int64(w.Writer.config.Noise.DelayMax))) * time.Millisecond) |
There was a problem hiding this comment.
since this is not an actual fragment, is the delay actually making a difference in this case? maybe it can be removed entirely to simplify the PR
There was a problem hiding this comment.
Why not? delay may make the firewall to judge the connection by the first bytes only, and not wait for more data and allow it
as nobody knows exactly how the target firewall works and nobody knows their limits, it could be useful for some users
There was a problem hiding this comment.
i'm asking if any difference has been observed in practice.
proxy/freedom/freedom.go
Outdated
| Context: ctx, | ||
| UDPOverride: UDPOverride, | ||
| if hasNoise { | ||
| return &NoisePacketWriter{ |
There was a problem hiding this comment.
i suggest to structure the code similarly to FragmentWriter, and add this wrapper outside of this function
There was a problem hiding this comment.
I am almost done , I clean up the code a lot,for this one I basicly had to create another function to return the wrapper,this PacketWriter uses counter,I do not know what it does(when i removed it it worked fine but it might mess something up so I kept it),for fragment they basicly added the wrapper in prooccess function,But in my case if I do that the code will get messy so I added another function(copy NewPacketWriter and return my wrapper instead)
|
the config parsing for fragment is really extreme levels of copy-pasting, and it seems that in order to be consistent with it, Xray-core/infra/conf/common.go Lines 247 to 249 in c0c23fd |
|
Yes, the config parsing of fragment is very very confusing |
|
@mmmray |
|
@yuhan6665 Is it possible to do similar thing to full random TCP connections like VMESS+TCP ? |
|
it is very unlikely to work for any TCP-based protocol. let's try to focus on getting this PR merged and discuss other ideas elsewhere... |
|
Looks ok to me. Thanks for the good collaboration |
|
If |
Adding a *net.UDPconn assertion in case of *Packetconnwrapper assertion failure should fix this,right?(not sure if this is the best way to fix) |
|
v2rayNG use this for VpnService protection. Maybe Xray need to fix its freedom As the system dialer is designed to be alterable, and Dial returns a |
|
i think a developer did it in a xray fork for iranian users https://github.com/GFW-knocker/Xray-core this is the project |
|
Freedom PacketWriter has been updated. I don't know about your firewall policy for single-socket multi-destination but you might want to update your code too. (e.g. one writer using net.PacketConn WriteTo, and another using net.Conn Write if not a net.PacketConn)
|
|
Thanks, fair enough. I think this commit should fix it, please check it... although this noise generator is mostly for a freedom dialerProxy on the tunnel's connection, and so I think the cone-ness of that outer protocol doesn't matter that much 🤔 |
|
Merged. Thanks all! |
|
|
|
我简单看了下配置，为什么这个不叫 udpnoise， |
* added udp noise * adding protobuf settings * freedom json parser and clean up * resolve confict * fix and clean up * use net.conn instead of packetconnwrapper * avoid constructing SequentialWriter directly --------- Co-authored-by: mmmray <142015632+mmmray@users.noreply.github.com>
|
感觉这里确实需要 base64 来支持非可打印字符，以及需要数组以支持连发多个 noise 包，“不能出现冒号”的限制应当去掉 @Fangliding 文档把 Freedom 改为“Freedom（fragment、noise）”， |
大概需要 noise 本身变成数组 noises |
Base64确实可以 不能用冒号是因为代码里用 split : 来分割 用冒号就割成几个了 当然如果换base64或者SplitN就可以解决这个问题了 至于发几个个人觉得就没啥必要了 等有墙开始开始解析第二个数据包但是放过第三个再说
Done, 变绿是因为不小心打出了个中文冒号 |
有没有一种可能 仅以第一个冒号来分割就可以避免歧义 当然 base64 也是有需求的
有没可能 如果直接写成 noises 数组可以一劳永逸 总之我觉得这个 PR 合并得有点快了 我只是说赞同可以加这个功能 还没 review |
strings.SplitN就是用第一个冒号啊(( |
Hi there, would you mind sharing a sample client json config for wireguard outbound with udp noise. I'm not sure if I'm doing this correctly. Thanks |
|
my take on having multiple noise packets: |
我是觉得如果某件事可以一次性做完一劳永逸，那么从一开始就设计完善比较好，就像 fragment 的 PR 初始版本远没有经我建议修改后的版本完善，同理人们会有发指定 UDP 包（base64）的需求，以及有多个 noise packets 的需求（比如现在 Chrome 的 QUIC hello 应该要占两个 UDP 包），并且当我们加上这些特性后就可以组合出 99% 的需求，以后就不用再改这个功能了。
|
This comment was marked as off-topic.
This comment was marked as off-topic.
Everybody has ideas all the time. But the fundamental truth about open source is that no matter the idea, it won't happen until somebody puts in the work and implements it. You open new issues with many small things every single week and expect us to respond to each one of them. You don't read existing discussions and re-litigate old decisions. This takes time from core maintainers, and the time that you spend arguing about random things on this forum, you could've learned golang and implemented your own ideas 10 times over. This has been going on for many months now, and you're not learning anything at all from the feedback we give you. I think it's completely insane to say that any of this happens for "no reason". |
|
@APT-ZERO 这主要是因为你此前的发言经常是 unreasonable，使得大家已经下意识 ignore 你的发言了， |
|
@APT-ZERO 虽然但是，我觉得最近你已经比以前靠谱一些了， |
* added udp noise * adding protobuf settings * freedom json parser and clean up * resolve confict * fix and clean up * use net.conn instead of packetconnwrapper * avoid constructing SequentialWriter directly --------- Co-authored-by: mmmray <142015632+mmmray@users.noreply.github.com>
sometimes internet providers block curtain udp based protocols(quic,wireguard) but udp itself is not blocked or throttled
using this strategy we can bypass almost all udp based protocol restrictions
This is how it works:
we want to use wireguard but our provider blockes it,The way they mostly do it is they almost always only inspect the first packet in each socket and if they see it is wireguard they will just drop everything on that socket
As I sayed they will inspect the socket only once and that's it, and with some noise we can fool them
What is noise:it is basicly a random nonesense packet that we send before wireguard or quic handshake,the server will ignore that packet like it was never sent but the gfw will inspect it and once it did not find anything suspicious they will let the connection go smoothly,
I will atach two screen shots of wireshark showing this behavior(this ISP blockes quic)
this PR is draft and not ready at all,I just wanted to discuss this with maintainer to see if you are interested in this feature
I will attach a sample config for people to test this(it is basicly a splithttp h3 with dialerProxy to freedom)
vless-splithttp-quic-dialer-proxy -clean.json
right now there is no option for enabling or disabling this feature as I did not want to spend a lot of time changing protobuf and json parser before discussing it with maintainers
this strategy I believe has a lot of pottential:
bypassing wireguard and quic protocol blocking
bypassing sni based filtering or whitelisting on quic(this does not happen right now but if or when they start doing it,this can easily bypass them)
right now the type of noise is a random byte generated by crypto/rand and it sends the noise in the first write to socket and if we want we could have other types of noise too(a video call packet,quic handshake packet with whitelisted sni,Dtls or whatever)