Unfortunately, current Xray-core features do not help the current situation in Iran.
Currently, dns-tunnel and some manipulations in IP-header (or just TCP-header in some cases) are communication methods
Although manipulation in IP/TCP headers cannot be permanent methods, in any case, Xray-tun should also support raw mode and not necessarily convert tcp-raw to tcp-stream and also support other protocols in raw mode (icmp, icmpv6, ...)
Later, outbounds appropriate to raw such as spoof and ... can be added, also users can easily implement their own method.

also, at least a basic dns-tunnel should be added.

DNS、ICMP 这两个 udpmasks 倒是有计划，IP/TCP header 挺新鲜的，实现起来也是 udpmasks 的范畴

Xray-core 加这些真的不会导致这些方法一夜暴毙吗

@Fangliding 有些人提到的 TUN 用久了会卡是不是可能和没 cancel ctx 有关

idk 我也没看过刨析文件 不过加个cancel是对的

@Fangliding 有些人提到的 TUN 用久了会卡是不是可能和没 cancel ctx 有关

2dust/v2rayNG#5057 (comment)

in v2rayNG, hev-socks5-tunnel wasn't working after a while, that was because default UDP-timeout was set to 300s and we had many DNS requests during this time and that would cause the program to crash, changing UDP-timeout to 60s solved the problem.

I haven't read the TUN and TUN-FullCone codes yet, and i can't help more.

加个 cancel 是对的，不过似乎没看到真的有人开 issue 说“TUN 用久了会卡”的问题，这个 2dust/v2rayNG#5175 不像是 core 的问题

I hadn't encountered this problem either. I just saw the issue and took a quick look at the code and saw that it had this minor-problem, and fixed it.

This just adds a cancelable context layer on top of existing context, that lives during handling, and then canceled after.
It kind of make no real difference to handling, it's just a thing that starts with it and ends with it.
Handling itself is taking care about lifecycle - routed connection will end when uplink ends it, tun connection will end when handling ends (defer conn.Close() is called).
This change changes really nothing...
For cancellable context to be functional the "cancel" method it provides should be called as a reaction on something (uplink timeout, downlink timeout, internal timeout...), just calling "cancel" on it at the end serves no purpose...

不过鬼知道哪里有没有 go 了一个协程在 conn closed 后还在跑，所以加个 cancel 是对的，逻辑跟入站 worker 对齐

Only if "cancel" is called somewhere during context lifecycle, and in this change it's not called until end of function where context goes out of scope anyway.
I'm not saying this breaks something, it just does nothing in my humble opinion. It's just another context layer that is initialised and then canceled when function ends. Everything that could have grabbed that context to monitor its state will already be done and released when cancel is called.
Just saying that it doesn't look like it is doing anything for me. Maybe I'm missing something, happens.

Everything that could have grabbed that context to monitor its state will already be done and released when cancel is called.

属于是低估了 *ray 代码的屎山程度，太多人写了太多东西了，不得不防一手

Just saying that it doesn't look like it is doing anything for me. Maybe I'm missing something, happens.

而且我依稀记得可能某些代码靠的就是 worker cancel ctx 来实现关闭的，写的时候发现反正有 w.c.c. 兜底那就依赖它吧，但没注释