I just read documentation for linux tunnerler, and it seems linux tunneler no longer tries to manually modify /etc/resolv.conf if systemd-resolvd is not available through polkit. Correct? I want to manually configure it on my highly customized linux system.
Intercepted IP addresses are added to TUN, and intercepted service domain names are added to TUN name server. Correct?
Hey there @amano 
That's right, the Linux tunneler, ziti-edge-tunnel run command, will keep running if it's unable to auto-configure the host's resolver. There's no requirement to use systemd-resolved, but if it's present and the necessary capabilities are granted, the tunneler's nameserver will be in the host's default resolution chain.
Since you're not using systemd-resolved, you must ensure the tunneler's nameserver is the first resolver for any processes you wish to connect to your Ziti services by a domain name.
If you can only configure a single resolver, you may add the --dns-upstream 1.1.1.1 option to specify a recursive nameserver.
Each authorized service with an intercept config with a domain name intercept creates an intercept address from the DNS IP range (default: 100.64.0.0/10) added to the TUN. For example, intercept 100.64.0.4 routes like so:
❯ ip route get 100.64.0.4
100.64.0.4 dev ziti0 src 100.64.0.1 uid 1000
cache
The built-in nameserver also resolves each authorized service's domain names.
❯ dig +noall +answer mysvc1.ziti.example.com @100.64.0.2
mysvc1.ziti.example.com. 60 IN A 100.64.0.4
The router's native tunnel binding mode is "none," and some deployments default to "host." If the mode is not "none," the router must be administratively enabled for tunneling, or it will panic at startup.
ziti edge update edge-router "router1" --tunneler-enabled
The modes are:
host: handles only binds for hosting services - acts as an exit point from Ziti to the regular network - automatically hosts new services when authorizedproxy: handles only dialing services - acts as a raw TCP (L4) proxy from the regular network to each Ziti service that is explicitly bound in the router's configuration filetproxy: handles binds and dialing services - acts like a transparent proxy from regular network to the Ziti network; requires NET_ADMIN to create TPROXY iptables rules in the network namespace - automatically starts dialing and binding services when authorizedHow is proxy mode of tunnel binding different from proxy binding?
One of the modes for the router's optional tunnel binding is proxy. In this mode, you configure an explicit list of pairs of Ziti service and TCP port. When the router starts, packets arriving on the TCP port are forwarded to the Ziti service's hosting identity.
listeners:
- binding: tunnel
options:
mode: proxy
services:
- myService1:8080
I have no idea of how to configure proxy binding. The documentation is not very clear. Can you explain transport binding, too?
In this router config.yml snippet, a hypothetical Ziti service named "myService1" is bound to the router's local TCP port 8080, and the router's tunneler dials that service when packets arrive on the port. This allows the proxy mode to function as a TCP (L4) proxy.
The main decision you must make regarding transport bindings is whether a specific router will listen on a public IP address for other routers to form mesh links. You must have at least one "public" router, i.e., with at least one link listener. All routers try to form links with public routers to build the mesh of transport links, i.e., the ziti fabric.
You may find this helpful: Data Flow Explainer | OpenZiti
I think there's a bit of confusion.
I was referring to Conventions | OpenZiti
proxy - listener only - allows ingress TCP connections to connect directly to a service defined in optionstunnel - a special type of binding used by routers
proxy - the router's tunnel is configured to provide a forward proxy listener for a list of service, TCP port pairs. This mode also enables the reverse proxy features of host mode.transport - listener, dialer - allows ingress TCP connections to request a circuit for a service and for traffic to dial to an underlay UDP service at a <host>:<port> addressI do not understand how proxy listener differs from proxy mode of tunnel listener. I also do not understand how transport dialer and transport listener work.
The xgress components named proxy and tunnel are different tools for ingress to and egress from the overlay.
The tunnel component is widely used and particularly convenient because it allows the router to be authorized to dial and bind services by the same policies that govern all other identities. The proxy xgress component is scarcely used, I'm guessing, because it's never been valuable or visible to me. If you're interested in extending OpenZiti with an xgress component then you could reference proxy for that purpose.
The tunnel component has a few modes, one of which is proxy. The main difference between it and the xgress component of the same name is that the tunneler is subject to edge policies, whereas xgress proxy exists at a lower logical level, foundational to the edge policies.
Re: transport
Routers form transport links with one another. Routers listening for links also advertise some address for other routers to dial. All links are initiated toward a listening router, and all links provide bi-directional transport for services.
proxy xgress component and transport xgress component are limited alternatives to edge xgress component for SDK traffic?edge xgress component in most cases for SDK traffic?I will stick with tunnel and edge xgress components. xgress components should be documented properly.
In an operational scenario, you'll encounter the edge, tunnel, and transport components as directives in the router configuration file because it implements all three to proxy service traffic between the OpenZiti edge and fabric layers of the system.
If you're developing a component to extend OpenZiti, you might deal with these components directly, especially if your goal is to build around the edge. If you're developing for the edge, then you'd probably use an edge SDK instead of a tunneler: Ziti Developer Resources | OpenZiti
transport component is for routing fabric traffic? edge is for edge traffic? proxy is for fabric traffic, too? tunnel is for conversion between internet traffic and edge traffic?
I'm a little worried that diving deeper into the xgress components may not be relevant to your scenario, aside from configuring the router's tunnel binding mode. The xgress components are internal to OpenZiti, so they're not how most users interact with the system.
It would help me to surface the most relevant information if I knew that you were approaching this as an operator to deploy OpenZiti, developer to extend or integrate OpenZiti, or both? I'd be happy to think about how best to approach your case if you can share a little about it.
Correct, transport links between routers carry services' payload data.
My rudimentary understanding is the edge xgress component implements xgress for the edge for things like translating data from the edge to the fabric and vice versa.
The proxy xgress component is a little, if ever, used component that directly proxies from the regular network to a service on the fabric, bypassing the edge.
The xgress component tunnel enables a router to also tunnel services. OpenZiti tunnelers proxy traffic between the edge and the regular network.