Hi,
Totally new user to OpenZiti. I went through the quickstart tutorial, and then proceeded to deploy a controller and router in a publicly accessible Linux cloud VM. I’ve installed a tunneller client on my home (Linux) laptop and have defined a Ziti service so that I am able to SSH to the cloud VM using the service’s Ziti “hostname” and have the traffic flow over the overlay (as opposed to directly on the Internet).
While I do have a ziti0 virtual interface on my Linux laptop, I've noticed that my Linux cloud VM running the edge router (with the tunneler option enabled), does not. Since the SSH service over the overlay does work, I guess it's not an issue. Still, I'm wondering how it all works without it. Do all edge routers with the tunneler option NOT have the ziti0 interface, or would it "magically" appear if I configured a service with a dial policy matching the edge router?
Thanks!
Version used:
Ziti controller/router: v1.6.12
Hello, great question.
The edge router uses a different mechanism for intercepting packets than the other tunnelers.
ziti-edge-tunnel and the desktop and mobile tunnelers for Windows/macOS/iOS/Android use a tun interface to intercept network packets. The packets are processed by ziti-tunnel-sdk-c which determines if a packet should be associated with an OpenZiti service, and if so proxies it to the overlay.
The edge router tunneler works differently - it uses the TPROXY iptables target to associate ip addresses and port ranges with OpenZiti services. So there’s no tun interface. Instead, the edge router creates a server socket and a TPROXY rule for each OpenZiti service that it should intercept. Each server socket is bound to a random port the loopback address, and the TPROXY rules direct connections destined for the intercept address(es) to the server socket.
It’s a little out of date but ziti/dist/dist-packages/linux/ziti-tunnel at main · openziti/ziti · GitHub is still a decent overview of the “tproxy” and “tun” intercept techniques used by the OpenZiti tunnelers.
edit:
And if you’re question was more concerned with how data moves from the “hosting” tunneler (which is an edge router in your case), the answer is that all tunnelers currently use a plain TCP or UDP socket to connect with with the address in the service’s host.v1 configuration. The payloads from the intercepted packets (or the TPROXY connection) are what gets sent on the overlay, and written to the socket.
Thanks for the detailed info, @scareything.
I created an edge router with the tunneler option enabled on a Fedora 43 instance and created an SSH service with a dial policy that includes the identity of that new edge router. Yet I am not able to SSH to the destination target bound to that service because the service name doesn't resolve properly. For my testing I am comparing interception on this new edge router instance with another instance running ziti-edge-tunnel on Fedora 43 as well. Interception works fine on the instance running ziti-edge-tunnel because systemd-resolved points the ziti0 interface's DNS server to 100.64.0.2 for proper Ziti service name resolution. However, on the instance running ziti-router there is no ziti0 interface and DNS is only configured for the instance's single interface, and it points to Cloudflare's 1.1.1.1.
You mentioned previously that the edge router uses a different mechanism for intercepting packets than the ziti-edge-tunnel, using instead the TPROXY iptables target. So I didn't initially see the absence of the ziti0 interface on the edge router instance as an outright issue, but irrespective of this, how would DNS queries for the Ziti service name be answered to begin with if the Ziti DNS server is not configured anywhere? And with regards to the TPROXY iptables target, the Fedora 43 instance I'm running doesn't have the iptables module loaded based on the empty output of lsmod | grep ip_tables, and iptables -nvL shows no rules being present. So I take it that even though I think I have configured the intercept policy correctly so that it should apply to this edge router instance, it doesn't seem like it has the plumbing to actually perform it.
I also found this error message in the logs of the edge router process: failed to intercept service: can not intercept services in host mode. I'm not sure what this message means by "host mode", but I don't have any bind policy related to that edge router, so I can't imagine that it's referring to a host configuration. But the message does seem to indicate that interception cannot be done, even though I cannot understand the actual reason why.
Any ideas?
“host mode” means the router will only host (bind) OpenZiti services. The edge router will only create the tproxy rules for intercepting connections if the tunnel binding mode in the router’s configuration file is “tproxy”:
listeners:
- binding: tunnel
options:
mode: tproxy
This will also enable a DNS server in the router that maps your ziti hostnames to IPs. The default address of the DNS server is udp:127.0.0.1:53 (this can be changed with command line options). You’ll need to add this address to your host’s resolver configuration in order for it to be used.
You’re running Fedora 43, which uses systemd-resolved by default. If you haven’t changed that then a reasonable way to add the router’s DNS server is to create a drop-in file /etc/systemd/resolved.conf.d/ziti-router.conf with the following content:
[Resolve]
DNS=127.0.0.1
If this file is effective you’ll see it in the “Global” section of the resolvectl output:
$ resolvectl
Global
Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 127.0.0.1
DNS Servers: 127.0.0.1
Link 2
...
1 Like
Thanks @scareything, I doubt I would have it figured it all out on my own!
I set the mode to tproxy as you indicated, and initially the router service wouldn't start because of a netlink receive: operation not permitted error, but after searching a bit and finding the override file /etc/systemd/system/ziti-router.service.d/override.conf, I uncommented:
AmbientCapabilities=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_ADMIN
and it all works now, meaning I can dial a service from the edge router successfully!
Thanks again.
1 Like