Additional tips for Reality

[houmie]

Hello,

Looking at the REALITY repo, they give some additional tips in Chinese:

配置加分项：禁回国流量，TCP/80、UDP/443 也转发（REALITY 对外表现即为端口转发，目标 IP 冷门或许更好）

It's generally difficult to translate Chinese into English, but it seems to suggest the following:

Configuration bonus points: Disable local traffic, **TCP/80, UDP/443 are also forwarded** (REALITY behaves outwardly as port forwarding, and it might be better if the target IP is unpopular).

What does it mean that TCP/80 and UDP/443 should be forwarded. Forwarded to where?
And how do we forward that traffic? I haven't found any example with Caddy and Reality, because Reality doesn't support H2c. So how can we forward TCP/80 and UDP/443?

Thanks

[chika0801]

Use the ping command on your VPS and ping the website address you provided in the "dest" field of your project to obtain its IP address.

There are many methods for forwarding, but I use the following command for forwarding.

Although the documentation states that this is an extra credit project, as far as I know, there aren't many people in China who use port forwarding for ports 80 and 443.

[chika0801]

apt install -y iptables-persistent

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination IP:80
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 443 -j DNAT --to-destination IP:443
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
netfilter-persistent save

查看
iptables -t nat -nL --line

删除
iptables -t nat -D PREROUTING 1
iptables -t nat -D PREROUTING 1
netfilter-persistent save

The purpose of these commands is better explained by asking ChatGPT.

[houmie]

Thank you Chika for your answer. That's very kind.

I'm familiar with iptables. But I didn't expect to see MASQUERADE for Xray:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

I thought this is only needed for OpenVPN and Wireguard. Because if you don't do this they won't work at all.
But right now on my XRay VPS, I don't use MASQUERADE and it still works.

Thank you, I will study your example further.

[chika0801]

I also googled and asked for gtp after I saw the advice in the official configuration notes. i don't know the rules of iptables, I would just ask chatgpt.

[chika0801]

I want to emphasize that these practices are plus items. I don't think there are many of us in China who use these extra credit programs either, and I personally don't use them.

[houmie]

Thank you @chika0801. Yes, that makes sense to me.

I have one more question, please. I hope to hear your opinion.

What is your opinion about all-in-one examples like this one

It is nice that they have fallback to a decoy website. But my worry is what if a user connects to a less secure protocol, and if GFW find out it will ban the whole VPS. So the other protocols in the all-in-one solution become worthless after that. Don't you think?
In other words the weakest link breaks the whole chain, if you know what I mean.

Maybe it's better to separate them and having only REALITY based protocols together on one server. For example VLESS+VISION+TCP+REALITY and VLESS+H2+REALITY.

And other protocols that are less secure like TROJAN, VMESS+WS on a separate server.

What do you think?
Thanks

[chika0801]

Maybe it's better to separate them and having only REALITY based protocols together on one server. For example VLESS+VISION+TCP+REALITY and VLESS+H2+REALITY.

And other protocols that are less secure like TROJAN, VMESS+WS on a separate server.

In China, my personal practice is that on the VPS server I use, I only open 1 proxy protocol, for example I use VLESS+VISION+TCP+REALITY combination, or VLESS+H2+REALITY, or they share one port (443) in 2 in 1.

I don't use it myself, and I don't recommend others to use a complex N-in-1 configuration on a total of one VPS server. The reasons I don't recommend it are: for example, Troajn+TCP+TLS protocol has TLS in TLS problem and uTLS fingerprinting problem. When it is shared with other protocols like VLESS+VISION+TLS, it appears that your VPS port (IP) is blocked and you don't know who caused it. In China, such N in 1 configuration, easy to cause online netizens cursing war (cause conflicts between different groups of proxy circle)

So my own configuration example, the configuration are single, I also put xxx + WS + TLS Trojan + TCP + TLS have been removed.

This is my personal opinion, for your reference.

[houmie]

I don't recommend others to use a complex N-in-1 configuration on a total of one VPS server. The reasons I don't recommend it are: for example, Troajn+TCP+TLS protocol has TLS in TLS problem and uTLS fingerprinting problem. When it is shared with other protocols like VLESS+VISION+TLS, it appears that your VPS port (IP) is blocked and you don't know who caused it.

Your opinion is important to me. Thank you for confirming this. I had exactly these thoughts and it makes sense to me how you explained it. 👍🏼 It seems complex N-in-1 configuration rely too much on decoy website. The decoy website is nice, but not sufficient when GFW has already found out about the protocol because of TLS-in-TLS or uTLS fingerprinting problem.

