Seamlessly Switching Certificates, Configuring Multi-Location Routing Strategies, and Path Tracking

Support
1

Some questions from a beginner:

  1. When the certificates created by PKI management expire, how can I seamlessly switch to new ones? Can I just regenerate the related certificates and replace the ones on the controller? Do I also need to manually replace the certificates on routers and other components?
  2. I have routers configured in multiple locations. By default, the routing follows an internal intelligent strategy. However, I would like to manually specify a route. For example, I have five routers: R1, R2, R3, R4, and R5. The default routing might go Client--R1--SERVER (perhaps based on minimizing routing costs, similar to OSPF). But I want to specify the route as Client--R5--R2--R4--R3--R1--SERVER. Is this possible?
  3. When testing access, is there a way to trace the routing path it follows? I’d like to know through which routers the traffic passes, similar to mtr or traceroute in Linux.
  4. When a client wants to access services like Google or Office365, I want to route traffic through a specified path. Since these are broad services with many domains or IPs, how can I ensure all related domains or IPs are included? Is *.google.com enough, or will there still be some omissions? I saw this feature in Netskope, so I’m curious if OpenZiti can achieve this.
2

There's quite a few to cover. Yes generally you can just regenerate one you need to, such as server certs. Routers will renew certs on their own unless you provide them in which case you need to manage them. There's probably too much to get into for this question to keep it short. Hopefully this is enough info for now?

A qualified "Yes". you can do this with the addition of link groups. See the Release v0.30.0 · openziti/ziti · GitHub change log for details. This allows you to influence links between routers, but not individual identity paths if that makes sense? If there are more than one path, you also won't know exactly which is selected. You can influence those sorts of things further with edge and service router policies and router "weights". It might be what you want. It might not be as fine grained as you're thinking

For short lived circuits, I'm not sure how to capture the information but for long lived circuits you can issue ziti fabric list circuits to see how any given connection was pathed.

Yes, a wildcard intercept with a forward address config should do this. I do worry that it will be imperfect at best. It's hard to keep up with changes to cloud services. If they migrate services, change names etc it'll potentially break or leak information. I don't know that this is reliably able to be done but I'd expect if you intercept all the relevant addresses and forward them off from somewhere else it'll work fine. I've never done this myself at any kind of massive service like *.google.com to know if there are any hidden gotchas but it should work.

3

  1. The controller's certificate remains within a manageable range, but the routing certificates cannot be automatically updated, which can be troublesome. This is particularly the case when your routing services are not deployed in your own environment, but potentially in remote or foreign locations where the control of the operating system may lie with other data center administrators. In such scenarios, if my certificate's validity period is shorter than the business lifecycle, there is a risk of interruption.

  2. I don't want all services to follow the same route; instead, I want different services to take different specified paths. For example, server1 could follow the path R5 → R2 → R4 → R3 → R1, while server2 might only require R1 → R2. I noticed that this isn't currently possible, which is just my speculation for the future. Different regions can have varying speeds, legalities, compliance, and political influences, and specifying different routing nodes could help mitigate data flow issues.

  3. I attempted to execute it but didn't get any return. However, I noticed the command ziti edge traceroute, which I couldn't successfully execute. Being able to intuitively understand the routing path would greatly assist administrators in troubleshooting business anomalies (this is my personal view).

  4. This is an idea I encountered in similar products, as I want to suggest improvements for OpenZiti. In this scenario, employees in different regions would exit through the routing available in their respective areas, even if they are on business trips elsewhere. It would also facilitate the deployment of traffic detection services like WAF or AC(Access Control) at critical nodes.

4

Not sure what you mean. The router renews its certificates automatically so this shouldn't be a problem?

It's "possible" right now, but it'll be really cumbersome to implement. You can use a "service edge router policy" to inform services where they can be "onboarded" to the overlay, and where they can offload from the overlay. You can then stand up a bespoke router for bespoke links and control that path precisely, but boy that'll be "work"... :slight_smile: but you could do it!

Bespoke pathing like this is one of those features we've talked about before, but there's not been a substantial demand for the feature to date.

Make an ssh connection via ziti and you'll get results. If you're doing http requests, you basically need to do a tight loop to catch the path... I did exactly that to catch the http request I used to reply on this topic Inspecting the Fabric and Mesh - #6 by TheLumberjack

Here's a quick video showing you how to use traceroute and our complicated docker compose environment

Commands from the video

curl -so docker-compose.yaml https://get.openziti.io/dock/docker-compose.yml
curl -so .env https://get.openziti.io/dock/.env
docker compose --project-name traceroute up

docker exec -it traceroute-ziti-controller-1 vi ziti-fabric-router-br.yaml
  listeners:
    - binding:          transport
      groups:
        - intermediary

docker exec -it traceroute-ziti-controller-1 vi ziti-private-blue.yaml
link:
  dialers:
    - binding: transport
      groups:
        - intermediary
		
docker compose --project-name traceroute restart ziti-fabric-router-br ziti-private-blue

docker exec -it traceroute-ziti-controller-1 bash -i -c "source ~/.bashrc && zitiLogin"
docker exec -it traceroute-ziti-controller-1 /var/openziti/ziti-bin/ziti fabric list links

docker exec -it traceroute-ziti-controller-1 \
	/var/openziti/ziti-bin/ziti edge create config http.intercept.v1 intercept.v1 \
	'{"protocols":["tcp"],"addresses":["http.ziti"], "portRanges":[{"low":80, "high":80}]}'
docker exec -it traceroute-ziti-controller-1 \
	/var/openziti/ziti-bin/ziti edge create config http.host.v1 host.v1 \
	'{"protocol":"tcp", "address":"web.test.blue", "port":8000}'
docker exec -it traceroute-ziti-controller-1 \
	/var/openziti/ziti-bin/ziti edge create service http.svc \
	--configs http.intercept.v1,http.host.v1
docker exec -it traceroute-ziti-controller-1 \
	/var/openziti/ziti-bin/ziti edge create service-policy \
	http.policy.dial Dial \
	--service-roles "@http.svc" \
	--identity-roles '#http-clients'
docker exec -it traceroute-ziti-controller-1 \
	/var/openziti/ziti-bin/ziti edge create service-policy \
	http.policy.bind Bind \
	--service-roles '@http.svc' \
	--identity-roles '@ziti-private-blue'

docker exec -it traceroute-ziti-controller-1 \
	/var/openziti/ziti-bin/ziti edge create identity traceroute-test \
	-o traceroute-test.jwt \
	-a 'http-clients'
docker exec -it traceroute-ziti-controller-1 \
	/var/openziti/ziti-bin/ziti edge enroll traceroute-test.jwt

docker exec -it traceroute-ziti-controller-1 \
	/var/openziti/ziti-bin/ziti edge traceroute http.svc \
	--config-file traceroute-test.json