apernet
Reverse Tunnel
Hello. As a general script developer who develops filtering bypass scripts for Iranians, I have a request for you. In powerful firewalls like IR-GFW, in situations where international internet access is blocked, we rent servers located in Iran and make this server an intermediary between the user and the main foreign VPN server. In difficult situations, the firewall still blocks the IP of the foreign server. In this situation, the Iranian server cannot ping or communicate with the foreign server, but the opposite is possible, that is, the foreign server can initiate any communication with the Iranian server. I know that QUIC is a two-way connection, but the issue is the initiator of this connection. We need the Iranian server to play the role of the server and the foreign server to play the role of the client and a reverse tunnel to be created between them so that the Iranian server can perform port forwarding. Like what happens in frp, but we don't want to use frp. Because it is easily detected by the firewall. We want to use hysteria. I request you to add the reverse tunnel feature to Hysteria 2. Thank you.
same as #558
I just need the traffic to go directly to the Hysteria core using QUIC, not through SSH or anything else. SSH can easily be detected and blocked by firewalls. Using the Xray core is also a smarter workaround, but what I really want is for reverse support to be added directly to Hysteria.
A reverse proxy is valuable, especially when dealing with UDP ports. There are very few UDP proxy tools capable of bypassing firewalls. In issue #558, it was suggested to use WireGuard to achieve this. However, WireGuard cannot directly bypass the GFW. Testing showed that WireGuard forwarded through Hysteria2’s port mapping suffers from serious performance issues. Using iperf3 for testing, as shown in the figure: the lower result is from Hysteria TCP port forwarding, while the upper result is from establishing a WireGuard connection through Hysteria UDP port forwarding. The test was conducted within a local network. When crossing the GFW, the performance issues become intolerable. 反向代理是有价值的，尤其是面对UDP端口时。很少有能越过防火墙的UDP代理工具。#558 中提到使用Wireguard 来实现。但是Wireguard不能直接跨越GFW。经过测试，经由Hysteria2端口映射转发的Wireguard有严重的性能问题。使用iperf3测试，如图，下面是Hysteria tcp端口转发的结果，而上面是经过Hysteria udp端口转发建立Wireguard连接的结果。测试在内网进行。当跨越GFW时，性能问题难以忍受
Of course, it would be even better if the developer is willing to investigate the performance issues of WireGuard working with Hysteria2. The bidirectional access experience of WireGuard is second to none. 当然，如果作者愿意追踪Wireguard与Hysteria2合作的性能问题就更好了。Wireguard的双向访问体验无出其右。
@chenxudong2020
如果是去程 CN2 ， 回程 163 的情况， 支持了 Reverse Tunnel 也没有用。 Reverse Tunnel 又不会改变传输路径。
反向代理的意义是国外vps线路回国垃圾，用，用反向代理可以利用hy2协议进行提速，如果无法提速的话还不如使用ws套cf
I think you are not familiar with reverse tunnel.
Whether the connection is reverse or direct has no bearing on speed (bandwidth and latency).
In reverse tunnel, the connection is initiated from server to client instead of client to server. So if the external server IP is blocked In normal mode Hysteria2 cannot connect
But if the connection is initiated from external server (like reverse tunnel in Xray-core) Even if the external server IP is filtered The connection will still be established properly.
(Client means: the intermediate server between the end user and the external server (server hosted in Iran or China))
@CalunVier Could you help testing udpdeminer + hy2 with this method? You can also customize the initial punching packet content CMD_PUNCH = 0x05 here , or from original file. udpdeminer is close-sourced currently, use it at your own choice.
@ParsaKSH For NAT Traversal, the connection can be initiated from both sides. You can DROP -m conntrack --ctstate NEW incoming packages on the server side to simulate the reverse connection with this method?
反向代理的意义是国外vps线路回国垃圾，用，用反向代理可以利用hy2协议进行提速，如果无法提速的话还不如使用ws套cf
I think you are not familiar with reverse tunnel.
Whether the connection is reverse or direct has no bearing on speed (bandwidth and latency).
In reverse tunnel, the connection is initiated from server to client instead of client to server. So if the external server IP is blocked In normal mode Hysteria2 cannot connect
But if the connection is initiated from external server (like reverse tunnel in Xray-core) Even if the external server IP is filtered The connection will still be established properly.
(Client means: the intermediate server between the end user and the external server (server hosted in Iran or China))
did you find any solution for this problem. not added reverse port forwarding to hy2 yet ?
did you find any solution for this problem. not added reverse port forwarding to hy2 yet ?
نه برادر اضافه نشده
did you find any solution for this problem. not added reverse port forwarding to hy2 yet ?
نه برادر اضافه نشده
راهی نیست این رو ریورس بزنیم . خیلی وضغ خرابه
@ParsaKSH @hadi-dindar FYI: https://github.com/apernet/hysteria/discussions/1369
@ParsaKSH @hadi-dindar FYI: #1369
I studied your project It was interesting but still not the solution to the main problem. As I understand it, your script opens a simple udp connection from the server to the client in reverse and then any other connection passes through this tunnel.
The main problem is this, the feature of Hysteria2 is that the initial connection and handshake are of the QUIC type, which is very difficult or even impossible to detect for powerful firewalls. But your project opens a simple udp connection, which itself can be easily detected and blocked.
In any case, your project can be very useful, but not for solving this problem Good luck.
راهی نیست این رو ریورس بزنیم . خیلی وضغ خرابه
تو این شرایط که از طرف زیرساخت روی 99درصد رنج آیپی ها بستر udp رو از بیخ بستن
کلا تانل های udp بیس برای شرایط جنگی تو ایران بدرد نمیخورن تقی به توقی میخوره سریع udp رو میبندن
راهی نیست این رو ریورس بزنیم . خیلی وضغ خرابه
تو این شرایط که از طرف زیرساخت روی 99درصد رنج آیپی ها بستر udp رو از بیخ بستن
کلا تانل های udp بیس برای شرایط جنگی تو ایران بدرد نمیخورن تقی به توقی میخوره سریع udp رو میبندن
الان یک ای پی ترکیه من تست کردم روش هیستریا وصل میشد. و بلاک هم نبود در حال حاضر که بازه و تشخیص این پروتکل برای فایروال سخته میشه استفاده کرد و سرعت خوبی هم میده
در زمان جنگ هم شرایط متفاوته . اگه کل نت بسته بشه از داخل و خارج پینگ نده هیچ راهی نیست
دقیقا مشکل اینجاست باید این ریورس بر روی خود هسته هیستریا اضافه بشه نه اینکه یک ارتباط یو دی پی ساده ایجاد بشه که اونو فایروال بسادگی میفهمه
which itself can be easily detected and blocked.
You can enhance it to send/receive whatever to make the powerful firewall happy during the punching procedure. Here is some suggestions you can take, and these attempts might fail if the powerful firewall checks every package. because the QUIC connection comes after link2lan exit.
For a single trip case, just send any data you wish, and tell the other side via ntfy to do following stuff, like plan 102 does.
For a round-trip case, which is complex depending on how strong you are going to build. Here is one example of reverse initiation: Direction from VPS to PC, select plan 201 with natype=4, change to mapaddr.push_str("external ip:port") to let the PC know the real destination. modify and call crudestunclient() to send whatever to PC. Direction from PC to VPS, select the plan 101, modify crudestunserver to reply whatever back to make the powerful firewall happy.