OpenZiti 入门（21）：通过远端节点访问指定 HTTPS 服务

前面我们用 OpenZiti 访问了自己部署的应用。本篇尝试另一种场景：在一台能够访问目标站点的远端服务器上运行 ziti-host，让指定客户端经该服务器访问特定 HTTPS 域名。

text
客户端访问指定域名
  → OpenZiti 网络
  → 远端 ziti-host
  → 目标 HTTPS 服务

本文先用 api.ipify.org 做验证：它会返回请求所使用的公网 IPv4 地址，便于对照远端节点的出口地址。随后再说明如何换成自己的目标域名。ipify 官方说明介绍了该测试接口。

一、准备条件

需要以下资源：

• 一套客户端和远端服务器都能访问的 OpenZiti 网络，例如第 7 篇的公网网络。
• 一台已经加入该网络的 Linux 客户端，例如第 16 篇的 ubuntu-ssh-client。
• 一台远端 Linux 服务器，已安装 Docker 和 Compose，能够访问目标 HTTPS 服务。
• 客户端和远端服务器都能连接 Controller 的 Edge API 与至少一个 Edge Router。

第 17 篇的 Docker 实验默认把端口绑定在 127.0.0.1，因此远端服务器不能直接使用那套默认地址注册。若使用 Docker 部署的网络，需要事先规划客户端可解析、可到达且与证书匹配的 Controller 和 Router 地址。

二、创建远端身份和指定域名服务

在 Controller 所在主机登录 ziti CLI。以下沿用第 7 篇 Quickstart 的方式：

bash
source "$HOME/.ziti/quickstart/$(hostname -s)/$(hostname -s).env"
zitiLogin

创建远端节点身份：

bash
umask 077

ziti edge create identity remote-outbound \
  -o remote-outbound.jwt

创建客户端拦截配置，只匹配 api.ipify.org 的 TCP 443：

bash
ziti edge create config remote-ip-intercept intercept.v1 \
  '{"protocols":["tcp"],"addresses":["api.ipify.org"],"portRanges":[{"low":443,"high":443}]}'

创建远端连接配置：

bash
ziti edge create config remote-ip-host host.v1 \
  '{"protocol":"tcp","address":"api.ipify.org","port":443}'

关联服务，并授权指定身份：

bash
ziti edge create service remote-ip-test \
  --configs remote-ip-intercept,remote-ip-host

ziti edge create service-policy remote-ip-dial Dial \
  --identity-roles '@ubuntu-ssh-client' \
  --service-roles '@remote-ip-test'

ziti edge create service-policy remote-ip-bind Bind \
  --identity-roles '@remote-outbound' \
  --service-roles '@remote-ip-test'

如果客户端使用的是第 8 篇的 Windows 身份，可把 @ubuntu-ssh-client 换成 @windows-laptop。

intercept.v1 决定客户端匹配哪些地址和端口；host.v1 决定远端节点连接哪个目标。本例把目标固定为一个域名和端口。配置类型说明和 host.v1 说明介绍了这些字段。

三、在远端服务器启动容器

通过安全的现有管理通道，把 remote-outbound.jwt 传到远端服务器。

在远端服务器创建目录，并将 JWT 放入该目录：

bash
mkdir -p ~/ziti-site-egress
cd ~/ziti-site-egress

创建 compose.yaml：

yaml
services:
  ziti-host:
    image: openziti/ziti-host
    restart: unless-stopped
    environment:
      - ZITI_ENROLL_TOKEN
    volumes:
      - remote-identity:/ziti-edge-tunnel

volumes:
  remote-identity:

首次启动时，将 JWT 内容交给容器：

bash
export ZITI_ENROLL_TOKEN="$(< ./remote-outbound.jwt)"

docker compose up -d
docker compose logs --tail=80 ziti-host

确认日志显示身份已注册并连接网络。也可以检查身份文件是否已生成：

bash
docker compose exec ziti-host \
  sh -c 'test -s /ziti-edge-tunnel/ziti_id.json && echo identity-ready'

确认注册成功后，清除当前终端中的令牌，并重建容器，使其从数据卷加载身份：

bash
unset ZITI_ENROLL_TOKEN
docker compose up -d --force-recreate ziti-host

项目 .env 中也不要保留 ZITI_ENROLL_TOKEN。确认容器恢复运行后，可以删除传输用的 JWT 副本。身份文件保存在 remote-identity 数据卷中；该卷需要持续保留且可写。Docker Tunneler 文档说明了身份卷的用途。

四、验证访问路径

先在远端服务器查询自己的出口地址：

bash
curl -4 --http1.1 -x '' https://api.ipify.org

然后在 Linux 客户端确认 Tunneler 正在运行，并访问同一个接口：

bash
curl -4 --http1.1 -x '' -v https://api.ipify.org

如果配置生效，客户端返回的地址应与远端服务器访问该接口时使用的公网 IPv4 地址一致。两边的地址可能经过云服务商的网络地址转换，因此应以接口实际返回值为准。

-v 输出还可以帮助检查客户端连接的地址；Tunneler 正常拦截时，域名通常会解析为其分配的虚拟地址。命令中的选项用于固定 IPv4 和 TCP，便于对照。

如果结果不一致，在 Controller 上检查两侧策略：

bash
ziti edge policy-advisor services remote-ip-test ubuntu-ssh-client -q
ziti edge policy-advisor services remote-ip-test remote-outbound -q

客户端需要 Dial 权限，远端身份需要 Bind 权限，并且双方各自与服务有共同的在线 Router。还要检查远端容器的 DNS 能否解析目标域名，以及它能否访问目标的 443 端口。

五、换成自己的目标域名

验证完成后，可以按同样方式为另一个域名创建独立服务。例如，将下面的 www.example.com 替换为实际目标：

bash
ziti edge create config site-intercept intercept.v1 \
  '{"protocols":["tcp"],"addresses":["www.example.com"],"portRanges":[{"low":443,"high":443}]}'

ziti edge create config site-host host.v1 \
  '{"protocol":"tcp","address":"www.example.com","port":443}'

ziti edge create service selected-site \
  --configs site-intercept,site-host

ziti edge create service-policy selected-site-dial Dial \
  --identity-roles '@ubuntu-ssh-client' \
  --service-roles '@selected-site'

ziti edge create service-policy selected-site-bind Bind \
  --identity-roles '@remote-outbound' \
  --service-roles '@selected-site'

远端节点使用目标域名建立 TCP 连接；HTTPS 的证书验证仍由客户端完成。

有几个实际使用时容易遇到的情况：

• 一个网站可能跳转到其他域名，或从不同域名加载图片、脚本和登录页面；这些连接需要分别规划。
• 本例只覆盖 TCP 443。应用若使用独立 DNS 或基于 UDP 的 HTTP/3，实际路径可能不同，应分别验证。
• 当客户端 Tunneler 关闭或服务不再可用时，真实公网域名可能恢复普通解析，请求可能走本地网络。若必须避免这种回退，需要另行规划客户端出站规则，并保留 Controller 和 Router 的连接能力。
• 远端节点能够看到目标地址等连接信息；使用 HTTPS 时仍应正常验证目标站点证书。