I have two more observations I would like to hear your opinion about:

1. Based on my research VLESS+VISION+TCP+REALITY is the safest option. But it seems VLESS+H2+REALITY is also popular, but why? Doesn't it have the TLS-in-TLS issue? Especially H2 is easier to detect. But I think it's faster, maybe that's a tradeoff between security and speed. But I'm not sure.

2. Another observation I have made is that VMess+WebSocket+TLS+CDN is still very popular. But VMess was compromised by GFW in 2020.

So why not using VLESS+Websocket+TLS+CDN instead? Wouldn't that be safer? Looking at XRay-core 1.8.3, it seems VMess is again improved. So it seems there is still a great interest in VMess. And I don't understand the reason.

Thank you

[chika0801]

My experience comes from feedback from users of Xray's Telegram and posts from users of this forum at hostloc.com. GFW refers to China's Internet censorship filtering firewall.They are all Chinese-speaking communities, which may be inconvenient for you to understand what is going on in China.

Here's a link to a collection of some of RPRX's speeches that are mentioned in there, take the time to read them if you're interested.

https://github.com/chika0801/Xray-examples/blob/main/warning.md

Based on my research VLESS+VISION+TCP+REALITY is the safest option. But it seems VLESS+H2+REALITY is also popular, but why? Doesn't it have the TLS-in-TLS issue? Especially H2 is easier to detect. But I think it's faster, maybe that's a tradeoff between security and speed. But I'm not sure.

VLESS+H2+REALITY and VLESS+gRPC+REALITY are the same effect (meaning multiplexing to reduce latency) H2 configuration because the RPRX return, by the way, the legacy of the historical H2 code to the revised, so now there are H2 and gRPC+REALITY 2, their role is the same, with which there is no difference. The RPRX view is that it is better to have more different proxies to facilitate the selection of the VPS ports. The RPRX view is that more different agents is a better choice. I don't know if the chance of your area being blocked with H2/gRPC is big, but I don't think it's big in China at the moment.

In the Xray community, the people who use them are mainly interested in the low latency they offer, for one thing. Another aspect is that there are other combinations, and some people like to try new ones at the same time.

[chika0801]

Another observation I have made is that VMess+WebSocket+TLS+CDN is still very popular. But VMess was compromised by GFW in 2020.

VMess+WebSocket+TLS+CDN The reason for the popularity is that there are many tutorials on the Chinese Internet to build proxy nodes, all mentioning this method, and you can search on youtube also have many tutorials to get started with the newcomers, always take the detour ahead, plus the netroots youtuber send videos to promote, so there have been many newcomers in the use of them.

VMess + WebSocket + TLS + CDN This combination also has tutorials on Hootsuite, teaching Chinese users to choose cloudflare free CDN service to use, and test the IP address of the faster cloudflare CDN.

Now the situation in China is that even if you use the CDN, VPS ports are not blocked, but the cloudflare CDN IP in China, but also become interfered with from time to time by the firewall, this interference generally refers to the speed is fast and slow, sometimes can connect, and sometimes can not connect. Because of the large area of China, China's firewalls in various cities on the cloudflare interference strength is different.

https://github.com/chika0801/Xray-examples/blob/main/warning.md#memo-5

You can see a link above, to the effect that the use of VMess + WebSocket + TLS VPS ports are blocked, such reports have been until now, there are still many people using this outdated combination, so RPRX said it is better to change to xxx + gRPC + TLS (CDN)

The VMESS protocol vulnerability has now been fixed, but using for example VMESS Shadowsocks + TCP in China results in the IP address of your VPS being blocked by the firewall not long after.

We have observed that with the combined form with TLS, the VPS is basically blocked when the port is blocked.

Although https://gfw.report/publications/usenixsecurity23/en/ has a report that using Shadowsocks + TCP still works in China. But our community is not pushing these traditional combinations with TCP anymore.

[chika0801]

Looking at XRay-core 1.8.3, it seems VMess is again improved. So it seems there is still a great interest in VMess. And I don't understand the reason.

Looking at XRay-core 1.8.3, it seems that VMess has been improved again. So it seems that there is still a lot of interest in VMess. I don't understand the reason for this.

