add Reverse Tunnel support

[AkramiPro]

My isp block all outbound requests but the inbound is open . so i can listen on 443 port in my client server it is good to add ability to connect from remote server to client server in normal use we connect from client to remote server but if isp block outbound 443 in client we can not connect to remote anymore but many isp's allow incoming 443 request so if you please add this feature so we can connect from remote server to the client then client can send requests to the remote server by Reverse Tunnel thank you

[haruue]

You can forward the sshd port of your remote server with hysteria (tcpForwarding), and use ssh reverse tunnel (ssh -R).

[AkramiPro]

Thank you for your reply But ssh is not stable and have many problems like tcp on tcp I think it is better to add this internally in hysteria core You help many people to access uncensored internet by add this. Please see this project : https://github.com/snsinfu/reverse-tunnel

[haruue]

If you just want to reverse proxy your local tcp 443 port to the remote server, there's no TCP over TCP problem. TCP over TCP happens when you run a layer 3 tunnel over a TCP proxy. However, ssh -R is not a layer 3 tunnel, it is pure layer 4.

[AkramiPro]

No I think I made a mistak in explain what I need Please forget prev conversation I try to explain the problem again Currently the tunnel start from client to remote server But GFW block outbound in client server and the tunnel can not start But we can solve this problem if tunnel start from remote to client Because currently GFW allow income connections from remote server so if remote server try to connect client we can bypass GFW I hope you understand what I mean Sorry for my bad English

[haruue]

我可以跟你说中文。

我明白你是在本地的 443 端口开了一个 HTTPS 服务器， 并且希望能把本地的 HTTPS 服务通过 Hysteria 服务端开放到公网（部分文章会把这类操作称为「内网穿透」）， 并且希望这种情况下 Hysteria 还能加速这种「反向访问」的流量。 事实上这个需求可以通过 hysteria 搭配服务器上的 sshd 轻松实现。

首先， 用 Hysteria 的 tcpForwarding 功能转发服务器的 sshd 端口（22）， 这样就能通过连接 Hysteria 开在本地的转发端口来访问服务端的 ssh。 例如， 在 Hysteria 客户端的配置文件中添加

tcpForwarding:
  - listen: 127.0.0.1:10022
    remote: 127.0.0.1:22

这样配置之后， 你在本地运行 ssh root@127.0.0.1 -p 10022 ， 就能连接上远程服务器的 ssh。

接下来， 你需要在服务端 sshd 配置文件中加上 GatewayPorts yes 来允许 sshd 监听由客户端指定的远程端口。 然后使用下面这个命令， 将访问远程服务器的 443 端口的请求转发到本地机器的 443 端口， 并且所有请求都是通过 Hysteria 加速的。

ssh -NR 443:127.0.0.1:443 root@127.0.0.1 -p 10022

你可以查阅 man:ssh(1) 或者通过 Google 搜索「ssh 反向代理」来获取更多关于使用 ssh 配置反向代理的帮助， 网上的相关教程都非常详细， 例如你可以用 autossh 等工具配置成在 ssh 断开时重连。

Hysteria 是一个代理工具， 协议上不支持也不会打算支持逆向代理， 因为服务端通常都不会允许客户端在服务端开放端口（若要实现也会需要额外的鉴权）。

[AkramiPro]

thank you for your reply but i do not need port forward this is my mistake that mention port forward in my example on client side i need to create socks5 so i can handle client requests by socks5 so i need normal hysteria use with socks5 on client but the tunnel need to start from [remote to client] not from [client to remote] to bypass GFW

client must listen on 443 and remote must request on client 443 port to open tunnel then a socks5 on client must handle all requests

if you add this, many users can bypass GFW easily 😊

this is the config that i need:

Remote Server Config (192.168.1.30)

server: 192.168.1.60:443

fastOpen: true

tls:
  sni: test.com
  insecure: true

auth: xxxx

resolver:
  type: tcp
  tcp:
    addr: 8.8.8.8:53
    timeout: 4s

ignoreClientBandwidth: true

Client Server Config (192.168.1.60)

listen: :443

auth:
  type: password
  password: xxxx

tls:
  cert: /root/cert.pem
  key: /root/key.pem

socks5:
  listen: 127.0.0.1:1080

curl --socks5-hostname 127.0.0.1:1080 ip.gs
192.168.1.30

[AkramiPro]

any idea? 😢

[us254]

A reverse tunnel is a type of connection where the server initiates the connection to the client, rather than the usual client-to-server connection. Both port forwarding and a SOCKS5 proxy can be used in the context of a reverse tunnel, but they serve different purposes:

