rathole 怎么配置 websocket 传输层并复用 TLS 设置？-育师

rathole 怎么配置 websocket 传输层并复用 TLS 设置？

【免费下载链接】ratholeA lightweight and high-performance reverse proxy for NAT traversal, written in Rust. An alternative to frp and ngrok.项目地址: https://gitcode.com/GitHub_Trending/ra/rathole

如果你已经用 rathole 把 NAT 后面的服务暴露到公网，现在想把传输层换成 websocket，同时不想重新准备一套证书、而是直接复用已有的 TLS 设置，核心就是两处改动：把[client.transport]/[server.transport]的type设成"websocket"，再在[*.transport.websocket]里把tls设为true，让它套用同一个transport下tls块的证书配置。

本文基于 rathole 的完整配置说明、传输层文档、TLS 示例与仓库内的 websocket TLS 测试配置，给出从准备证书到验证转发打通的一条连续路径。

前提：websocket 传输需要对应特性编译进二进制

rathole 的 websocket 能力由 Cargo.toml[features]决定：

默认特性包含websocket-native-tls（依赖native-tls），因此从 release 页拿到的默认构建、以及cargo build --release的产物已带 websocket + TLS 能力。
若改用 rustls，需同时启用websocket-rustls（依赖rustls）。构建指南给出的命令：

cargo build --release --no-default-features --features server,client,rustls,noise,websocket-rustls,hot-reload

注意：rustls/websocket-rustls与native-tls/websocket-native-tls互斥，同时开启会编译报错。使用 rustls 构建时，未启用websocket-rustls则 websocket 能力不随二进制编译。

准备被复用的那份 TLS 设置

websocket 的tls = true会直接读取同一transport下的tls块，所以先把这套 TLS 设置准备好，它和普通 TLS 传输用的是同一份材料（见传输层文档）：

服务端——需要 PKCS#12 归档（含服务端证书与私钥）。文档给出的 openssl 命令：

openssl pkcs12 -export -out identity.pfx -inkey server.key -in server.crt -certfile ca_chain_certs.crt

参数：-inkey服务端私钥、-in服务端证书、-certfileCA 证书。若用 rustls 构建，p12crate 只支持有限的 PBE 算法，需用 openssl 3 加-legacy生成旧格式：

openssl pkcs12 -export -out identity.pfx -inkey server.key -in server.crt -certfile ca_chain_certs.crt -legacy

客户端——需要信任签发服务端证书的 CA，trusted_root指向根 CA 的 PEM 证书文件；hostname是客户端校验证书用的主机名，文档说明它不要求与[client]的remote_addr相同。

仓库 TLS 示例提供现成的证书材料（rootCA.crt、identity.pfx、server.crt、server.key），并附带一个生成自签证书供参考的脚本。

服务端配置：websocket + 复用 tls 块

在服务端配置文件里，把transport的type设为websocket，保留transport.tls块，并在transport.websocket里设tls = true：

# server.toml [server] bind_addr = "0.0.0.0:2333" default_token = "default_token_if_not_specify" [server.transport] type = "websocket" [server.transport.tls] pkcs12 = "examples/tls/identity.pfx" pkcs12_password = "1234" [server.transport.websocket] tls = true [server.services.echo] bind_addr = "0.0.0.0:2334"

type = "websocket"指定使用 websocket 传输。
pkcs12/pkcs12_password是tls = true时被复用的证书配置。
tls = true表示 websocket 连接套用上面tls块的 TLS 设置；设为false则 websocket 不带 TLS。

上面pkcs12路径与密码沿用文档中的示例证书（websocket TLS 测试配置使用同样的examples/tls材料与密码1234）。实际部署请替换为你自己的归档路径与密码，并把bind_addr端口改成要暴露的端口。

客户端配置：type 同样设为 websocket

客户端与服务端对齐，type也设为websocket，tls = true复用自己的tls块：

# client.toml [client] remote_addr = "127.0.0.1:2333" default_token = "default_token_if_not_specify" [client.transport] type = "websocket" [client.transport.tls] trusted_root = "examples/tls/rootCA.crt" hostname = "localhost" [client.transport.websocket] tls = true [client.services.echo] local_addr = "127.0.0.1:8080"

remote_addr的端口必须与服务端server.bind_addr的端口一致（这里都是2333）。
default_token（或服务级token）两端必须一致才能通过校验。
hostname用于证书校验，不要求等于remote_addr。

服务端与客户端的type、tls设置要对齐：一端 websocket 而另一端是普通 tcp/tls，连接无法按预期建立。

运行

分别用配置文件启动两端（rathole 会按文件内容自动判断运行模式；若[client]与[server]放在同一文件，则用--server/--client显式指定）：

./rathole server.toml ./rathole client.toml

日志级别可通过环境变量控制，例如RUST_LOG=error ./rathole config.toml只输出错误。

验证转发是否打通

按快速上手的转发模型：客户端连上服务端后，任何发往服务端服务bind_addr端口的流量都会被转到客户端的local_addr。以文档 quickstart 为例——服务端把服务暴露在5202、客户端本地服务在127.0.0.1:22，打通后即可ssh myserver.com:5202访问 NAT 后面的机器。

对照本文配置（websocket TLS 测试配置的示例值）：流量发往服务端0.0.0.0:2334（echo服务）应到达客户端127.0.0.1:8080，发往0.0.0.0:2335应到达127.0.0.1:8081。文档中这些127.0.0.1地址是本地回环示例值，真实部署请换成你的服务地址。

限制与排查

websocket 特性由websocket-native-tls（默认特性包含）或websocket-rustls提供；rustls 与 native-tls（含对应 websocket 特性）互斥，同时开启会编译失败。
rustls 读取 PKCS#12 受 PBE 算法限制，须用 openssl 3 加-legacy生成归档。
transport.websocket的tls字段决定 websocket 是否套用tls块：true复用 TLS 设置，false为不带 TLS 的 websocket（见纯 websocket 测试配置）。
客户端证书校验依赖trusted_root（签发服务端证书的 CA 证书）与hostname（校验用主机名，文档说明其不要求等于remote_addr）。