Simple Multi-cloud deployment - Routers Configuration

Support General Questions
1

Hello,

I’m trying to achieve what’s in the diagram below :

Diagramme sans nom.drawio

If you feel that you need to edit the diagram : link.
I’ve configured the Oracle Cloud part using the quickstart and it’s working all good.

The bottom part I’ve successfully done it with a tunneler instead of a private router, and now I’m trying to achieve the same thing but with routers.

First, I’m trying to understand the configuration files of each router type and it’s giving me headaches haha.

Correct me If I’m wrong, but , Instead of the private router, I cannot setup a Fabric Router instead with edge feature disabled, right ?

If I refer to the configuration files of a Fabric Router, an Edge Router and a Private Router of the docker compose quickstart.

Fabric router config file 
...
link:
  dialers:
    - binding: transport
  listeners:
    - binding:          transport
      bind:             tls:0.0.0.0:10080
      advertise:        tls:ziti-fabric-router-br:10080
      options:
        outQueueSize:   4

#listeners:
# bindings of edge and tunnel requires an "edge" section below
#  - binding: edge
#    address: tls:0.0.0.0:3022
#    options:
#      advertise: ziti-fabric-router-br:3022
#      connectTimeoutMs: 1000
#      getSessionTimeout: 60s
#  - binding: tunnel
#    options:
#      mode: host #tproxy|host


csr:
  country: US
  province: NC
  locality: Charlotte
  organization: NetFoundry
  organizationalUnit: Ziti
  sans:
    dns:
      - ziti-fabric-router-br
      - localhost
    ip:
      - "127.0.0.1"
...
Private router config file 
...
link:
  dialers:
    - binding: transport
#  listeners:
#    - binding:          transport
#      bind:             tls:0.0.0.0:10080
#      advertise:        tls:ziti-private-blue:10080
#      options:
#        outQueueSize:   4

listeners:
# bindings of edge and tunnel requires an "edge" section below
  - binding: edge
    address: tls:0.0.0.0:3022
    options:
      advertise: ziti-private-blue:3022
      connectTimeoutMs: 1000
      getSessionTimeout: 60s
  - binding: tunnel
    options:
      mode: host #tproxy|host


edge:
  csr:
    country: US
    province: NC
    locality: Charlotte
    organization: NetFoundry
    organizationalUnit: Ziti
    sans:
      dns:
        - ziti-private-blue
        - localhost
      ip:
        - "127.0.0.1"
...
Edge router config file 
...
link:
  dialers:
    - binding: transport
  listeners:
    - binding:          transport
      bind:             tls:0.0.0.0:10080
      advertise:        tls:ziti-edge-router:10080
      options:
        outQueueSize:   4

listeners:
# bindings of edge and tunnel requires an "edge" section below
  - binding: edge
    address: tls:0.0.0.0:3022
    options:
      advertise: ziti-edge-router:3022
      connectTimeoutMs: 1000
      getSessionTimeout: 60s
  - binding: tunnel
    options:
      mode: host #tproxy|host


edge:
  csr:
    country: US
    province: NC
    locality: Charlotte
    organization: NetFoundry
    organizationalUnit: Ziti
    sans:
      dns:
        - ziti-edge-router
        - localhost
      ip:
        - "127.0.0.1"
...

the only difference is that Fabric has link.listeners only, Private has only listenersand Edge routers has both.
What I’m understanding by comparing those two config files is that :

  • link.listeners is used to tell the router “Hey, listen on traffic coming from outside of the Ziti Overlay”
  • listeners tells the router “Hey, listen on traffic coming from inside of the Ziti Overlay”

I’m not really confident when saying this, because it kinda looks wrong, I mean, why does a Fabric router should be routing traffic coming from outside ? Isn’t that the job of an Edge router ?

I hope my questions are meaningful to you, If not, I’d be glad to clarify things.

Regards,
Arslane

1 Like
2

Close, but backwards :slight_smile:

Links are what connect routers to each other. So a router with link.listeners can receive connections from other routers to form the mesh. Routers that have link.dialers configured will try to make connections with routers that have a link.listeners configured. A router can have both dialers and listeners configured.

Every router, fabric or edge, should generally participate in the mesh, so usually every router will have either link.dialers and/or link.listeners configured.

The listeners section is for configuring components which can feed external traffic into the ziti fabric or sent traffic out of the fabric. Generally this means the edge. If you want to enable edge functionality, you need to specify an listeners section for edge, as well as a top level edge: section. If you want to use the combined edge router/tunneler, you also need a listeners section for the tunnel.

Example:

listeners:
  - binding: tunnel
    options:
        mode: host
  - binding: edge
    address: tls:0.0.0.0:7876
    options:
      advertise: 127.0.0.1:7876

Hope that's helpful, let me know if I can provide more details.
Cheers,
Paul

3 Likes
3

This is very helpful as I am going to work through this tomorrow.

4

Very clear answer, thanks a lot.

I’ve have just two more questions about the SANs, is there any use case where I need/should put more than two DNS names ? Like other than localhost and the router name ?

Also, correct me If I’m wrong, but instead of localhost I can actually put something else like “some-random-dns” given the condition that I provide that exact dns name in every other router and client/server pki of my overlay network.

5

The SANs you want is completely up to you, but I can provide guidance.

On every system, you have localhost, 127.0.0.1, and an external IP. Conditionally you can have additional IP addresses (say for an internal and external network) and 0 or more domain names.

Adding all permutations to the edge routers certificate is up to you and is based on how you want to address them. At the minimum, I would aim for 127.0.0.1, localhost, and whatever IP address is exposed on the open internet. Additionally, ensuring that whatever your advertise values are for your listeners (for link and edge) is important as that is how external systems (SDKs and routers) will connect.

If you know you will always be able to use the same DNS names for a router, those do provide agility over IP addresses should you need to move routers/controllers. If you know you will always be able to provide the same DNS names/maintain them sticking only to DNS names can be preferable. If you don’t care about the IP/DNS names of routers changing, you can always re-enroll new ones. I only mention this portion because we have some new features coming out where having a public DNS names that is from a public CA may be useful.

All other IP/DNS values are for your agility/future design decisions. Also, the certificate, when renewed, can obtain new SANs if configured to do so. If necessary, it would be possible for us to add a command to force early renewal.

1 Like
6

Thanks alot !

So, on the client/server PKI I should put the DNS names of public edge routers only in there ?

7

When I deploy ziti network components, I use at least the DNS names (public or private) of the machine that it’s configured to advertise to other network components, localhost, 127.0.0.1, and any ips of the router I might want.

If you’re content with only using a DNS name you could do that. I like adding all the ips, all the DNS names because you never know how you might end up using it.

1 Like