Conversation
|
|
also you can see in short, it convert "useIP" to "useIPv4v6" or "useIPv6v4" base on originalDest-IP-type. |
|
for example if originalTarget is IPv4, we use "useIPv4v6" instead of "useIP", This does not change any logic, because in "useIP" we select a random IP between all-IP-types, and selected-IP can be any type, and "useIPv4v6" is the same, but it prioritize IPv4 to IPv6. This is necessary so that we don't encounter MTU-problem or GFW-recognize-problem(for freedom) |
|
Regardless of MTU-problem, I found a more important reason: almost all users bypass domestic websites, but if original-request-IP-type != final-sent-request-IP-type on UDP, they send 1250-bytes-on-IPv6/1230-bytes-on-IPv4, while it should be the other way around and GFW easily detects that the user is using proxy-tools !!! so we should send to same IP-type as much as possible. |
|
这两个anyip检查又是什么意思 |
currently, there is no difference between "listen": but if we use Xray-core/transport/internet/dialer.go Line 88 in 5464862 but this is not correct and we should received both IPv4 and IPv6, because "origin" mean use inbound-local, and inbound-local listen on both IPv4 and IPv6. /// localAddr is anyIP/anyIPv6 only when network is UDP and we listen on all-interface, so we should use |
|
我已经把这个功能标记为不支持udp了 udp上这玩意就是损坏的不应该再管了 而且src也没有这个问题 |
|
when UDP is listen on one-interface it works, also we should have this feature for UDP, otherwise we should have multiple-outbounds beside multiple-inbounds, but now we only need to have multiple-inbounds and one outbound with Nothing has changed except on "origin" when udp listen on one-interface "gateway" set to that, otherwise we don't set gateway(instead of not set at all) so now by excepting anyIP everything works properly, and there is no need for multiple-outbounds, only multiple-inbounds is needed. |
|
如果你执意那么做应该在udpworker知道hub是anyip之后根据源IP把本地IP重置成正确的0000或者[::] |
I will do it, wait... |
done. |
8672438 to
5808a4f
Compare
5808a4f to
e6ef75a
Compare
|
Tested and Ready. |
|
|
targetStrategy; More intelligent "useIP"/"ForceIP", enhance "origin" functionality
…elligent "useIP"/"ForceIP", enhance "origin" functionality (#5030) #5009 (comment)
|
|
|
we have duplicate codes related to domainStrategy, one in "transport/internet/config.go" and one in "proxy\freedom\config.go", i remove freedom-domainStrategy-codes and now freedom use internet-domainStrategy-codes.
we should not use outbound-handler Address() function to obtain outgoing-local-Addr, because we may set "origin" as sendThrough, and localAddr determined when we receive a connection, so we should use "ob.Gateway" instead, and i add "SetOutboundGateway" to set gateway.
suppose in inbound we use "quic-sniffer" or "fakeDNS", and in freedom-outbound we use "useIP"/"ForceIP" targetStrategy, suppose chrome send initial-quic-packet to an IPv4-fakeIP, so the UDP-payload size is 1250, after convert fakeIP to domain, because we use "useIP"/"forceIP" in outbound, the domain can resolve to an IPv6, but if our IPv6-interface-MTU is 1280(minimum possible), we have a packet with 1250+40+8=1298 size but 1298>1280, so we may have fragment-at-IP-level or packet fail to send at all.
regardless of MTU problem, even if our IPv6-MTU >= 1298, GFW can recognize these suspicious-packets, because GFW expect 1250-bytes for IPv4 and 1230-bytes for IPv6, but this can be the opposite.
so only for "UDP" and only for "useIP"/"forceIP" strategy, instead of selecting a random-IP between all IPv4 and IPv6 IPs, we should give priority to originalTarget-IP-type(try to select originalTarget-IP-type first, it means use "useIPv4v6"/"useIPv6v4" instead of "useIP" depending on originalTarget-IP-type)
also, mention that we cannot set two outbounds(one use "useIPv4v6" and one use "useIPv6v4"), because we cant route base on originalTarget-IP-type.