Explain about host and intercept Configs

Support General Questions
1

Hi, I was going through the ziti documentation and encountered the config types, I understand these configs are to configure the tunneler to access the service, but could someone pls explain in detail about the difference between the host.v1 config and intercept.v1 config. I assume host.v1 config is instructing the tunneler to forward the traffic to the specified address wherever the service is hosted , but then what is the intercept config doing, and what address are we providing in the intercept address field

1 Like
2

Hi @dexter, this is a great question! You've made me aware of the fact that our documentation doesn't cover the intercept configuration types all. I'll get to work on fixing that, but in the meantime I'll try to explain it here.

It sounds like you understand the host.v1 configuration: it tells the tunneler where to forward connections to. The tunneler can also work on the initiating side of a connection. When a tcp/ip or udp client like curl or ssh tries to connect to an address, the tunneler can "intercept" that connection and proxy it over a ziti connection. Those addresses in the intercept.v1 configurations tell the tunneler which protocol:ip|hostname:port combinations to intercept and proxy for the associated ziti service. Hopefully that gives you an overview of intercept configurations.

You asked for a detailed expiation, so I'll talk a little bit about how intercepting works. Let's start with an example service with intercept.v1 configuration that could be used to intercept http connections:

ziti edge create config webserver-intercept intercept.v1 '{
    "protocols": [ "tcp" ],
    "addresses": ["10.10.10.10"],
    "portRanges": [ {"low": 80, "high": 80} ]
}'

This intercept configuration tells the tunneler to look for connections to tcp:10.10.10.10:80. Exactly what happens depends on the specific tunneler that's processing the configuration. I'll talk about how ziti-edge-tunnel works on Linux. The Ziti Desktop Edge for Mac/Windows/iOS tunnelers are very similar in how they work, but there are slight differences. Let me know if you have specific questions about how other tunnelers work.

The first thing that ziti-egde-tunnel does is create a "tun" device. This is a virtual network device that applications can use to exchange raw IP packets with other applications that are running on the same host.

$ ip link show dev ziti0
17: ziti0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 500
    link/none

When the tunneler receives a service with an intercept configuration, it looks at each of the addresses in the configuration and creates a route in the operating system's routing table. You'll see something like this in the logs:

INFO tunnel-cbs:ziti_tunnel_cbs.c:409 new_ziti_intercept() creating intercept for service[ssh] with intercept.v1 = {"protocols": [ "tcp" ], "addresses": ["10.10.10.10"], "portRanges": [ {"low": 80, "high": 80} ]}

And you'll now see a route for that address on ziti-edge-tunnel's tun device:

$ ip route list dev ziti0
100.64.1.0/24 scope link 
10.10.10.10 scope link

This route tells the operating system to direct any packets that are being sent to 10.10.10.10 through the tun device, which ziti-edge-tunnel is reading from. When ziti-edge-tunnel receives a packet, it looks at the destination protocol, ip and port of the packet and tries to match it up with one of the services that it has intercept configurations for. If a matching intercept address is found, ziti-edge-tunnel uses the ziti SDK to make a connection for the associated Ziti service on the overlay network. Once that Ziti connection is established, ziti-edge-tunnel proxies data between the tun device and the Ziti connection.

That's the overview of how connections are intercepted. Hostname intercepts add a DNS layer on top of what's discussed here, but the packet intercept mechanism still boils down to IP packets whether the intercept address is an IP or a hostname.

3 Likes
3

These explanatory articles about tunneling configs should probably be replaced by those newer references about config types.

1 Like