HTTP/2 CONNECT 可以用作反向隧道吗？

Question

是否可以使用 HTTP/2

CONNECT

或 HTTP/3 QUIC

CONNECT

连接作为反向隧道，以便服务器端可以多路复用 HTTP 请求沿着隧道返回到连接发起者？

这需要 HTTP 服务器能够在客户端发起的连接上创建新流。

或者 HTTP/2

CONNECT

流严格由客户端发起和客户端控制？

---

背景：

我希望将 NAT 主机上的服务公开给中央控制中心。边缘服务和控制中心都位于独立的 k8s 集群上。只有中央集线器具有公共可路由 IP 地址。

大多数支持服务发现和虚拟服务的 k8s 原生东西向路由和服务网格选项都无法使用，因为 Istio 和 Consul 等工具需要相互可达性。

我知道典型的选项，例如

ssh -R

、wireguard VPN 等，但由于各种原因，它们在这种环境中会很尴尬且难以使用。基于 HTTP+TLS 的东西会工作得更好。例如，我可以通过 HTTP CONNECT 建立隧道 ssh，然后使用 ssh 反向隧道传输请求，但分层可能会对 TCP 造成丑陋的影响。

我一直在研究是否可以将 Envoy 代理配置为接受来自外部服务的入站 HTTP/2

CONNECT

，然后使用该入站连接作为侦听器来路由其他请求。但我找不到任何迹象表明这是可能的。

（基于对 Teleport 代码的快速阅读，Teleport Proxy 使用 ssh 协议作为到 Teleport Agent 的反向隧道。有一个“inlets pro”工具可以通过 HTTP 执行类似的操作，但看起来像是 1:1 隧道只是。我还没有找到像简单工具这样的工具来通过客户端启动的 HTTP 隧道公开 SOCKS 代理，或者通过客户端启动的 HTTP 隧道进行远程端口转发（ssh -R 样式）。）

Answer 1

答案似乎是“不，不能”。您需要一个命令和控制通道，客户端可以在其中对“服务器”端进行长轮询。服务器通过控制通道发出对新通道的请求，然后客户端发起这些请求。

尚不清楚这是否可以在服务器端通过 QUIC 或 WebSockets 使用 HTTP/3，但对于 HTTP/2 来说，这看起来像是“不”。