2.7 KiB
| title | date | tags | draft | summary | ||||
|---|---|---|---|---|---|---|---|---|
| 利用 SNI 路由 TLS 连接实现端口复用 | 2022-09-08 |
|
true | 通过 SNI 反向代理，实现 VLESS 与 Web 站点共享 443 端口。 |
前言
这次的目标是通过 TLS 的 SNI 来实现对 TLS 连接的路由，以实现 SD LAN 中的 VLESS 连接与 HTTPS 连接复用 443 端口。 如此一来，我在外访问家庭网络内的非 Web 服务时，能够很轻松地通过防火墙，因为 443 端口作为 HTTPS 默认端口，并且通过 VLESS 隧道访问的流量特征与 HTTPS 流量特征相同，有效避免被误杀。
试错
因为苦 Nginx 久矣，所以我近一年来都在用 Caddy 2，而这次也是因为 Caddy 2 生态不够强大，所以绕了一圈。
Caddy 反向代理 Xray
Caddy 标准版本不提供 TCP 或 TLS 反向代理的能力，但是它有一个非官方的模块支持四层反向代理——mholt/caddy-l4: Layer 4 (TCP/UDP) app for Caddy。 Caddy L4 支持 TCP 和 UDP 反向代理。但是，它目前为止还不支持 Caddyfile 配置，只能通过 JSON 配置。这就不友好了，我也就干脆地放弃这方案了。
Xray 反向代理 Caddy
Xray 的 VLESS 协议支持回落功能，能让非 VLESS 连接传递给后备服务。将 Caddy 作为后被服务，则能让 HTTPS 连接交由 Caddy 处理。
这个方案还行，首先，流量特征与 Caddy 差异小，这得益于都是 Go Lang 开发的程序；其次是性能损耗也可接受。唯一的问题就是，签发的泛域名证书只是 *.ivanli.cc，所以 443 端口只能部署 *.ivanli.cc 的站点，部署主域或者三级域名之类的站点将会报证书错误。所以这个方案也 pass 掉了。
在 Caddy 和 Xray 之前路由
使用一个支持 TLS SNI 路由的程序将连接按 SNI 反向代理到 Caddy 或 Xray 中。这个方案没啥局限性，就是浪费了些性能，增加了些延迟。我能接受，毕竟咱有追求不是？
那接下来就用这个方案来实现，那个路由就由 SNI-Proxy 来实现。
技术栈
SNI Proxy
dlundquist/sniproxy 是一款支持对 HTTP 和 TLS 连接按虚拟主机名转发流量的反向代理程序。 对于 TLS 连接，它通过 SNI 进行区分并按规则转发到对应的端口，并不需要对 TLS 进行解密。并且它支持 HAProxy 代理协议将原始源地址传递给后端。
VLESS
VLESS 是一种安全高效的数据传输协议，其支持的 xTLS 协议非常适合作为网络隧道传递 TLS 数据，能够极大地降低网关计算资源。