The updates since Xray 1.8.X Although RPRX doesn't write an update log, the updates are generally stated in Xray's TELEGRAM channel, which you may not understand if you don't watch the community channel. As far as I know, there are no updates to the VMESS protocol either.

The new features added are all used by the VLESS protocol now. There are not many users in the XRAY community who use the VMESS protocol and discuss it.

[chika0801]

https://github.com/chika0801/tuic-install

https://github.com/chika0801/hysteria-install

If UDP protocol transmission is available in your area, in China, we also have a part of the network users try to use UDP protocol transmission of some proxy protocols, above is the example I made, you can find their github page.

[chika0801]

In China, for proxy agreements, the XRAY community is hoping for a hundred flowers and all kinds. The proxy protocol community should not attack each other (although this is not easy to do in the Chinese community, and still is, but we still want everyone to use each other) so Xray's TELEGRAM discussion group, any topic can be asked, in addition to Xray's, and sing-box platform, TUIC and Hysteria's.

In addition, we recommend you sing-box platform has a MUX function, we use H2Mux + padding to refer to it when communicating. He is currently used in China, the report was blocked VPS port case is rare (not to exclude the reason for not many people use) you can try. For an example of sing-box, see my link here

https://github.com/chika0801/sing-box-examples

[houmie]

Hello @chika0801

Sorry for my late response. I have been studying all these configurations. Thank you very much for providing all this information.

In the meanwhile I came across a problem. I can't block bittorrent.

I have seen this tutorial and have done the same thing.

Sniffing in inbounds is enabled:

"sniffing":{
            "enabled":true,
            "destOverride":[
               "http",
               "tls"
            ]
         }

Then under routes I have three rules:

"routing":{
      "domainStrategy":"IPIfNonMatch",
      "rules":[
         {
            "type":"field",
            "outboundTag":"block",
            "ip":[
               "geoip:ir",
               "geoip:private",
              ....
             ]
         },
         {
            "type":"field",
            "outboundTag":"block",
            "protocol":[
              "bittorrent"
            ]
         },
         {
            "type":"field",
            "outboundTag":"block",
            "domain":[
               "geosite:private",
               "geosite:category-ir",
               "ext:iran.dat:ir",
               "ext:iran.dat:other",
               "regexp:.*\\.ir$",
               ...
            ]
         }
    ]
}

I'm downloading the Ubuntu ISO torrent on my Android phone. It slows it down, but it can't block it.

Looking at the /var/log/xray/access.log I can see it's trying, but Bittorrent traffic still slips through sometimes. It can't block all of the connections.

2023/07/07 16:39:13 140.228.xx:32368 accepted tcp:51.159.4.xxx:55463 [block]
2023/07/07 16:39:13 140.228.xx:32012 accepted tcp:96.244.189.xxx:58946 [direct]
2023/07/07 16:39:18 140.228.xx:29768 accepted tcp:ipv6.torrent.ubuntu.com:443 [block]
2023/07/07 16:39:18 140.228.xx:29378 accepted tcp:torrent.ubuntu.com:443 [block]

Am I doing something wrong?

Many Thanks

[chika0801]

The Xray/v2fly core configuration checks for bittorrent protocols and blocks them, a feature that, as far as I know, was available a long time ago. But as we (Chinese community) know when discussing this feature, it's not very useful anymore for now, and we don't use it much on the server side. So I read your config file, the config file is correct, it's just that it currently works just that badly. How to stop bittorrent protocol traffic from downloading on the server side is also basically gone now that we are discussing it.

[seeker252]

Hello.
Today morning I thought, that I found some serious Reality volnurability. I hope to listen from you that I mistaken.
Look. Reality works as TLS 1.3 server and use SessionID for authenticate valid client connections. All requests from other clients transparently redirected to remote server by TCP. In TLS 1.3 SessionID must be random ir zero. Any TLS 1.3 server don't validate it. Ok. If third party (censor) change Reality client SessionID (with encrypted authentication data) in ClientHello with any 32 bit data for all TLS 1.3 Hellos to foreign IPs or IPs from grey lists, I think all legal (non-Reality) TLS 1.3 connections not be violated. We even can connect with our Reality VPS, but Reality server due to Session ID changed by third party will think about us as not valid Reality client and send our connection to remote server.
So censor no need to find Reality servers specially. He may mechanically change Session ID of TLS 1.3 ClientHello to any randon 32-bit value for some connections to some IPs and not violate any TLS 1.3 non-Reality connections. So HTTPs will work fine, but Reality don't.
Or I mistaken?