Reviewing the configurations when making a second edge router private

Ziti Overlay
1

I am consolidating my learnings, and noticed a previous example where I created a second public edge router.

Here is a copy of the discussion
https://openziti.discourse.group/t/creating-a-second-public-edge-router/

This is a summary of the changes needed

  1. use a new port number
  2. use the IP address of the controller to advertise on
  3. include the IP address of the controller in the edge CSR IP tags
listeners:
# bindings of edge and tunnel requires an "edge" section below
  - binding: edge
    address: tls:0.0.0.0:8442
    options:
      advertise: 222.333.44.22:8442
....
  - binding: tunnel
    options:
      mode: host #tproxy|host


edge:
  csr:
      ip:
        - "127.0.0.1"
        - "222.333.44.22"

Some questions that I have are:

  1. If you comment out the listeners section, would this make the public edge router a private edge router

I remember a references in the past about private routers.. but are not really sure what they are

  1. what is the difference between the edge / tunnel bindings

I am not really clear on this

  1. When making changes.. at what point do you need to re-enrol the edge router identity

why is this needed?
I remember that the edge router identity need to be re-created if you are using a Oracle Linux server.. because it does not use the IP address for the listener to advertise on

Any tips / insights would be greatly appreciated.

2

I remember noticing this comment in one of the earlier threads.. so that answers my question re the tunneller binding.. as its not needed if you use app embedded networks.. but is if you dont :slight_smile:

3

I think I worked this one out.. because when you enrol the identity for the edge router.. it defines the IP addresses in the SAN for the router certificate..

Hence.. you don't need to recreate it if you are simply making a few minor changes.. only if it affects the SAN details of the certificate.

1 Like
4

If you're not app-embedded, you need tunnelers of some kind. You can either have the tunneler running inside an edge-router, in which case you need the tunneler binding, or you can have it running standalone, in which case you don't. A standalone tunneler looks just like any other SDK app to the edge router.

1 Like
5

I think usually public/private routers refer to where they sit on the internet, in public or private networks.

Public routers are those that can be reached on the public internet. Public edge routers can be used to allow clients coming from arbitrary locations access to a ziti network. Public routers (either fabric or edge) can also be a means for routers in private networks to be bridged together. If you have private routers in private networks A and B, they can't reach each other. But they can both reach out and from links to one or more public routers, allowing traffic to flow from A to B (provided you have the right policies configured).

Private routers are those that are in a private network. They reach out to the public routers to form the fabric mesh and provide access to the services that are in the same private network. They can also provide access to clients in the same private network.

If you removed everything from the listeners section you wouldn't be able to initiate any connections to that router. Depending on what you had in the dialers section, you might be able to have traffic terminating on that router.

1 Like
6

The edge binding configures a listener for edge SDK clients. The tunnel binding runs a tunneler in the router process.

edge binding: router[edge listener] <- network -> edge sdk clients
tunnel binding: router[tunneler] <- network -> non-sdk apps

1 Like