Hi. I would like to understand the difference between transport and edge_transport binding in terminator settings.
The document mentioned that
The binding. This indicates which Xgress component on the router will handle making the connection. This will generally be transport for tcp based applications and udp for UDP based applications
When using ziti CLI to create a terminator, it creates one with edge_transport binding.
root@vyos:~# ziti edge create terminator --help
creates a service terminator managed by the Ziti Edge Controller
Usage:
ziti edge create terminator service router address [flags]
Flags:
--binding string Set the terminator binding (default "edge_transport")
...
Unfortunately I cannot find anything regarding to this type of binding in the document or on the forum.
Also only terminating with edge_transport works for me (I'm hosting a web server within the same local network as the edge router).
I'd suspect @plorenz might have something extra to say here, but in my opinion now-a-days, you shouldn't bother with ziti edge create terminator. I personally find it much more preferable allow the SDKs to create terminators on their own. For routers, you'd do that by putting the router into "tunneler" mode, and then authorizing services on that router. In my opinion, it's much easier to remember/track/administer that setup than creating terminators manually.
As for the transport type, I'm a bit murky with that concept myself but I expect that it is going to specify the purpose of that terminator. Whether the termination point is for "backhaul" (aka moving the bytes around the fabric) -- this would be "transport" -- and in my experience is unlikely to be relevant for what most people are looking at OpenZiti to do. Most people are happy to let OpenZiti maintain these terminators for itself via policies the operator configures. Or, whether the transport is for "user" traffic, aka "edge_transport", the data you're likely sending from one node of your overlay to the other.
Generally speaking, I personally only ever deal with the "edge" space for traffic and I think most people also spend their time with that concept. "Edge" traffic is the end to end type traffic that most of us are trying to send over the overlay.
I'm curious to see how my understanding meshes with Paul's. He's much closer to this part of OpenZiti than I am, I'm sure I've gotten a detail or two or ten confused...
Hi @nickchen120235
The only difference between transport and edge_transport is that edge_transport supports end-to-end encryption when there's an edge SDK on the client side.
In general I agree with the Clint that if you want service hosted by the router, it's preferable to use the built in tunneling capability. That main thing that gives you is built in support for service health checks, without which certain kinds of high availability and horizontal scale are harder to achieve reliably.
If you only have a single router talking to a single server, it probably doesn't make difference, but once you start removing single points of failure, you'll likely want to consider switching. Health checks and fail-over can also be automated externally, but I'd only recommend that if the built-in functionality doesn't meet your needs.
Cheers,
Paul
1 Like
Thanks for the replies.
My network topology is as the following diagram.
Unfortunately I cannot use the SDK for the application running on the "LAN Server", and I'm trying to avoid installing ziti-edge-tunnel or edge router on it. So maybe I can try putting the edge router in tunneler mode and make it work? If so how do I do that?
Also we'll have clients with ziti-edge-tunnel accessing the application from the Internet side, will it be different if I use my current terminator settings or use the edge router's tunneler mode?
In addition, I do recognize that managing terminators manually isn't that scalable, but we may have other application servers that we don't have control with joining our OpenZiti network on the LAN side. Is putting the edge router in tunneler mode more scalable or do I have to do some changes whenever a new server joins?
Yes, exactly. In this situation, you would use the edge router in tunneler mode to send traffic via a host.v1 config to 10.0.0.2. We'd consider that "ZTNA" or "zero trust network access" where you still traverse a "trusted", "private" LAN. I would remove any self-made terminators and simply let the controller/router manage the terminator.
The "onboard" side of and OpenZiti connection has no impact on the "offload" side of that connection. You can onboard with ziti-edge-tunnel or any other SDK client you wish and the traffic will tunnel to the terminator. Once at the terminator (in this case) that traffic will offload back to the underlay properly.
You will still need to define services in the OpenZIti overlay. Those services need to be authorized either to be Dial'ed or Bind'ed. You would authorize the router to Bind the service and then it will generate terminators for you. So yes, that's a much more natural and easy way to maintain terminators in an OpenZiti overlay. That way, for example, you could give the router a "#private-lan-routers" attribute and those services a "#private-lan-services" attribute... That would allow you to make ONE policy stating "any router with #private-lan-accecss can bind a #private-lan-service":
ziti edge create service-policy private-lan-bind Bind --identity-roles '#private-lan-routers' --service-roles '#private-lan-services'
Then, if you ever add a second router for scale, you simply make it with the #private-lan-routers attribute, and it's ALSO able to bind all those same services...
That make sense?
I can use a host.v1 to point out where the server is relative to a edge router, so there's no need to specify a terminator for it, am I right?
Also I would like to ask how to change an normal edge router to tunneler mode.
ziti edge update edge-router $idOrName --tunneler-enabled
Yes but that is not what a terminator is for. The terminator is the end node where traffic is sent on the overlay network. In the case of a "tunneled" service, this is the last OpenZiti node before the traffic is pulled from the overlay and put back onto the underlay. That's NOT the actual destination of the traffic though. Enabling tunneler mode is special, it allows the router to understand the host.v1 configuration, allowing the router to know that it should send traffic back into the underlay (IP) network towards the actual final destination.
So the host.v1 (or v2) configuration allows a tunneler-enabled edge router to relay traffic to a location relative to the router. The terminator gets the traffic to the router, so that it can then relay that traffic.... I hope I explained that well enough?
1 Like
Yep now I understand the difference. I’ll try the tunneler mode later today and see what happens. Thank you for the thorough explanation.
1 Like
Make sure you also add a tunnel binding in the router config, for example:
listeners:
- binding: tunnel
options:
mode: host
Cheers,
Paul
1 Like
Yay now everything works! Thank you Clint and Paul for the help.
Some takeaways
- With edge routers with tunneler enabled, we can "bind" the service with the router's identity and the router will manage terminators for us.
- When creating a new service in this scenario, remember to create both client-side "Dial" policy AND router-side "Bind" policy.
1 Like
