Quick checkin to test my logic.
I am moving the edge router from the QuickStart demo to a second remote server.
As I am planning all of the steps required, I want to check the following:
Controller server:
- only requires port 6262 to be open
- all other ports can be closed (ie the port used by the demo public edge router)
Second server:
- requires port 3022 to be open for the public edge router.
- requires port 6262 to be open for the controller ( I am not 100% sure about this though)
I have worked through this the most of the day, trying to get all of the documentation in place, which has helped a lot preparing for this demo.
Now that I have this in place, I am now trying to debug the following error that happens when I run the ziti-router
ziti-router run "${ZITI_HOME}/${router_name}.yaml" > "${ZITI_HOME}/${router_name}.log"
{"error":"error connecting ctrl (x509: certificate is valid for 127.0.0.1, not 333.111.11.77)"
Before running this, I successfully enrolled the edge router on a remote server and confirmed that the router identity was successfully created
I think I know what is happening… as the IP of the server that I want the router to run from is not in the SAN of the controller certificate… that was created when I setup the contoller.
Is this what is happening?
@TheLumberjack
In such cases, what steps to do need to take when seeking to run the controller and public edge router on separate servers.
I am going to need to rethink the approach that I am taking… as I am missing something from a certificate perspective.
I do have another possible issue… as I did not download a env file for the second server.
Instead, I manually set the following in the .bashrc file.
export **ZITI_HOME=**/home/opc/.ziti/remote-router
export **ZITI_BIN=**$ZITI_HOME/ziti-bin/ziti-v0.26.3
Maybe there are a few other settings that I am missing… as I don’t really know what I am doing
Ahh… I think I know what is happening… as the ZITI_BIN folder is not set correctly… I will reset everything and try again
Personally, I don’t consider it “moving” an edge router. For me, I consider it easier to put a new one in place, then just turn off the old one later. It also lets you keep that edge router around until you get it right. You also don’t have any pki related problems when doing it that way.
We also don’t have a “deploy another router” quickstart yet, it’s in the plans but not done yet.
If you have successfully setup a second edge router in the past (I think you have) just do it that way and you’ll be through this in no time…
Hope that makes sense.
1 Like
As Clint said, it is easier to put a new one in place and then turn off the old one later. If the service is setup using attributes, the move is even easier by just assigning the same attribute to the second router.