本手册让一个感知代理的应用程序使用已有的 WireGuard 通路,而不在 VPN 服务器或互联网上发布代理端口。SOCKS 守护进程提供应用接口,WireGuard 提供已获批准的 IP 通路,两者都不会替你完成用户认证。下面每一步都产出可检查的东西,且都有回退方式:停止实例、删除规则,或去掉应用的代理设置。这里没有任何操作会改动主机的默认路由。

示例假定 Dante 1.4.x 以专用、受管实例的形式安装在可信的 Linux 工作站上,并保留软件包提供的服务账号与日志配置。工作站在其 WireGuard 接口上拥有 10.77.0.2,经该隧道到达 10.60.0.20:443,而服务的正式名称是 app.corp.example。

第 1 步:把监听只绑定到 loopback

把网络、方法与规则三段写入实例的活动配置,替换示例地址。所有服务器设置都放在规则块之前:

internal: 127.0.0.1 port = 1080
external: 10.77.0.2
external.protocol: ipv4
clientmethod: none
socksmethod: none

client pass {
    from: 127.0.0.1/32 to: 127.0.0.1/32
}

socks pass {
    from: 127.0.0.1/32 to: 10.60.0.20/32 port = 443
    command: connect
    protocol: tcp
}

这只是一个片段,不能替代软件包的用户与日志设置。挑一个未使用的本地端口,并确认这个专用实例没有其他监听、没有更宽的放行规则,也没有会改变契约的上游串联条目。如果旧配置留下了一条 socks pass 而没有目标限制,就在做任何测试之前把它删掉。

这一步的回退是停止实例;回退期间配置文件可以留在磁盘上。

第 2 步:写两条规则,而不是一条

Dante 的 配置参考 给两类规则分配了不同职责。客户端规则允许连接到 loopback 监听,其目标就是监听自身的地址。SOCKS 规则允许所请求的继续连接前往获准的主机与端口。不匹配的请求默认被阻止,所以缺少规则看起来与路由损坏一模一样。

注意这份配置有意不做什么:它不要求 SOCKS 密码。这适合可信的本地主机,但它不是用户认证。该机器上的任何其他进程同样可以使用 loopback。保留远程应用自身的认证,不要把这种无认证形态复用到不可信的本地用户或面向局域网的监听上。

第 3 步:从正确的源验证路由

external 只选择出站源地址,并不安装 WireGuard 路由。针对示例源与目标的只读查询:

ip -4 route get 10.60.0.20 from 10.77.0.2

要在 Dante 实际的网络命名空间里执行,而不是在你随手打开的某个 shell 里。路由、WireGuard 对端选择、远端许可与返回路径都必须与那个源地址相符。查询成功是必要条件而非充分条件,因为它完全不能说明远端是否接受请求。

不要为了查询成功就去加默认路由。代理端口只存在于这台工作站上;为了让端口存在而改动主机默认路由,等于把整个设计颠倒过来。

第 4 步:用预期的身份测试

所有者验证已安装的配置并通过服务管理器启动实例之后,一个示例请求是:

curl --proxy socks5h://127.0.0.1:1080 --noproxy '' https://app.corp.example/

使用 socks5h 时,Dante 负责解析目标,但 Dante 运行在这台工作站上,所以 该设置本身并不会把 DNS 送到隧道远端。Dante 使用的、已获批准的解析器必须为该名称返回被允许的地址。空的 no-proxy 列表可防止继承来的例外悄悄绕过 SOCKS。

测试中要保留 HTTPS 主机名与证书校验,然后检查实际监听并确认契约的两半:被放行的请求成功,被排除的目标失败。还要确认不支持的转发命令仍被拒绝,因为该片段只允许 TCP 上的 SOCKS CONNECT 命令,不含任何类似通用 UDP 或整机隧道的东西。

第 5 步:决定隧道断开时会发生什么

把它称为生产之前,先测试隧道丢失与实例重启。先启动 WireGuard 再启动 Dante 的守护管理并不会造成 fail-closed 路由,也不会造成 fail-closed DNS;两者都必须由网络所有者落实。观察隧道断开时应用的行为:干净的错误是好结果,悄悄回落到公共解析器则不是。

如果绑定的隧道地址发生变化,要协调更新,因为 external 就钉在这个地址上。当这套安排不再需要时,把这个实例与应用的代理设置一起退役,并把 WireGuard 通路留给它的所有者。

相关文章