1. Reverse Port Forwarding: In this case, the server initiates a connection to a specific port on the client. The client then forwards traffic from this port to a specific port on the server. This allows a specific service on the server to be accessed from the client, even if the client is behind a firewall or NAT.

2. Reverse SOCKS5 Proxy: Here, the server initiates a connection to the SOCKS5 proxy running on the client. The client can then use this connection to send any type of network traffic to the server. The server relays this traffic to the target server, and then sends the response back to the client through the reverse tunnel. This allows the client to access any service on the internet, not just a specific service on the server.

In AkramiPro's request, they want to set up a reverse SOCKS5 proxy, not just reverse port forwarding. This is because they want to be able to handle any type of network traffic, not just traffic to a specific port.

[AkramiPro]

please see this project this is what i mean:

https://github.com/fatedier/frp

[aa51513]

As we all know, quic is a two-way protocol. When we talk about the server and the client, we are actually talking about the process of connection creation. After the connection is successfully established, there is no need to distinguish between the server and the client. 众所周知，quic是一个双向协议，当我们在说服务端和客户端的时候，我们其实是在说连接创建的过程，在连接建立成功后，是不需要区分服务端和客户端的。

In my opinion, Hysteria should regard itself as a tunnel and weaken the distinction between the concepts of server and client. 在我看来，Hysteria应该把自己视为一个隧道，而弱化服务端和客户端的概念的区别。

So I actually don’t quite understand what the previous speakers want to say? 所以我其实不太明白前面发言的诸位，到底是想表达什么？

Why a two-way quic tunnel is not enough to run a socks5 server on the client, with the server as the entrance? 为什么一个双向的quic隧道，不足以支持在客户端运行一个socks5 server，以服务端作为入口？

If I understand something not enougth, please point it out, I would be very grateful 如果我有理解错误的地方，请指出，我将非常感激

[AkramiPro]

As we all know, quic is a two-way protocol. When we talk about the server and the client, we are actually talking about the process of connection creation. After the connection is successfully established, there is no need to distinguish between the server and the client. 众所周知，quic是一个双向协议，当我们在说服务端和客户端的时候，我们其实是在说连接创建的过程，在连接建立成功后，是不需要区分服务端和客户端的。

In my opinion, Hysteria should regard itself as a tunnel and weaken the distinction between the concepts of server and client. 在我看来，Hysteria应该把自己视为一个隧道，而弱化服务端和客户端的概念的区别。

So I actually don’t quite understand what the previous speakers want to say? 所以我其实不太明白前面发言的诸位，到底是想表达什么？

Why a two-way quic tunnel is not enough to run a socks5 server on the client, with the server as the entrance? 为什么一个双向的quic隧道，不足以支持在客户端运行一个socks5 server，以服务端作为入口？

If I understand something not enougth, please point it out, I would be very grateful 如果我有理解错误的地方，请指出，我将非常感激

in many firewalls (Like IRAN GFW) they block outgoing request but they allow incoming request so if we start tunnel from remote server to client we can bypass firewall and tunnel established successfully i give you example to understand what i mean

from x.x.x.x (Iran) ping y.y.y.y ---> timeout

from y.y.y.y (Germany) ping x.x.x.x ---> 70ms

so we can only establish connection from Germany to Iran but all request from Iran to Germany all blocked. an revers tunnel like frp is good example that i use for many month if hysteria add some options to establish tunnel like frp many users can bypass GFW

[shakibamoshiri]

The term "reverse tunnel" is like what SSH reverse port-forwarding does.
In normal SSH port-forwarding (-D IP:PORT) requests are forwarded from local to remote
In reverse SSH port-forwarding (-R IP:PORT:IP:PORT) request are forwarded from remote to local

This feature is not a strange or new one. SoftEther VPN already has this feature and it is called "Cascaded Connection". With this feature we can chain multiple SE servers.

Also Xray has this feature with which if from A to B a connection cannot be made , we can make a connection from B to A but traffic comes though B via A

In some countries (e.g Iran) their firewall blocks outbound traffic. For example at the moment Wireguard from Iran to outside has been blocked. But from Germany to Iran we can have Wireguard connections.

A simple model

# blocked by GFW
[ client (openvpn) ] ==> [ hop-1 ( SE ) ]

# blocked even with domestic network
[ client (openvpn) ] ==> [ hop-1 ] ==>  [ hop-2 ( SE ) ] 

# fine (with NAT-Traversal)
[ client (openvpn) ] <== [ hop-1 ( SE ) ]

# fine
[ client (openvpn) ] ==> [ hop-1 (SE) ] <==  [ hop-2 ( SE ) ]