Freedom outbound doesn't work properly when connection is UDP and address is a domain

[patterniha]

during writing serverless-for-Iran-config I encountered this bug, and unfortunately, my work was delayed again.

Reproduction Method:

1. open New-incognito-tab in chrome-android, and go to "cloudflare-quic.com"
2. refresh the page until "HTTP/3" is shown, this show that "cloudflare-quic.com" and "quic" protocol is not block, and everything is working without VPN.
3. import this config to v2rayNG and turn on the VPN
4. refresh the page, the "HTTP/2" is shown, indicating that the UDP connection is down.
5. even if you close chrome and open New-incognito-tab and go to "cloudflare-quic.com" again and refresh, "HTTP/2" is still shown, i try this procedure many times, but as long as the VPN is on, "HTTP/3" is not displayed.
6. after turn off VPN (and close chrome and open new-incognito-tab) everything returns to normal and "HTTP/3" is displayed.

///

Tips:

1. you should open incognito tab instead of normal tab, otherwise chrome-cache affects the results.
2. if you replace fakedns with 1.1.1.1 and turn off sniffing, The problem will not occur: https://github.com/patterniha/bug-test/blob/main/NO-BUG-no-sniff.json
3. or if you use "redirect": "188.114.98.0:0" (or other cloudflare-ip), the problem will not occur: https://github.com/patterniha/bug-test/blob/main/NO-BUG-redirect.json

Conclusion:

the Reproduction-Method and Tips2-3 indicates that something is wrong when connection is UDP and address is domain and outbound is freedom (probably something is wrong with freedom.go)

[Fangliding]

核心可以正常处理目标为域名的UDP流量(包括QUIC)

也许你应该去问chrome为什么不愿意使用QUIC。如果你找到问题了的确与xray有关那或许可以进行一些修改，但是这很明显超出了这里应该处理的事情

[patterniha]

@Fangliding

I try to solve this problem myself.

do you test my reproduction-method?

[dyhkwong]

This should be related to #3351, it it converted from issue to discussion and apparently moderators don't want to further discuss about it.

[patterniha]

I found the problem and open pr soon.

[Fangliding]

唔 udp回包
为什么我有一种不好的预感

[patterniha]

@Fangliding

AsIs mode:

suppose our address is domain and domainStrategy is AsIs:

Xray-core/proxy/freedom/freedom.go

Line 149 in fbae89d

rawConn, err := dialer.Dial(ctx, dialDest)

this dial give us a remote-address for receiving-data

but this:

Xray-core/proxy/freedom/freedom.go

Line 373 in fbae89d

destAddr, _ := net.ResolveUDPAddr("udp", b.UDP.NetAddr())

give us a remote-address for sending-data

there is small property(depend on OS) that this two address are not equal and cause our connection fail.

UseIP mode:

this:

Xray-core/proxy/freedom/freedom.go

Line 136 in fbae89d

ip := h.resolveIP(ctx, dialDest.Address.Domain(), dialer.Address())

give us a remote-address for receiving-data

but this:

Xray-core/proxy/freedom/freedom.go

Line 368 in fbae89d

ip := w.Handler.resolveIP(w.Context, b.UDP.Address.Domain(), nil)

give us a remote-address for sending-data

because resolveIP give us a random-IP each time, there is high-probability that these two address are not equal and connection fail.

/////////////////////////////////////////

in short, we should determine remote-address one time and we should run DNS-query one time, otherwise we have two remote-address for one connection and we fail.

//////////////////////////////////////////

I open pr soon.

[patterniha]

@Fangliding

please reopen, i also have simple-proof for my words, and if you want i will present.

[Fangliding]

它好像确实存在 但是我不确定它是否与你的问题有关

[Fangliding]

应该说ResolveUDPAddr随机返回有问题 dialDest和sendto不一样应该是没什么问题的 本来就可以发出去 它只是一个包装器用来给没带目标的udp包设置一个默认的目标