Do Not Default to a VPN

Internet censorship and blocking push people toward public VPNs. That is understandable. But public VPNs are not a strong security answer. You are moving your traffic and trust boundary onto someone else's infrastructure.

If you need this kind of access, it is safer to host it yourself on your own VM or your own infrastructure. Then you control the server, keys, logs, and policies. Running a traditional VPN like OpenVPN is possible, but it is not simple. You have to manage certificates, client profiles, routing, DNS, revocation, and mobile client behavior.

OpenZiti is useful because it is service-first, not network-first. Instead of giving a device access to part of a subnet, you give an identity access to a specific service. One technical detail matters here: OpenZiti separates client intercept config, host forwarding config, and dial/bind policies. The hosting side can stay outbound-only, and the client only gets the domains and ports defined by policy. That is narrower than the usual commercial VPN model.

With an agent, the request can be this simple:

Add a new OpenZiti rule for web access to YouTube and Telegram only.

That is easier to work with than doing everything by hand. The agent can create the configs, service, policies, and identity role changes without turning a small access change into a long controller session.

Doing the same thing manually takes much longer. It looks like this:

ssh hawking 'bash -s' <<'EOF'
set -euo pipefail

source /root/.ziti/quickstart/ziti/ziti.env >/dev/null 2>&1
/opt/openziti/bin/ziti edge login \
  "${ZITI_CTRL_EDGE_ADVERTISED_ADDRESS}:${ZITI_CTRL_EDGE_ADVERTISED_PORT}" \
  -u "$ZITI_USER" -p "$ZITI_PWD" -y >/dev/null

cat >/tmp/yt-tg-web.intercept.v1.json <<'JSON'
{
  "protocols": ["tcp", "udp"],
  "addresses": [
    "youtube.com",
    "*.youtube.com",
    "youtu.be",
    "*.googlevideo.com",
    "*.ytimg.com",
    "telegram.org",
    "*.telegram.org",
    "t.me",
    "*.t.me",
    "telegram.me",
    "*.telegram.me",
    "web.telegram.org"
  ],
  "portRanges": [
    { "low": 80, "high": 80 },
    { "low": 443, "high": 443 }
  ]
}
JSON

cat >/tmp/yt-tg-web.host.v1.json <<'JSON'
{
  "forwardAddress": true,
  "allowedAddresses": [
    "youtube.com",
    "*.youtube.com",
    "youtu.be",
    "*.googlevideo.com",
    "*.ytimg.com",
    "telegram.org",
    "*.telegram.org",
    "t.me",
    "*.t.me",
    "telegram.me",
    "*.telegram.me",
    "web.telegram.org"
  ],
  "forwardPort": true,
  "allowedPortRanges": [
    { "low": 80, "high": 80 },
    { "low": 443, "high": 443 }
  ],
  "forwardProtocol": true,
  "allowedProtocols": ["tcp", "udp"]
}
JSON

/opt/openziti/bin/ziti edge create config yt-tg-web.intercept.v1 intercept.v1 -f /tmp/yt-tg-web.intercept.v1.json
/opt/openziti/bin/ziti edge create config yt-tg-web.host.v1 host.v1 -f /tmp/yt-tg-web.host.v1.json
/opt/openziti/bin/ziti edge create service yt-tg-web-egress \
  --configs yt-tg-web.intercept.v1,yt-tg-web.host.v1

/opt/openziti/bin/ziti edge create service-policy yt-tg-web-egress-dial Dial \
  --identity-roles '#yt-tg-web' \
  --service-roles '@yt-tg-web-egress'

/opt/openziti/bin/ziti edge create service-policy yt-tg-web-egress-bind Bind \
  --identity-roles '#yt-host-qs' \
  --service-roles '@yt-tg-web-egress'
EOF

ssh hawking 'source /root/.ziti/quickstart/ziti/ziti.env >/dev/null 2>&1; /opt/openziti/bin/ziti edge update identity anton-iphone-qs3 -a yt-tg-web'

The difference is not just convenience. The agent request is short, but the resulting access is still narrow: specific domains, specific ports, specific roles. That is a better model than putting a device onto a broad VPN and treating the rest as cleanup later.